One of my greatest curiosities over the last thirty-five years, while building complex software, is why construction projects for skyscrapers, which are highly complex beasts, seem to go so much smoother than software projects, most of which are far less complex.
When I was young, legend has it that at least 50% of all software projects would fail to produce working code. On top of that, most of what did eventually work was of fairly low quality. People used to talk a lot about the huge risks of development.
Since then, there have been endless waves of ‘magic’ with bold marketing claims, intended to change that, but it seems that our modern success rate is roughly similar. Of the projects that I have seen, interacted with, or discussed with fellow developers, the success rate is poor. It actually seems to have gotten worse. Although outright failures are a little less, the overall quality is far lower. Balls of mud are commonplace.
At some level, it doesn't make sense. People can come together to build extremely sophisticated things reliably in all sorts of other industries. So why is software special?
Some people claim it is because it is purely “digital”. That makes it abstract and highly malleable, somewhat like jello. But somewhere, the rubber always meets the road; software sits on top of hardware, which is entirely physical.
Computer systems are physical objects. They may seem easier to change in theory, but due to their weight, they more often get frozen in place. Sure at the last layer on top, close to the users, the coders can make an infinite number of arbitrary changes, but even when it is actual “code”, it is usually just configuration-based or small algorithmic tweaks. All the other crud sinks quickly to the bottom and becomes untouchable.
You can fiddle close to the top in any other medium. Fiddle with the last layers of wood, concrete, rubber, plastic, or metal. Renovate the inside or outside of a building. So that doesn’t seem to be the real issue.
Another possibility is the iceberg theory. Most of the people involved with building software only see the top 10% that sticks out of the water. The rest is hidden away below the waves. We do oddly say that the last 10% of any project is 90% of the effort, which seems to line up.
I used to think that was just non-technical people looking at GUIs, but it even seems true these days for backend developers blindly integrating in components that they don’t really understand. All other forms of engineering seem to specialize and insist on real depth of knowledge. The people entrusted to build specific parts have specific knowledge.
Software, because it has grown so fast, has a bad habit of avoiding that. Specialties come and go, but generalists are more likely to survive for their full careers. And generalists love to ignore the state of the art and go rogue. They prefer to code something easy for themselves, rather than code things correctly. They’ll often go right back to first principles and attempt to quickly reinvent decades of effort. These bad habits are reinforced by an industry that enshrines them as cool or popular, so they can sell pretend cures to fix them. Why do things properly when you can just buy another product to hide the flaws?
I tend to think that impatience is the strongest factor. I was taught to estimate pretty accurately when I was young, but most of the time, the people controlling the effort would be horrified to learn of those estimates. They are way too long. They want something in days, weeks, or months, but to get the implicit quality that they don’t realize they actually need, would sometimes take years. Their expectations are way, way off. But if you tell them the truth, they will just go to someone else who will tell them what they want to hear. They are told by the industry that everything is quick and easy now, so you can’t contradict that.
That doesn’t happen with big things like skyscrapers simply because there are regulators and inspectors involved at every step of the way to prevent it. Without them, skyscrapers would collapse quite regularly, which would kill an awful lot of people. Most societies can’t accept that, so they work hard to prevent it. Software failures, on the other hand, are extremely common these days, but death from them isn’t, so the industry is held to a lesser standard. That shows.
I do miss the days, long gone, when we actually had the time to craft stuff properly. Libraries and frameworks were scarce; we usually had to roll everything ourselves except for persistence. That was a mixed blessing. For good devs, they would get strong custom work that enhanced their codebases. But you’d see some exceptionally awful stuff too.
Getting mass tonnes of half-baked dependencies didn’t change that. Sure, it is easier for mediocre devs to hook up lots of stuff, but it is still possible for them to hook it up badly, and a lot of the parts are defective. So lots more complexity that still doesn’t work. Same difference, really. Just less real success stories.
All in all, it is a pretty weird industry. We learn stuff, then forget it, so that we have fun redoing it in a cruder way. That keeps the money rolling for everyone, but has clearly made our modern world extremely fragile.
Whacking together something fast isn’t better if the shelf life is far less. What comes together quickly falls apart quickly, too. Overall, it costs way more, adds more friction, and threatens stability. But since software is invisible and it's in a lot of people's best interests that it stays a mess, it seems that it will keep going this way forever. Rumors of its impending demise from AI are premature. Hallucinating LLMs fit in nicely in an industry that doesn’t want quality. Coders will be able to churn 10x or possibly even 1000x more crap out, so it is just a more personal stack overflow and infinite number of customized flakey dependencies. Far more code that is just as poor as today’s standards. It just opens up the door for more magic products that claim to solve that problem. And more grunts to churn code. One more loop through an endless cycle of insanity.
No comments:
Post a Comment
Thanks for the Feedback!