Get out of the immaturity model (part 2) (posted by Fabien Villard)
[Part 1]
Here are some points to focus on to try to get out of the immaturity model. Some are obvious. Some may sound like weird ideas. But do not underestimate culture: obvious points may not be obvious for everyone and weird things may well be weird only for those who see them for the first time.
1 – Stop designing only by intuitions, start using analytical processes
Good intuition, or deus ex machina, may be an accelerator to make good designs. This is not untrue. But relying only on good intuitions is dangerous for more than one reason:
- We cannot count on intuition. Sometime it comes, sometimes it does not. When intuition is not there, or if the intuition is badly oriented, the design is also a poor one, or even a complete failure.
- Good intuition is dependent on people. If you have the right guy at the right place at the precise good moment, it may work like a charm. But how to do that apart from randomizing the design process? Some may say that selecting the best person for each task is an answer. Well, it’s right to some degree. But the selection process is very hard, the costs are high, and you can not be sure that this best guy will be there at the right moment, after all. There is a tradition to manage risks by people, and of course this is not the case in industries like nuclear plants or health care.
- Good intuition is not repeatable. The same person, even if it’s the best guy described above, may have different intuitions at different moments. How to be sure that one idea is a correct one, not speaking of the best one?
Intuition must be used with opportunism inside an analytical design process. The process must include ways to evaluate the correctness of the intuition and its adequacy with the current task and expected result.
2 – Stop considering blueprints as useless artefacts, start designing with models
In IT, blueprints are models. Without models, design can not be fixed when problems are solved. Without models, solutions are searched, found and tuned each time the problem occurs. Models have two main purposes:
- Establish clearly the results of the designing stages to avoid multiple thinkings about the same concern.
- Act as a non ambiguous documentation for further references.
They need some work and we have the bad habit to save time by avoiding this work. It’s a bad trade off; we pay higher prices by not having them when we measure all the costs of chaotic realisations, duplicated works and maintenance or evolution difficulties.
3 – Stop changing bad pragmatism into a virtue, start using theories and deriving solutions from established concepts
Pragmatism is the process that considers a good practice as a theory. In our business, a practice that has worked in a context is considered as an always-working practice, in all other contexts. This is very dangerous because the context is all. The execution of something is very dependent on the context, the environment in which it is executed, therefore eliminating context may lead to unpredictable results.
Because this kind of pragmatism seems a shorter process (the generalization phase is eliminated) it is considered simpler and cheaper. This is false, obviously. Promoting directly a local practice to other situations leads to a lack of knowledge in how the thing works, which brings a deep lack of control on it. Every time this approach requires special hacks, to react to otherwise predictable failures: they increase the complexity of the result and the overall cost.
4 – Stop thinking only with technologies, start using technologies as implementations of higher levels designs
Technology is not an answer to real life problems. Using technology is (well, often). The difference is important: using a technology implies the “for what” and the “How”. Exhibiting a technology as an answer without the studies to support the claim is like faith. But we don’t need faith in IT, we need science because we have to predict things. We have to show guarantees to our users and demonstrate our products and ideas before using them for real.
5 – Stop mixing abstraction levels, start to enforce the separation of concerns principle
Different abstraction levels respond to different concerns and have different life cycles. Mixing concerns and forcing a cycle into another one create dependencies that increase the system’s complexity and reduce control on it.
A clear separation of concerns is the solution to quickly changing ideas and technologies. If one abstraction layer has to be modified the adjacent layers can be used to limit the scope of the changes. This, for example, prevents from trashing all the system because the technical platform has to be changed.
6 – Stop building on sand, start to build on robust foundations
The metaphor is obvious: building a house on sand creates a high risk for the house and its occupants. Building an IS system on poorly designed requirements creates a high risk for the system to quickly become unusable (sometimes as soon as the first deployment). Building an IT implementation on poorly chosen technologies and weak architecture creates a high risk for the system to collapse when the context changes. Strong foundations are made of good architectures at all levels including enterprise level. And good architectures are made with methodologies, not just intuitions. Each product must be the result of a derivation process determining the goals to achieve and the way the product is used must be precisely related to the goal it targets. This is the base for building robust foundations.
7 – Stop denying human nature, start to learn humility
That’s the first condition for being able to built the discipline and improve one’s craft.
Sharp expertise in narrow domains is important but not enough. Every practitioner must be able to see things they build from a higher point of view in order to understand how its part is integrated in the wider scope of he system. This is important to acquire autonomy and be able to react correctly to unpredictable issues and bring guarantees in the process. This higher level of understanding is mandatory to efficiently articulate the number of expertises required to achieve a complex result. Learn and understand other disciplines and be prepared to share expertises without fear to become less knowledgeable. This is how practitioners will become able to work in highly skilled teams required to build complex systems.
September 27th, 2009 at 15:25
Great! This strong text should be a mandatory reading in the IT community, for hygienic purpose.
It is a pity that, after nearly three decades of software engineering, we still have to remind these basics.
December 5th, 2009 at 17:31
Dominique, yes, a pity. One reason being that the “waste” in this industry is only financial therefore not tacked. We often hear that more than 50% of the IT projects fail one way or another. And we are talking about hundreds of billions after all these years. If it was about manufacturing, let’s say for instance the production of tires, imagine the mountains of waste that this would have generate. Enough that the entire world would notice. To some extent we face a similar situation than global warming. Despite scientific evidence that we have damaged the planet and the situation is only getting worse every day, people are doubtful and don’t want to change unless there is a major crisis impacting their personal life. The same for software engineers. Even with the outsourcing/off-shoring fear…