Engineering Beyond Software
We software engineers are puppies when it comes to engineering.
Building stuff for us is still largely a matter of instinct and luck. Yes, we iterate fast—because we don't get it right the first time. You can see this all around: Frameworks replace each other within a year, so do entire languages, and patterns and anti-patterns, methodologies and processes pop up like mushrooms, with every six months a new savior being hailed. Agile coaches recommend against even estimating, because we just can't do it.
There is a thousand different ways to build a simple web page—not even the rough approach is sorted out, from generating static pages over dynamic generation to a hosted CMS, everything goes.
It's fiddling, really.
Now, I'm being harsh of course. There are people committed to address exactly these problems, and there are companies that have figured out how to deliver their products reliably. In tiny projects, we do reasonably well. An off-the-shelf mobile app can be produced without a 100% delay. DevOps is also about acknowledging that engineering is not the same as coding. But by and large, our field is still figuring things out, the basic things. That's because we are—again—puppies. Software engineering is a young field.
For perspective, let's look at other engineering disciplines. Here's part of the Roman aqueduct of Nimes:
To supply the city's 50,000 inhabitants with water, each day it transported an estimated 200 million liters from the Fontaine d'Eure to the city's basin, over a distance of 50 km. Without pumps the Romans had to rely on the water flowing downwards, but even so the aqueduct descended a mere 17 meters over the entire distance. To get the water over the Gardon river, they built the illustrious Pont du Gard at a height of 48m.
And because that height really complicated things, at one stretch the water descended only 7mm per 100m. Have a read at the details in the Wikipedia article; it's amazing what they had to make work in order to get drinking water to Nimes. Oh, and that aqueduct was built two thousand years ago. And the Pont du Gard still stands today.
Making this aqueduct work was not entirely a matter of luck, of course. Romans had clear ideas on how to get water from the source to the city. Around 100 A.D. Roman senator Julius Sextus Frontinus, appointed Water Commissioner, wrote De aquaeductu. In it, he gives a systematic overview of Rome's then current water supply system and along the way some insight into how it's being built and maintained.
Unsurprisingly water throughput gets it's fair attention in the treatise. Over the decades the Romans figured out the art of leveling the conduit, to maximize the yield. (Interestingly, when attempting to measure water pressure Frontinus was rather off the mark, for example largely ignoring water speed or friction.) The differing water quality of the source determines how the water is being used and which streams can be allowed into the same conduits. Catch basins are being used to clear the water. Public health is being considered, when weighing earthen versus leaden pipes. In ancient Rome, water was just as precious as ever: Thieves drained it along the way and enemies targeted the water systems to succumb the city, so vulnerable stretches needed to be hidden, protected or guarded. Maintenance crews were established, in the city and afar, ready to reroute water in case of outages and repair breakages. A Senate resolution is appended to ensure these water men have access to the conduits. Frontinus even makes recommendations for how to schedule downtimes and how to avoid them by building temporary leaden circuitry. And beyond all that, issues as taxing water consumption and issuance of water-rights are addressed.
If that sounds like the recipe of a great computer game to you, have a look at how to Construct an Aqueduct, or make it a team exercise. ;)
So, yeah, we know how to build and maintain physical things. We've been building houses for millennia, have been constructing vehicles and bridges for almost as long. Even modern, highly complex structures such as skyscrapers have been around for more than a century. And software? Well, there was the “Baby” computer, barely 70 years ago. And complex software really taking off in the 70s. That's not long. So, let's give us another century and maybe building software will no longer be as fluffy as dreams and hopes, but straightforward: the trade-offs between the few reasonable design choices clearly understood and the choice obvious, dictated by the requirements.
How do we get there?
I think, by showing a measure of humility; we are pupp… alright, alright, you get it. Let's listen to experts from other engineering disciplines how they have been doing things.
That's what the “Beyond Software” talks are about, which I am organizing at engageSPARK semi-regularly, basically whenever I can find a volunteer speaker. The idea is to invite architects, mechanical engineers, project engineers, interior designers, QA from production plants, construction site managers and learn about how they plan their projects, how they manage teams, how they ensure and measure quality, etc.
Let me know what you think! Please give me ideas for how to improve this, for useful videos to watch, or links to similar undertakings. See you at the next “Beyond Software” talk!