Why people think software is so much easier than it really is
New software is
A colleague works outside IT and seems to have a pretty good grasp of how complex IT really is. I mentioned to this person that sometimes a customer will, upon seeing “what they really wanted”, simply shake their head and say “what took so long”, blithely ignorant of the complexity involved. My colleague was, well, almost aghast that someone could think this way, and said “I’d not have thought people would be that, I don’t know, ridiculous? Why would anyone presume something like ‘oh that, yeah, you can do that!’ if they can’t do it themselves? That seems an awfully strange way to think (using the word very casually there apparently)”. This is my extended answer to that question.
I think it has something to do with how usable and useful our tools have become: I think we have an implicit appreciation for the complexity “under the hood” (and that can be meant quite literally), inchoate and rarely if ever articulated, but we lack any kind of context for that complexity, any kind of appreciation for the years and in some cases decades of work required to hide that complexity under aesthetically pleasing veneers, be they body panels or airbrushed aluminum cases.
For example, how complicated was it for you to start your car when last you drove? Was there risk of injury?
Until Charles Kettering invented the electric car starter, a saga in and of itself, given the complex mechanical and electrical engineering required, car owners were advised to grip the starter crank handle with their fingers and thumb on the same side of the crank and to pull up. Why same side? To reduce the risk of a broken thumb or wrist or worse in case a backfire caused the crank to suddenly reverse. At immensely higher speed and force than the human had applied in the desired direction.
And this was a commercial product that sold really, really well.
Likewise, think of your independent suspension, automatic transmission, fuel injection, etc., etc., etc.
We know it’s all there, we sort of grok that is fantastically complicated, but since we don’t get how hard it was to solve each individual problem, we take it for granted.
And it doesn’t break! That’s practically a freaking miracle. Ask me why my Jeep has solid axles some time.
A computer is possibly thousands of times more complex than a car (though far less deadly). Again, we grok the complexity, are ignorant of the effort, and take it from granted.
Since we take it for granted that some smart person somewhere put all this complexity in a box, we assume it must be easy for one or two more smart people to add even more complicated functions.
We miss the fact that it wasn’t one smart person that put it all in a box, it was a veritable army of armies, over decades. So we underestimate the effort to improve.
Did you know that rocket engines - and all of their supporting infrastructure, fuel tanks, fuel pumps, etc., etc. - are all engineered to resist the destructive effects of fuel? Rocket fuel is so chemically reactive than it destroys the very vehicles it is powering, so part of the engineering is figuring out how to get fine propulsion control while making the parts as close to indestructible as they can reasonably be and still be light enough and cheap enough to put into the vehicle in the first place. Part of maintaining any shuttle was deciding which parts to replace; there were parts that were replaced every single mission, others every few. Very few, perhaps no, elements of the propulsion system would have lasted the lifetime of any specific shuttle.
And there is another factor, a psychological one.
Until someone gave you a computer, you had no idea what you could do with one.
Then you got one, and went, oooh.
Then they gave you Internet, and you went ooooooooh.
Then they gave you a mobile phone, and you went oooooooooooooh.
Each time the next new thing comes along, we make a few leaps of imagination: “Well, if it can do that…”
Then we find the constraints, and are a little disappointed, but we still have leaps.
Then another new thing, a leap, some constraints, some disappointment.
Repeat.
Finally, after years of effort, the work of an army of teams and of a few outstanding individuals comes together, and we finally get a device that does something close to what we imagined but could not articulate, years before. And our reaction is “FINALLY! What took you guys so long?”
Now, tie together the two lines of thought, the complexity of engineering and the user psychology, by remembering that the vast majority of humans, especially the vast majority of managers, senior managers, and executives, deal with problems of managing people or machines as cogs: Learn to manage a team, get good at it, learn to manage a team of team leaders, get good at it, learn to manage managers, get good at it, etc., etc.
There are additional nuances and subtleties at each level, new skills, and new layers of abstraction, but one has to be very high up the chain before one gets to complexity on a scale comparable to what senior technologists deal with. Everyday.
A colonel or brigadier has a lot more riding on their decisions in terms of immediate consequences when directing their regiment or brigade in battle, but they have trained and drilled for weeks and months and years, and the overall operations are not that complex, compared to what happens inside many of our machines. Especially our networked machines.
An engineer signing off on the design of a bridge is dealing with something a lot more complicated. If they get it wrong, almost as many people could die as in a battle.
An engineer signing off on the design of a commercial passenger aircraft is dealing with something even more complicated. If they get it wrong, many, many more people could die than as in a battle.
But we all see and appreciate the complexity of the senior officer’s job, and the immediacy of the impact of error or poor decisions, so we assume it is the harder one, the more stressful one, the more complex one.
And we get that wrong.
Pretty much every time.
And we assume in our ignorance that the really cool thing that we just had delivered and are now charging couldn’t possibly have been that complicated, was just a matter of time, because we reason about using heuristics and yardsticks that just don’t apply.
But wait, there’s more.
Every time an engineer designs a bridge, they are essentially doing what hundreds and thousands of people have done before. There really isn’t anything new in bridge making, it’s incremental change over all previous bridges. Any new tools and techniques are created to enable a specific end, making a better bridge for less money.
Every time a software developer creates a new program, they are creating something net new that never existed before. Sure, they may use code and libraries written by others, but those were written not to enable a specific end, but any and all ends. Often, the thing they write is similar to what others have done, but software developers are lazy, they try to not duplicate what others have done. Everyone wants to work on net new as much as possible, and the newier the better.
The more they work at the pointy end of problem space, the more novel and more newily new is the net new they create.
And that is the crux of the perception problem: Customers and managers without software development experience, whose entire existence is about maintaining or incrementally improving things we’ve been doing for a long time, simply lack the context and understanding to appreciate the novelty and complexity of the net new that comes with every new piece of code. And the newest and shiniest pieces of code are as far from the mundane new as the mundane new is from mundane maintenence-or-increment experience.
So when we finally get the right pieces of code assembled in the right way, a common reaction is “what took you so long?”
And now you know why.