Risk-driven development 🧨
Software development processes in the 1990s have gotten a pretty bad reputation. (Largely for good reason, one could argue.)
The pendulum swings #
A lot of people became fed up with the rigidity (and often failure) of software projects run with these processes. This gave birth to what became the Agile movement, immortalized by 17 men through the Agile Manifesto. It put focus on collaboration and customer interaction over processes, and reacting to changes over following a well-defined plan.
Like it often does, the pendulum swung from one extreme to the other. While the 90s tried to design everything, many took the Agile movement as license for designing nothing. No “big design up front”, was the mantra. Just “do the simplest thing that could possibly work”.
And what is wrong with that? After all, isn’t it better to get something working and then continuously improve it? Well, yes. At least in theory. But all code is not equal.
Are we there yet? #
What often happens is that you do a very quick planning, and then start building something. You start with the “natural starting point” from a user’s perspective. Perhaps you create a first view in the UI and then implement a basic version of the underlying functionality. You then iteratively extend this by adding little bits of functionality. The hope is that this will eventually lead to a complete, working system. Doing it this way seems natural, and it feels good to get something up quickly.
The drawback of this approach is that we often find ourselves “half way” through the project and the scope just keeps growing. Or we realize that some of the assumptions we made at the start were quite wrong. As Tom Cargill put it, somewhat tongue-in-cheek.
The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.
Risk awareness #
While I don’t want the heavy processes back, I feel something from the 90s was lost – an awareness of risk. One of the most prominent processes of the 90s, the Rational Unified Process, talks about risk as follows.
For practitioners new to RUP, a common mistake during phase planning is to decide what functionality to add during each iteration based on the sequence of the use cases. This approach overlooks the risk-driven element of RUP; it means the practitioner does not understand how to combine risk-assessment and functionality considerations in selecting content for iterations.
What this says is that risk is an important factor when deciding what to do first. It does not say that it is the only factor to consider, but it should definitely be included!
Start with the hardest problem #
I think we should start by identifying parts of the project that are hard and important. The parts of the project which will virtually guarantee failure if we don’t get them right.
Note that it does not not have to be a technical problem. For example, if the team members do not know each other or are unfamiliar with the domain, then that may be the highest risk.
Another way to frame this is to start with the part which you expect to learn the most from. The best learning opportunities in a software project are not the areas which are easy, but the ones which you are not really sure how they will be solved. That is where most of the dragons live.
You could also consider it a “fail fast” strategy. If the project is going to fail because of unforseen complexity, why not fail as quickly as possible? 😉
To sum it up, I would like to make a case for “risk-driven development”. Identify the parts of your project with highest risk, and make sure to look at them early. Your project schedule will thank you!