Perfection in the IT – or “less is more”


Just a thought …

A few days I read the following citation:

“Perfection is reached not when there is no longer anything to add, but when there is no longer anything to take away.” (A. Saint-Exupéry)

I thought about it for a while and from my perspective there is a lot of truth and wisdom in this short sentence. But then I started thinking about IT …

One should think that confronted with more and more complexity we should strive for that kind of perfection by getting rid of anything that we do not absolutely need to accomplish our goal. At least that is what I would expect. But when looking around most of the time I see exactly the opposite. We pile up more and more complexity around us no matter if we need it or not. Just to name a few examples:

  • To make things more comprehensive we invent new elaborated templates for everything and anything every day, starting with more than detailed requirements templates and ending in support processes that take several hundred or thousand pages of description … templates and rules that take weeks and months to understand and that make sure that the content is way much harder to understand than it was before … at least for the “normal” people.
  • To avoid ambiguity we create models that would take up whole walls to show them. No one will ever understand them altogether, but still we create them. And if is not enough we start creating meta models and meta-meta models to make sure that we lose the last people who had an idea of the model.
  • By trying to get things done easier we use products that have so many features that we will probably never use more than 3% of them … and we also integrate those products in our application landscapes.
  • To save a few keystrokes we plug so much stuff into our IDEs that no one knows anymore what is going on “backstage” and we are lost in all the “magic” that is going to happen.
  • Again in our never ending search to get things done easier we create so many frameworks and we are so keen about using as many as possible in one application that we are completely lost in understanding the technology and resolving all the resulting integration issues and do not have any time left to deal with the applications purpose – you know, that “business stuff”.
  • With all those tools we create applications of such a complexity that no one really understands anymore what is going on inside the application, neither the users nor the poor developers who try to implement a new feature within those code nightmares without breaking the whole system.
  • And just because we can and some business department guy or lady thinks this might possibly become useful some day we interconnect everything in our application landscape no matter if it provides real business value or not, this way creating a web of dependencies that no one really understands anymore.

I could probably go on for hours, but I think you got the point, and I am sure that you could instantaneously add some more examples. We regularly succeed in turning something simple into something complicated by adding more and more stuff to it no matter if it serves the goal or not, until it develops complex behavior, i.e. that it becomes incomprehensible and unpredictable.

By trying to deal with the limits of our brains or sometimes just because of our laziness or our fear of decisions we pick the worst alternative very often: We add complexity instead of removing it.

When I look at this trend within the IT that everything becomes more and more complex I think it is urgently about time to change course. Instead of complaining about more and more complexity around us we should try to avoid it wherever we can. Again, just to provide a few examples:

  • No one requires us to do things as formal as machines. We are humans and we should interact like humans. Yes, we make mistakes because we are human (it’s part of our nature) but altogether we do not make less mistakes if we try to behave and communicate like machines, i.e. more and more formal.
  • Nobody needs models that no one understands. A model serves communication in the first place, the sharing of knowledge; and if nobody understands it there is nothing to share. I would rather have a simple model that I can share with everybody than a complex model that cannot be shared, no matter how precise it is.
  • Nobody urges us to use every plug-in for our IDE and every framework for our application that is around. I had a colleague a lot of years ago when design patterns were “all the rage”. He proudly told us one day that he managed to implement each design pattern of the “gang of four” book within his code. Alerted by this statement the rest of the team took a look into his code. After doing this we decided to throw away all the code that colleague ever wrote for the project and to rewrite it from scratch because it was brittle, error prone and not maintainable at all. The same thing usually is true for your IDE and your source code if you use too many plug-ins or frameworks or whatever.
  • And do we really need to implement each and every requirement some business guy or lady postulates without questioning it? I mean it is the very own right of the business departments to ask for everything and anything without thinking about the consequences it might have on the technical side. It is not their job to think about the technical consequences and usually they do not have the required knowledge to do that. But it is our job to talk to them, to show them the consequences (in a non-technical language, please), to show them alternatives, to help them to make the best decision by showing them the whole picture. And quite often they will pick the best alternative then, one that is quite often less complex than the initial one.

However, this is not a black or white story. There is not “the” solution to our dilemma and simplification beyond recognition does not help either. But I think it is about time for all of us to avoid complexity wherever we do not need it, that we try to push back to the amount of complexity our brains are capable to deal with. Or, to close this with another citation I like a lot:

“Less is more!” (Mies v.d. Rohe)

As I said at the beginning: Just a thought …


  • Gordon



    “Simplicity—the art of maximizing the amount of work not done—is essential.”

    As Uncle Bob puts it .. http://www.amazon.com/Software-Development-Principles-Patterns-Practices/dp/0135974445

    “Agile teams do not try to build the grand system in the sky. Rather, they always take the simplest path that is consistent with their goals. They don’t put a lot of importance on anticipating tomorrow’s problems; nor do they try to defend against all of them today. Rather, they do the simplest and highest quality work today, confident that it will be easy to change if and when tomorrow’s problems arise.”

    Of course this confidence flows from creating quality well-factored systems / designs .

  • Paul W. Homer

    Yes, this drives me crazy too.

    Everybody is running around trying to show how smart and pro-active they are, but the consequence of their actions is just making things worse. Adding complexity is not the same as fixing something. We don’t really need more code, or more features, what we need is for our tools to be integrated in a fashion that they make our lives better. We’re building too much on a house of cards, it is unstable and unlikely to work as we expect.

    And there is always a new set of ‘best practices’ that people have haphazardly put together, which on their own seem reasonable, but together they don’t really help or even make things worse. Best expression I’ve heard lately is “wisdom is knowing when to break the rules”.

    We live in an age of stupid complexity, and too much mis-information.



Your email address will not be published. Required fields are marked *