A common complaint I’ve heard often expressed is that software today is too complex, that it could and should be dramatically simplified. We could throw out a lot of the old crap and simply start afresh. This is most definitely the case whenever a modern text editor like VS Code is discussed. Why do we need this bloated thing when Dennis Ritchie built a text editor editor in a thousand lines?
This misunderstands how software is built.
Most software is simple when it starts out. The requirements are (mostly) clear. The design (mostly) fits the requirements. The implementation (mostly) matches the design. The software is good. We are happy.
Until we find that it doesn’t handle some edge cases well (like supporting non-Latin scripts used by billions of human beings). Or the spec changes because new requirements come in. Now the software begins to bloat. Extra pieces are tacked on, sometimes haphazardly. Tech debt piles on, because we lack the time to “do it right”. Eventually we declare tech debt bankruptcy and start over. But the fresh project won’t be any better unless the requirements are clearer or simpler.
A case study of software rot
A poster child for this kind of software is OpenSSL. Before 2014, it was used by every website on the internet to provide green padlocks (“secure”) on the URL bar. OpenSSL was a behemoth of 500k lines. Some of this code was maintained, lots of it was tech debt that needed to be paid down. There was only one SSL library so if you had some quirk in your use case, some particular algorithm you needed, you would modify OpenSSL itself, adding your hack to the mountain of hacks held together by duct tape. This policy of implementing every feature led to one of the biggest security vulnerabilities ever - Heartbleed.
The SSL situation needed to be fixed. Some decided to fork OpenSSL, starting by deleting all the cruft. Others started implementations from scratch. One such replacement was s2n, which started out with 6k lines. They didn’t implement every feature that OpenSSL had, only a carefully selected subset. It works well in it’s niche. But if s2n ever had to support all the myriad use cases that OpenSSL tried to, you can bet that it would start to look more like OpenSSL circa 2013 than s2n circa 2015. The lesson here is to limit scope while starting out and actively fight scope creep.
It’s probably more complex than you think
What’s frustrating is people who think that they can radically simplify something without knowing anything about it. The same people who think they can implement a text editor in 1000 lines of code because that’s how the first text editors were made. Why can’t we go back to those simple days?
We can’t because modern software handles cases that those didn’t. For example, rendering and editing text seems straightforward until you look closer. Text Rendering Hates You and Text Editing Hates You Too are two amazing reads that analyze this in detail. They explain the hidden complexity to the vast majority of us who never knew. We simply slapped down a <textarea> or <EditText> and called it a day.
If we tried to reimplement this stuff from scratch, we would likely start with a simple implementation, then tack on bits when we tried to handle issues like right-to-left layouts, Unicode, emoji, anti-aliasing, text overlapping and so on. All this before getting into implementing features that Dennis Ritchie didn’t have to, like supporting plugins, releasing on multiple operating systems, accessibility or even syntax highlighting. Problems already known to and tackled by existing text editors today.
If you look at work outside of your area of expertise and you feel like starting a sentence like “why don’t you just …”, then reconsider. If the person you’re talking to is halfway competent (they probably are), they’ve already considered what you’re about to say. “Have you considered using less memory/CPU or removing this feature that I personally don’t need?” Why yes, we have.
Conclusion
No software is perfect. All software can be improved in many ways. Sometimes, a rewrite is the only way.
Software today is no more worse than it was in the 80s or 90s. If anything, software that has survived 10+ years (gcc, Linux, Chrome, Excel) probably do a lot for a more diverse set of people than ever before. It might make different tradeoffs than it did earlier, but the fact that it survived and remained popular says a lot.
If you don’t like those tradeoffs, start afresh. Many people do, and they create the best software. But please, let’s stop complaining about how bad software has become and how it was better in the good old days.