Until recently, we have misjudged the nature of creating IT products. It was believed to be “complicated.” As a result, unsuitable methods for creating software have been developed, but in fact building software is not complicated at all…
In 2000, David John Snowden, known as Dave Snowden, finalized Cynefin. It is a model for categorizing situations in which you find yourself in order to help decision-making.
This model has 5 mutually exclusive domains (i.e. a situation can only be in one of these domains at a time).
Today, we will focus on two of them only.
The first is the domain deemed “complicated”. Here are some of its characteristics. In this field, cause-consequence relations can be established a priori. However, only experts are able to establish them. The consequence is that if we follow the recommendations of these experts, we get pretty much the result they had predicted.
Building a house is a complicated problem. Experts are called in: architects, materials engineers, and so on. If their recommendations are followed, we get pretty much the house they imagined. Cooking is also a complicated situation. If you follow the recipe and the chef’s recommendations, you pretty much get the desired dish.
That’s exactly what I asked for, but it’s not what I want
But building software products is not complicated, unlike building houses or cooking.
Indeed, it is rather a “complex” situation.
In Cynefin, the complex domain has these characteristics: the cause-consequence relations cannot be established a priori. Such relationships can only be established retrospectively. It is by seeing concrete results that I can tell myself that what I have obtained is the result of an act.
Often, complex situations are also described as adaptive. This means that seeking to respond to this situation changes its nature.
It is the exact description of building an IT product: people have a need, they order software. When they receive the product, it gives them other ideas, allows them to realize that some ideas they had issued previously are not relevant, etc. In short, the nature of their wish is modified following the software’s response to the initial situation. It was not possible to predict the new requests that would arise according to the responses of the chosen software.
A few years ago, I heard this sentence from the sponsor of an application during a demonstration that a developer was doing: “That’s exactly what I asked for, but it’s not what I want.” I then realized something. This is when I became aware of the complex and adaptive nature of software development. The development team had provided a correct a priori response to the sponsor’s need. He recognized that his request has been understood and even satisfied, but ultimately, the result was less than expected and made him want to change part of the application.
Bad tool, bad…
Waterfall development, or V-Model, is a response to a complicated situation. First of all, we call on experts in collecting needs, thinking that if we realize what they have formalized, we will obtain software that will perfectly satisfy the sponsor (e.g. the client). We then call on technical experts: architects, urban planners, etc.
The designations of these experts also illustrate what industries inspired the creation of this methodology. In the 1950s, when the first research to formalize a software creation methodology appeared (they gave the Waterfall model then the V-Model), we were inspired by known industries: heavy industries, public works and construction. However, we have seen above that the construction of buildings is a “complicated” situation, which is not the case of constructing software products.
These methodologies are therefore inappropriate.
What to do with experts?
In a future article, we will try to answer the question of the place of the experts if we change methodology, if we use their capacities differently and if we no longer follow their recommendations in order to deduce a priori cause-consequence relations.
This post has first been published on thefnublog.com.
No Comment