The Parable

A person had a problem, and asked a Project Manager to help.

Following a wise methodology, the Project Manager:

• clarified the nature of the problem, and what a solution would look like;
• defined the solution architecture, identifying the main parts and the relationship between them;
• built only as much as was needed at each step;
• created each unit and its test suite together;
• used the experience of building to test, clarify and discover assumptions;
• when assumptions changed, revisited and revised the unit, the architecture, the solution and the problem statement as required; and
• continued building and testing and checking until the project was complete and the problem was solved.

The Thought

In the world of IT, we are talking about Agile software development.  But this approach to managing software development can usefully be applied to the rest of life, too.

All too often, when trying to solve a problem, we take the problem statement as a given.  But the problem statement we start with, like everything else we have, is only the best we could come up with at the time: it was helpful, it was probably good, but it was almost certainly not perfect.

When you have a non-trivial but solvable problem, there are four basic steps to the solution.

1. State the problem - clearly and unambiguously, so you - and others - can recognize when it has been solved
2. Describe the solution - say what is essential, what is desired, and what the constraints are; say what you want, not what you dislike or what you think should be done.
3. Design a solution - identify the major aspects, and describe the relationship between them, define the interfaces.
4. Build the solution - only build what is needed right now, and use the real world experience gained to test what has been build already, and the assumptions made along the way; change anything that needs changing, either in this step or any of the previous ones; ensure that what you build is tested quickly and easily - you want to find mistakes and weaknesses as early as possible.

It's not rocket science, but it is hard work.  In the real world, what usually happens is something like this...

• Someone tells you he wants to get from A to B, so you design him a bicycle.
• Then he says he needs to get there quickly, so you design a motorcycle.
• Then he says he needs to take some boxes with him, so you add a trailer to the motorcycle.
• Then he says he needs to bring his three children with him, so you design a motorcycle with trailer plus three smaller, three-wheeled motorbikes which can be programmed to automatically follow the bike in front.

Of course, if you knew the actual requirement at the outset, you would have designed a car.  But you start with a sensible plan, and with each new detail, you modify it to handle that new aspect.  You rarely go back, and re-think the plan in the light of the new information.  Of course not - it would take too much work, and it would create delays.

Whatever technology you are using to address the problem, what kills the solution is generally not the technology, but the way the problem (as it has been described to you) changes as you try to solve it.  The same process kept repeating, whether I was trying to build computer software or help drug addicts get clean and start a new life.

Whatever the project, there is never the time and money to do it right, but there is always the time and money to fix it when it is done wrong.  The problem (a problem, at least) is the eternal optimism of management: "This project is different - we understand the problem well enough, so we will get the solution right first time.  Promise!"