Basically, the Waterfall development methodology.
For a bridge, this approach still works very well. And this is because the construction of a bridge typically respects these characteristics:
- it has precise requirements (what should be done, for how long it should last, etc.);
- the requirements do not change during construction (it is rather difficult to imagine that the client, with work in progress, says something like: “Listen, could you get it 1 km further downstream?”);
- for future modifications or extensions;
- if there are any doubts, they are known: i.e., I don’t know how many kg/m2 that foundation can hold, so I know I have to to find out;
- building the bridge is much more expensive than designing it.
Furthermore, realizing a wrong design choice would imply going back to some phases of the construction that could be impossible to modify (what if, after starting the construction of the road, you realized that you needed an extra pillar?).
Obviously, this is not an absolute truth: even a bridge may be subject to modifications during construction, or future renovations. However, they will be expensive, and their cost will be difficult to predict at the time of construction. Sometimes, rather than renovating an old bridge to make it more modern and capable of driving more cars, it’s more convenient to rebuild it from scratch.
We can say, in short, that bridges follow a construction method that optimizes the initial realization, to the detriment of future developments. Now, this can be considered an excellent system for making hardware (and I would say that a bridge can be regarded as a nice piece of hardware), but we produce software, right?
Are we sure we can apply the same system
Well, let’s see which of the five factors mentioned above are typically respected in a software product.
1. Precise requirements.
Nothing like it. Usually, the requirements become clear as the product takes shape. And since we prefer to make our users happy rather than tell them “You signed for this 6 months ago”, the continuous feedback from users is much more important to us than the initial negotiation of the requirements. (Customer collaboration over contract negotiation – Agile Manifesto).
2. Stable requirements.
No: it happens all the time that some requirements change during the development, new ones come out or that which at first seemed indispensable end up being excluded. The market changes quickly, the needs change quickly, so the software must change accordingly (Responding to change over following a plan – Agile Manifesto).
3. Changes in progress.
Modifications and extensions are a daily occurrence when working on a software (think of all the news included in each release of our products ).
We are aware from the beginning of not knowing some aspects. But we discover other flaws the moment we encounter them. A bit like saying: if you know you don’t know, feel lucky…the problem is when you don’t know you don’t know (little spoiler, we’ll see shortly that it’s better not to try to solve even the doubts we have in advance!).
5. High modification cost.
This is the only point that could be common with the bridge, and it’s the one from which we want to stay further away. If we happen to have a software that should be redone rather than extended, it would mean that the software became unmantainable, and we should understand what went wrong to avoid this situation in the future.
So, apparently, the upfront design, which is well suited for building bridges, doesn’t work very well with software products.
Designing the entire product before starting its development, in fact, has a number of easily identifiable disadvantages. Creating an hyper-extensible and super-abstract product is an expensive exercise that risks creating unnecessarily complex abstractions (KISS); the extensibility on which the investment was made could prove to be useless or excessive if we found out that a lower or much simpler level of abstraction was sufficient (YAGNI); and, in any case, it is complicated to predict what the requirements will be and to understand whether extensions will be needed and at what stage of development. Even if you try to do it, it’s very easy to go wrong, ending up wasting a great deal of time and money.
The solution is there: let the design emerge.
Let’s see how.