Some software is changed over time. But there is a great deal of software that is simply part of the landscape or part of the underpinning of the software we see. This largely ignored category of software is important to understand.
Keeping up with Software
I had a nice conversation with the non-technical CEO of one of our software-based companies. He expressed the widely-held view that the process of developing software is undergoing change at a dizzying pace. Just in the last couple of years, new languages and tools have emerged and are being used and talked about. How can anyone possibly keep up, he wondered?
That certainly is how things seem to most people, both inside and outside of the computer industry. We had desktop machines, personal computers, 25 years ago, and we have them today; of course, they’re less expensive and have way more power and capacity than they did back then, but they’re still personal computers, we put them on or beside our desks, and use them. Software, on the other hand, undergoes constant change. For programmers, we’ve gone through an incredible changing landscape of programming languages and tools during that time. I’ll just give a short list: assembler, BASIC, turbo Pascal, Smalltalk, C, Objective-C, 4-GL’s too numerous to list, C++, Java, C#, PERL, javascript, php, python, ruby and on and on. It’s no wonder that it seems like it’s hard to keep up! And of course, in a way it is – it does take work. But most of that language change is little but noise. The claims of advances don't hold up when examined.
That’s how it seems. Hardware is hardware. Yes, it gets better and cheaper, but software, wow – there’s always something new!
The reality is different. True software change, whether in methods or bodies of code, is slower than glacial.
The Non-Evolution of Software Categories
It’s hardware that undergoes dramatic change, not software. Think Moore’s Law. Think about mobile phones just ten years ago. Here are details. By contrast, change in software is actually glacial. Yes, the surface weather of software changes rapidly and unpredictably; but the underlying principles and structure of software don’t even move as fast as glaciers – it’s more like tectonic plates.
Things are changing all the time. Software is certainly “soft” compared to hardware. But programmers spend most of their time in their minds, not wandering around touching up the hardware. What do they spend time thinking about? It’s not the hardware – it’s the software environment in which they work, and in which the software they create will live.
Think about kids in a sand box. The sand is something they can push around, pile up, makes holes in, and generally have fun with. How about the box the sand is in? It’s hard. It keeps the sand in one area. No kid thinks about it much – it’s just something that’s there when you’re playing.
It works the same in software. The “part” of the software you are playing with (a.k.a. “programming”) seems “soft” and easily changeable, like sand. The “part” of the software you’re not playing with seems “hard” to you. It’s just part of the landscape. This effect is strongest when the programmer has no access to the source code of the landscape software. An example is a DBMS or an operating system. These things feel like immutable reality. They are what they are, and you have to deal with them. Hardware speed and storage capacity has grown so much, for example, that DBMS's are a data storage solution to a problem that no longer exists. But most software design continues to be built on them.
Just as other pieces of software feel like given realities if you’re a programmer, so does the programming language in which you’re working. The verbs and the syntax are as real as the grains of sand. Just as when you play with sand, you have no sense that each grain is actually a very large aggregation of molecules, so when you use a verb in the programming language, you have no sense that a compiler or interpreter will actually use many machine language instructions to execute each verb.
The “hardness” of software to which you have no source code access (or otherwise no ability to change) is a strong psychological effect.
The Glacial Evolution of Software Applications
Programmers have a special view of software. Regular people also use software personally and/or professionally. While society gives us the impression that the software people use changes like crazy, the reality is that people learn new things slowly, and successful software evolves very slowly. The changes we see are largely incidental things that are enabled by the astounding advance of hardware.
The Bedrock of Production Systems
Large bodies of working, production code are the bedrock on which fancy new layers may be built, but change very slowly. Here's an example of the impact of that hard-to-change code.
It isn’t as though people don’t want to change these systems. Often they are desperate to change them! Sometimes managers will put huge investments into changing or replacing them, only to quietly admit failure and stop trying. Until the next bunch of ignorant-of-history managers come along.
These bedrock systems aren't just systems software like DBMS's. They are also plain old applications. For example, the software that handles the largest number of credit card accounts in the world is written in the prehistoric language COBOL. Several attempts were made to re-write card processing software using fancy new languages. Failed. See also this and this.
Conclusion
Hardware changes with amazing speed, giving no signs of slowing down. While there's always something new to talk about in software, it changes much more slowly than hardware, and is remarkably hard to change.
Hi Mr. Black,
I would like to speak with you about Ahriman. Connecting via email would be most appreciated.
Posted by: Craig Ramsdell, M.D. | 08/20/2023 at 10:47 PM