The first thing we must agree on is that software has gotten complicated.  There are all kinds of tools that help with coding and implementation.  However, these do not eliminate the challenge of building a useful and stable system.  The lines of code written by humans may be dropping, but the overall size of modern systems is growing all the time.  Thus, software design is needed to plug all of those pieces together and provide a path for the implementation team to build a cohesive system.  There are tens of thousands of “moving parts” in most modern systems and that means the same number of potential points of failure.

Code complexity is just the technical part of the problem.  The more significant reason for spending time on software design is due to vision.  A client, end-user, stakeholder, and developer all have their vision of a solution.  Some of the differences are due to gaps in knowledge.  For example, a subject matter expert has a deeper understanding of the problems to be solver than other team members.  This is not an issue unless we skip the step where that knowledge is transferred to others.

A more substantial challenge is that we do not know what we do not.  Thus, there must be a conversation around software design.  The designers and implementation team needs to be on the same page as the end users and stakeholders.  When this does not happen, it is like giving someone directions to meet you, but they use a different (and incorrect) set of instructions.  When the destination or goal is not the same, then failure is almost guaranteed.

The astounding aspect of this situation is that it is an old problem.  Even worse, it is one that has been solved.  The idea of measure twice and cut once goes back a long time.  However, that is precisely the purpose of software design.  In this case, the action is implementation instead of cutting, but it is nearly as final.  When you make the wrong cut on a piece of wood, you need to get new wood.  You can not “un-cut” the wood. Code is more forgiving; you can undo an action.  Unfortunately, we often realize that we need an “undo” far down the road from the mistake.  This leads to a lot of back-tracking, lost work, and potentially a duplication of effort or worse. A good design is likely to point out mistakes earlier when they are far less effort to correct.

I would be remiss if I ended this post without mentioning the Agile process.  The goal of Agile is to reduce overhead related to design and documentation, not eliminate it all together.  A proper Agile approach still includes planning; it just limits the scope to the upcoming implementation.  This can cause issues and turn up problems later than desired.  However, the trade-off is a more fluid approach to creating software and turning a presentation approach to something more like a conversation.  Agile assumes that we cannot correctly create a complete design from step one, but it does still embrace software design.

Next time you are pressured to dive into implementation have confidence in pushing back.  When you fight for the value of good design, you improve the chances of project success.  After all, that is the ultimate goal of everyone on the team.