Software is invisible, and that’s a problem

In the spring of 1987, the town of Alba Iulia, Romania, had a change request to their infrastructure.

They wanted to build a boulevard. The problem was that a 7600 ton building hosting 80 families was on the way. Of course they opted for the sensible solution that anybody would have thought: They split the building in two halves, with the families still living inside, and moved each half of the building 55 meters on each direction. People remained inside at all times, and just to prove a point, a woman decided to place a glass of water on the edge of her balcony. It didn’t spill a drop. The building remained connected to all utilities (water, electricity, etc) during the moving process.

In IT we do invisible things. Google is 2BN lines of code, Reading it at one line per second non-stop would take 63 years. And yet us users don’t see this, for us it’s just a web page which we use. How complex can it be? Surely not that much, after all my cousin’s son who is 15 years old is a whiz-kid programming in Javas.. This invisibility of IT has many unfortunate consequences, architects can learn from each other and appreciate the beauty of the technique in the buildings they create. Quality comparisons can be easily established at plain sight. Barcelona’s Cathedral La Sagrada Familia is obviously different to Kirchberg’s church. How to compare the code from google to the code from windows, to the code that runs my computer’s mouse? We can’t because we don’t see it, sometimes even if we would like to see it we can’t because it’s proprietary software.

Bad design of IT solutions brings misery to the users and elevated maintenance costs to management.

It is unintuitive for an end user to know the complexity of a change that he is requesting in the underlying platform.He could think he’s asking for something “standard/state of the art/our competitors did it” (build a boulevard) without understanding the invisible underlying complexity (move a building)

When a new requirement, or a change in a requirement comes in late, and must be delivered without taking the appropriate time to adapt the design. The solution will not be robust.

Let’s listen to our builders of invisible boulevards.



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s