Get out of the immaturity model (part 1) (posted by Fabien Villard)
“IT is a young discipline” syndrome
For as long as I have worked in IT I have heard this dogmatic explanation. It is used for all sorts of issues ranging from hardware failures to heavily bugged software including huge and astonishingly complex IT solutions without strong relations with business problems. Each time, the maturity idea was part of the explanation with the sense of “Don’t blame us for this failure, you know IT is so young, we have still to find our way…”. Failures, bad practices, big fiascos, stupid errors, are considered normal in IT because they are accepted as a mandatory part of the learning curve. It is also admitted that, being a new discipline born in the twentieth century, IT can not benefit from knowledge elaborated in other older disciplines. This is very pretentious and dangerous and by doing so IT has been making the same errors again and again during the last 30 years.
Examples? Oh, so easy, boy!
- Software licensing that guarantees nothing not even that the software will run, and preventing so much, including lending to relatives. Do you imagine not being able to lend your car to a friend or buying a fridge that may work, or not, without being able to call for refund, replacement or repair?
- All parts of the system depend on all other parts. Well, not really, but you never know so you have to be prepared to the fact that a change in one part will create failures in other parts. Try to imagine the maintenance of an Airbus A380 built that way…
- Where are blueprints ? In IT where we are trying to build more and more complex systems, we don’t have blueprints! Blueprints, or plans, are the representation of an architecture. Does that mean that we do not have architectures? Well, nearly. Think of it: it is now often considered a waste of time to even think about drawing blueprints. Well, you know, blue, this is not a good colour anyway…
- Documentation for software is reduced to a description of menu entries paraphrasing the title: “Files/Open: let you open a file.” Wow! Astonishing, really! But if you need to know how such a file is formatted and built? Well, just dig in the file and the code that writes it. Do you imagine car builders opening the engine to find precisely what voltage or fuel type a car they have built uses?
- Security gear is added on top of systems, not built inside. This suggests inevitably that security gear is optional which leads to a variety of failures we are accustomed to. Can you imagine a nuclear plant with security systems designed after the main design or even added after the plant’s build?
- Worse: if someone, let’s call her an auditor, requests proofs that an IT system is respectful of rules from real life, we can not answer. Rules do not appear clearly in systems, they are diluted across all sorts of artefacts including expressions that are complete re-wording of the rule, and each artefact only contains part of it. Would you entrust a health care machine built that way?
This is no longer acceptable
IT technologies are said to change very fast either hardware and software. And it’s true. So do aeronautics or health care technologies. We cannot accept badly designed IT systems because they are more and more involved in physical technologies and risks using badly designed IT system increase in our day-to-day lives. The conclusion is obvious: get out of the immaturity model and act as grown-ups.
[Part 2]
October 12th, 2011 at 12:57
[...] Isn’t it time to Get Out Of The Immaturity Model? [...]