Use Up-Front Design to Enhance Agility

Detailed up-front design can actually be used as a tool to increase agility. This might sound self-contradictory at first, but let s explore whether software agility really can be enhanced with the right kind of up-front design.

Manage Change

This might be seen as a controversial statement, but we believe that the best way to be agile is simply to do the following:

1. Develop software really quickly. Then there s less chance that it will need to change midproject.

2. Don t code each module until you have your design (see Chapter 8 for a discussion on knowing when the design has enough detail). It s much easier to change a diagram than to change source code.

   The easiest way to develop software quickly is to code to a known design. Then you know exactly how to get from A to B in the straightest possible line. Everyone is working from the same version of the same design, so there is no confusion.

   Developing software rapidly is effectively shielding the project from the forces of change. This is the bipolar opposite of the Extremo definition of agility we cited earlier.

   Of course, this doesn t make the project impervious to change. When change happens, you still need to be able to respond to it without the entire project shuddering and falling over.

   A couple more items could be added to the list:

3. Keep your design simple. Changes will be a lot easier to handle.

4. Break the architecture down into smaller modules, delivered separately in small increments ( ideally about a month each).

Simple design and small releases are also central to XP, but if we combine them with the first two items, the result should be a process that is lightning fast, robust, and responsive to change. We have our Holy Grail.

Refactoring the Design Before Code ”Surely That Would Be Too Extreme?

Yes, it s true. Refactoring is hard work, and when you don t keep your code in a well- factored state, it s just too easy to let that next iteration deadline creep in and keep you from doing the refactoring you need. And, you know, you can t ever have too much refactoring. Yes indeed, refactoring s a good thing, and so we can t have too much of it.

So we re going to introduce a new concept that we believe to be even more eXtreme and agile than Constant Refactoring After Programming. Because we re all agreed that the earlier we start refactoring, the better, what if we started our refactoring before coding?

Wow, you say, that really is eXtreme! I mean, how can we refactor code before code exists? Certainly we couldn t start refactoring before we have some stinky code to refactor, could we? Seriously, don t we have to code the simplest thing that can possibly work, and then refactor it?

But here s a thought: Every time we refactor, we have to write new tests and rerun all the old tests. Because we always have to keep the code in a state of 100% unit-test correctness. But what if we could refactor the design , without all the overhead of first writing bad, stinky code; and then making sure the bad, stinky code passes all the unit tests; and then cleaning up the bad, stinky code so it smells better and making sure that the sweeter-smelling code passes all of its tests, all the while worrying about that next iteration deadline for delivering new functionality that s always within a week or two of making us late on our stories?

What if there was time budgeted into the development process where we could think about getting the design right, without that next iteration deadline looming on the horizon? What if we had frictionless refactoring, where we didn t have all the overhead of testing and integration getting in the way of our refactoring? We could turn the dial all the way up to ten on refactoring! Wouldn t that be eXtreme?

 

Striking the Balance of Design Abstraction

Good design documents are much quicker to update and refactor than code. This means that not only can you refactor the design very quickly before the code is written, but also ”should you need to update the design once you have begun coding ”you can do so equally quickly. The robustness diagram, as defined in Chapter 4 of Use Case Driven Object Modeling , is ideal for this task.

The skill is in knowing how abstract the design should be. We sometimes see sequence diagrams where the designer appears to have tried to write a detailed program (with the minutest code logic) into the diagram. Diagrams are intended to convey sufficient information so that the program can be coded from them, ^[18] but they aren t intended to be the program themselves . In other words, they re written at a level of abstraction away from the code.

Getting the level of abstraction right means that the design can be updated quickly and minute changes to code don t render the design obsolete in a nanosecond. The design needs to be decoupled from the code but not made so far removed that it s meaningless. There is obviously a balance to be achieved.

FANGS  

Embracing Fangs

If it sounds too good to be true, it probably is. Changing the requirements during coding is expensive, and changing the requirements once the product has shipped is even more expensive. Always has been, always will be. Smell the hype.

Change Defanged

SOLUTION  

In any project, it s worth questioning how soon it really needs to go into maintenance mode (i.e., how soon the first live customer release should happen). If the reason for an early first release is simply to gain better user feedback, there are other ways of achieving this.

Rather than evolving the requirements based on a process of early feedback from the user, it s better to use more effective techniques to get the requirements in the first place. Use an interaction design approach, analyze the users goals, and gain the users insight into their ideal solution using prototypes and storyboarding techniques. The requirements will never be 100% correct at first, but we can nevertheless take great steps toward reducing requirements churn.

Similarly for design, effective up-front design techniques can help to reduce the need for Constant Refactoring After Programming.

That isn t to say that the requirements should be locked down once programming begins. Many projects have failed because the requirements changed (e.g., due to a change in market forces) but the project team didn t react . As with XP, the customer should be allowed to change the requirements at any stage, but he should also be made aware of the cost of such changes, and the effort should still be made to get the requirements right as early as possible.

 

^[18] And sequence diagrams in particular are intended to model a scenario ”a single pass through a collection of objects for a specific set of data ”rather than a complex web of conditional logic.