Software Design is an interesting process as it requires, in most cases, a lot more forethought than your coding (often done on the fly). How detailed it should be depends like most things, on the size of the project and how complex it is. One thing that I am constantly trying to force myself to do these days is simpler designs. Just like diagrams are best kept simple to convey one thing well, a design should not try and convey everything.Trying to convey to much in a design forces you into spots that you may not want to be in if you haven’t thought about that particular aspect of the design long enough. The more you put into your design, the more rigid it becomes. The more you have committed to a particular design thought, the harder it is to let it go when the times comes.

Software Design is by very nature a tangible representation of a thought, or collection of thought processes. What’s the first thing you want to do with these thoughts? I normally run straight for the closest white board as they start flowing out :) Thought’s are fluid and often changing, hence the reason it is much harder to code from. Not to mention, without something tangible it is very hard to convey this information to anybody else. How much design required depends on how fluid the thought process is to begin with. How much does it need to be refined? What needs to be conveyed? The goal of which, is not to end up with something that won’t change. But to end up with something more concrete and set in stone than what you started with.

How does software design work in agile development?

Software Design is an iterative, ongoing, changing process and agile development recognises this. For this reason, agile development designs tend to be more emergent than the traditional up front rigid designs of other traditional development models. How much work invested in design initially (iteration0) is not enough to capture the whole system. But just enough to get things started.A design in itself doesn’t translate to anything if there is no implementation.

Implementing a subset of the design in the form of a user story and coding a set of intentions (how to use it) is much more useful.Just like the amount of design done up front is minimal to getting started, so should the documentation be. This does not mean neither exist, but agile focuses on value delivery for the customer.

In most cases (unless specifically asked for), customers pay for a working product, not for documentation that describes how the product might have worked or should have worked.

Agile development models and meta models allow and provide for a sufficient amount of change. So should your design. Make anything too rigid and it can fall apart very quickly as soon as the slightest wind of changes comes. Systems are rarely if ever understood to the point of zero change from conceptualisation to implementation. So, plan light, do the minimal required to get the job done. Add, change and expand on this as your understanding of the problem grows. There are always certain choices that have to be made up front, but minimise these to allow for a truly emergent design that will capture and reflect change.