Although the agile manifesto promotes the idea that “Continuous attention to technical excellence and good design enhances agility”, there’s been a movement in agile project management away from up-front software design. While it's generally accepted that requirements will change during most projects, and therefore big design up front no longer makes sense, the other extreme is not desirable either. No up-front design can result in a mess that reduces agility, a mess that is increasingly expensive to correct as the project progresses and often hidden from the business. It can happen even when developing within frameworks like Ruby on Rails, ASP.NET, J2EE, and Django that provide some design ‘out of the box’. Even when using code refactoring tools. Designing up-front for change, on the other hand, can be lean and help maintain agility, even as the code grows. Designing for change includes identifying units of functionality, considering which are more likely to change based on competitive environment or end user needs, then isolating them into logical parts in such a way that those less likely to change are not dependent on those that are as much as possible. For those who want to get a glimpse of how this looks under the hood, this presentation illustrates some common examples of software designs that improve agility.
Frameworks that provide design structure take care of some of this, but not all. Applying design practices like identifying, naming, and capturing the properties (as much as possible) of the units of data in an application up-front, for example, can return dividends from day one that further increase with time. Not doing so can easily result in data units that are ambiguously named, vary by developer, and even overlap with one another. It's not hard to imagine that after even a few thousand lines of code the time cost to change these units goes up and from there just keeps rising. After all, even with software tools that make changing databases easy, there's still all the surrounding code that has to be dealt with.
Some up-front design really can go a long way to improve agility and there are sensible, lean ways to go about it. Since doing so isn't popular at the moment, however, it may be something you want to make sure is happening on your projects.
What's your experience with adaptable designs and maintaining agility as your software grows? What's your team doing to avoid a mess? Please share your thoughts and experiences in the comments below.
