The effects of complexity and value on up-front architecture planning

Complexity versus size... and value versus cost.

What are the effects of each of these on up-front planning in agile development? I am presenting a paper on these results from my research at the XP2013 conference in Vienna next week.

Abstract:

A key feature of agile software development is its prioritisation of responding to changing requirements over planning ahead. If an agile development team spends too much time planning and designing architecture then responding to change will be extremely costly, while not doing enough architectural design puts the project at risk of failure. Striking the balance depends heavily on the context of the system being built, the environment and the development teams. This Grounded Theory research into how much architecture agile teams design up-front has identified system complexity as an important factor in determining how much planning a team does up-front, while system size, although related to complexity, has a much less direct impact. Furthermore, when determining how much design to do up-front, value to the customer can be a more important factor than overall development cost. Understanding these factors can help agile teams to determine how much up-front planning is appropriate for the systems they develop.

Submitted version

The final publication will be available at link.springer.com

The effects of size and complexity on architecture planning

Shaw and Garland opened their seminal book "Software Architecture: Perspectives on an Emerging Discipline" with this sentence:

"As the size and complexity of software systems increase, the design and specification of overall system structure become more significant issues than the choice of algorithms and data structures of computation".

That is, the bigger and more complex the system, the greater the proportion of time that needs to be spent nutting out the architecture.

Barry Boehm used his COCOMO II model to determine the effects of size of architectural effort in "Architected agile solutions for Software-Reliant Systems": the more time you spend architecting, the more time you add to the overall schedule (naturally!); conversely, the less time you spend architecting, the more time you have to spend on rework and fixing up architectural problems. Add those two curves together and you get a U-shape, with a sweet spot at the minimum (see figure 5 on page 7). The cost of rework is higher with larger systems, so your sweet spot moves to the right - that is, more architectural planning.

But do we see this relationship in modern systems being built using agile methods? Not necessarily, it appears. Architecture is changing: for teams using modern development frameworks (such as .NET, Hibernate, Ruby on Rails), architectural decisions aren't nearly as intractable as they were in the old days -- they can be changed more easily during development.  In fact, some decisions that used to be considered architectural may now be considered design decisions.

Frameworks do this by providing standard solutions to problems and therefore greatly reducing the complexity (and risk) of a system.  In effect, they are decoupling the relationship between complexity and size: a system may be large but implemented entirely using predefined components and libraries, therefore greatly reducing the complexity and architectural effort required. On the other hand, a small system may not be easily built using predefined framework components and libraries, and needs significant architectural effort.

So while size and complexity are related, it is not an linear relationship and it is complexity that is the true driver of architectural effort, not size.

And what's the corollary of this? Perhaps it is modern frameworks are an important enabler for reducing the up-front effort required in agile software development.

The relationship between requirements stability and up-front planning

Is there a relationship between how stable a system's requirements are and how much up-front planning teams do?

If agile means delaying architectural effort till the last sensible moment so you can better respond to change and have less rework, then perhaps we can assume that the more stable your requirements are the more up-front planning you can do, so you can get the benefits of an complete architecture design that has been better thought through.

But is this the case?

It doesn't seem to be. A highly agile team will still try to minimise its up-front effort, defining requirements later and making architectural decisions as close as possible to the time that they're needed. Even when they have fairly stable requirements, such as when doing a functional migration.

This isn't because teams are looking for an excuse to avoid up-front effort, but rather it allows them to focus on the high-value functionality rather than get bogged down in the detail and minutiae of defining a complete set of requirements at the beginning and losing sight of the big picture.

And anyway, even if we have fairly stable requirements, who knows exactly what's going to change in advance, and hence what can be left till later?