How do we minimize complexity and rework in an Agile project?

Sorry, flash is not available.

A common question from Agile developers is – “how can I avoid over and under design?”  That is, while I know that I don’t want to overbuild my system, I also don’t want to be hacking in my solutions.  We believe the solution to this question is building only for what you need at the moment, but building in a way that can be readily changed when you discover new issues. 

You want to build the code only for what you need because we are all pre-cognitive impaired - that is, we are not pre-cognitive, even though we often act like we are. Building for more than you need invariably leads to more complex code than necessary.  This complexity will slow you down.  We need the abilities to:

  • Write code quickly
  • Make changes to our code without breaking it
  • Be able to change our code safely

You can tell if your team and code have these abilities by your answers to the following questions:

  • Can you easily change your code?     
  • If you change it, are you likely to break it?
  •  If you break it, can you automatically detect the break?

The only way we know to get safety is through a full set of automated regression tests.   These are very important and one thing we strive to achieve as soon as possible. See Michael Feathers’ excellent “Working Effectively With Legacy Code” for more information on how to do this.  The ability to be able to change code quickly without breaking it requires good design.  Design patterns are an essential part of any competent developer’s toolbox.  Unfortunately, these are little understood (or more correctly, largely misunderstood).  Their quick definition of “solutions to a recurring problem in a context” is misleading and even recanted by the creator of it at the end of his book (Christopher Alexander’s phenomenal Timeless Way of Building. Patterns have been more misused than used, we are afraid to say.  Patterns properly used are about resolving issues of variation in a problem domain.

In working with dozens of clients, we are afraid our industry does not measure up to the test.  We say this because of the almost universal answer we get to the following question:

“Imagine you are working on a well established system and you need to add some new functionality.  Where will you spend most of your time – in writing the new functionality or in integrating the functionality into your existing system?”  For the last 10 years we’ve been asking this question we have consistently been answered 95% of the time with “integrating it in.” 

We believe this is because people don’t write their code to be changeable.  Instead, people are focused on implementing the task at hand and don’t recognize when they should put in a design layer and when they shouldn’t.  Putting layers in your code wherever possible is a path to over-complexity.  But not putting in layers when you need to is a path to code that is both difficult to change and brittle.

The trick in knowing when is to add layers as soon as they are needed, but not before.  In practice, this means to create an abstract layer when you get two ways of implementing the same concept.  While this requires a modest amount of refactoring when this layer is first needed, it rarely costs more to put in at this point than when you first could put it in (and it wasn’t needed). While this causes some refactoring, we prefer to think of this as just-in-time design.  In other words, developers should write their code with as high quality as they can get without anticipating the future – that is, don’t handle cases that haven’t arisen yet.  Doing so will have you have high quality code with a good design.  Now, when a new requirement comes along that requires the extra design, put it in.  You’ll be surprised to discover how little this actually costs you to defer.  The savings are great, however.  You don’t put in these design changes until they are both needed and better understood (you now have a second case to handle – therefore your interfaces will be better defined).

To further your studies in this area:
There are a lot of resources available to developers at our technical resources page.  Many of these you will need to register to get access to, however.  Here are some suggested starting points:

If you are interested in learning how Net Objectives can help you achieve Enterprise Agility through our combination of an assessment, training and coaching, please contact us by clicking here.

For further information on how to address these issues, read Portfolio Management from our upcoming book Lean-Agile Software Development: Achieving Enterprise Agility.  You can also find several articles and webcasts on this topic on our Lean Resources page.  *Note, you will have to register to get at some of this content.