I never liked the bridge building metaphor very much and I know many software developers also didn’t. Many criticize the whole engineer thing and prefer the craftsmanship metaphor.
I can see value in both, but I wasn’t able to express what exactly was the problem with them. At least until a few days ago, when I watched this cartoon with my son about a tractor loader stacking numbered little cubes of various colors.
The building block metaphor
The first thing that came to my mind was the analogy of building software using components. If we think on these components as blocks, we can go even further. When we stack a block on the top of another or gather them side by side we can call the surface touching another block’s surface as the interface between them.
The problem is, in software, greater contact area between two components means coupled code that’s hard to change and maintain, right? However, real blocks benefit from friction and are more stable when they have direct contact with a greater number of blocks. While real blocks support each other, too much friction between software components makes them unusable.
So, when you think a little deeper in this analogy, you realize it didn’t work very well.
The bridge metaphor
Going back to the bridge analogy, after having watched that cartoon, I realized a subtle but crucial difference between a real bridge and that one that fills the gap between client needs and running software.
When professionals build a house, a building, or a bridge they go to the physical place, inspect, measure, do the calculations, bring the material, put each thing in their place. If some material is missing, they just buy more. If something is not fitting in, they just tweak it. When they finish it, they can see exactly whether they met the expectations or not. Of course a bridge can fall, someone can do incorrect calculations, but in general engineers are somehow able to assess its stability.
What can I say about software development? It’s abstract. It can’t be seen. It can’t be measured properly. You can test it in some manners, but it doesn’t guarantee it’s correct. But you already knew about all these characteristics, right? Yet there’s something perhaps you have missed, as I did. That is, in software, we don’t just build and delivery.
Actually, we do not build a bridge at all. What we really build is an abstraction. Not an abstract bridge. We build an abstract bridge builder.
At low level, every time an application is executed it builds a concrete bridge. That bridge needs to fit perfectly unknown places and shouldn’t fall under uncertain weights. In another words, it brings and loads and gathers and connects all components, and when they’re ready it’ll do whatever it was designed to do.
So a software bridge is more like a bridge you can carry in your pocket and use whenever you need to cross some valley or river. Depending on the user, he/she will complain that bridge won’t take them from America to Europe.
And about the Mona Lisa?
I think we can apply the same principle to software craftsmanship. Think for a moment. Even if we switch to this analogy, with developers producing binary masterpieces and programmers painting Mona Lisa’s, it doesn’t change anything in the nature of that problem.
We’re still making an abstract artwork builder. When the software runs, it should creates instantaneously a masterpiece according to the instructions of its master.
Is there a proper analogy?
Sorry for disappointing you, but in fact I have no idea. 🙁
On the other hand, I have strong reasons to think that much of our problems in software engineering will be solved by finding the right analogy.
As cubes and rectangles and circles are properly used as abstractions to build bridges and paint masterpieces, it there should be proper abstractions to software development.
One thing I do know
As software developers (engineers or craftsmans) we should be simple. We need master simplicity.
I think it’s clear for anyone who have ever worked with software that complexity should be avoided at all costs. It’s not by chance the latest frameworks and tools and processes and methodologies and techniques try to be as simple as possible.
Nevertheless, I have something against them. They’re becoming too shallow.
For instance, I’ve seen many people doing agile because they hate documentation. But throwing it away won’t solve their problem. I’ve seen many new flavors of tools and frameworks and methodologies that do exactly what the existing ones do, except for promising they’re easier. I’ve seen people that hate everything that seems to be old and love every novelty though they have no clue about the reason.
They just want to work less. They just want to think less.
We’re living the era of lazy programmers. But not the kind that would automate repetitive tasks, as noticed by Steve McConnell in his book Code Complete, or avoid useless documentation. Unfortunately, there are plenty of lazy programmers today that don’t even want to understand the problems they face. They want some magic easy solution so they don’t need to think and do the hard work.
Simple but deep
When you have a problem, there’s basically two alternatives: ignore it and hope that soon or later it’ll disappear, or face it and do whatever it takes to solve it.
Despite many advances in the field, I think we’re still living a software crisis. I see many companies and professionals completely lost having so many options to do the same thing, while others jump from technology to technology by a matter of taste.
Well, I have my personal taste for programming languages too, but that’s not the point. I’m talking about the fundamentals. I think people are just attacking the wrong thing. They’re ignoring the real problem.
It’s not sufficient to make things easy and cool without solving the real problem.
Software development today is simpler than some decades ago. Nonetheless, as spotted in Brooks’ Mythical Man-Month, it happened because we overcome the accidental difficulties of programming. We have now better debugging, rich-featured IDEs, faster personal computers, and son on. But few initiatives attack the essence of the complexity in software development. And here dwells our biggest challenge.
In order to make software development even simpler, it’s necessary to dig deep into the dirty of complexity, face the hard things, try solution after solution, year after year.
We need people that do not put blind faith in new tools and methods, that aren’t lazy to do whatever needs to be done, that really understand what they are doing. And we need people willing to persist in this direction, instead of being apathetic and choosing the easy path.
Only those who discipline themselves in this craft will be able to provide us with a real improvement in software development some day.
