Software Evolution

Summary: Computer Software History and Evolution

This is a summary with links to my posts of the history and evolution of computer hardware and software.

In computers and software, history is ignored and its lessons spurned. What little software history we are taught is often wrong. Everyone who writes or uses software pays for this, and pays big. This is true at a large scale for computers.

Software history can be spectacularly bad about important things.

Bad software history is also rife on a smaller scale, for example cryptography.

Software history is largely ignored.

When you learn math, you are learning its history. When you get to calculus, you’re essentially up to the 1600’s. You build from the ground up. Not in computing, to its detriment.

Studying history would show modern software people who think they’re solving big problems that the problem is decades old and that the box of failed solutions is overflowing.

Software development is a giant mess. Studying its history and the attempts to clean up the mess is an essential part of constructive change.

The history of other fields can have lessons that are highly relevant for software.

Some aspects of computer history are so important and relevant that, when understood and applied, they make dramatic improvements to software development.

Software Evolution

Software evolves. But it evolves differently than other things studied by science. Virtually no one studies software history in any way, much less the patterns of evolution that become apparent when you study that history.

Why should anybody bother to study software evolution? Knowing software evolution can help you predict the future! How? Software does not evolve the way most people think it does

When studying software evolution it’s important to understand the underlying principles of automation – the things that computers and software are capable of doing.  The fundamentals will tell you WHAT will happen, but not WHO or WHEN.

The way you learn software evolution is to study both its history in general and how it has been used in different industries and domains.

One clear pattern of evolution is that a kind of software will be established in one domain and then slowly, sometimes over decades, appear in other domains, one by one.

A similar pattern often occurs with simple kinds of software.

A peculiar aspect of software evolution is software fashions. They appear, grow strongly and often fade away as their awfulness becomes hard to avoid. Then they come back, usually re-named.

A typical result of a fashion-driven software trend is to increase costs without delivering benefits, which can happen even when it involves an intrinsically good thing like workflow automation.

One of the forces of evolution is resistance to automation.

Software Programming Language Evolution

Software people love to talk about progress and innovation. Most of what they claim as progress is little but milling around in a small box.

There is an odd evolution in programming languages, in which the relationship between data definitions and programs cycles from inside to outside the program and back.

However, there have been a couple major advances in the evolution of programming languages.

While some truly powerful advances have become standard, others have been thoughtlessly discarded.

Other powerful advances, widely used for a time in the market, ended up being ignored or abandoned by academia and industry in favor of a productivity-killing combination of tools and technologies.

The emergence from academia of “structured programming” and the associated effort to find all GOTO statements and burn them at the stake was a particularly shameful instance of the evolution of programming languages.

While loads of people focus on language, programming tools that make huge contributions to the productivity of programmers have evolved: libraries and frameworks.

Some programming languages that were supposed to be so much better than older ones led to major failures. But failures are expected in the normal world of software development, so the bad new languages kept marching along.

The small world of functional software languages has an interesting history.

Software Applications and Systems Evolution

One of the recurring evolution patterns is that functionality emerges on a new platform in roughly the same order as it emerged on earlier platforms. The timescale of the emergence may be compressed; the important aspect of the pattern isn’t the timing but the order. Here is an explanation of the general concept and how it worked for operating systems.

Here is how the same pattern of functionality on a new platform worked out in security services.

Here’s the pattern of existing functionality on a new platform as seen for remote access software.

Just because you’re building a version of existing functionality for a new platform doesn’t mean you’ll succeed. You can screw it up in various ways, including being too early – if the market doesn’t think it has a problem, it won’t buy a solution.

Transaction monitors are a classic example of the pattern of functionality emerging on a technology platform, and then emerging in pretty much the same way in the same order on other platforms.

Once an application appears on a software platform, there is a consistent way the category of applications evolves on that platform. It goes from a custom application to a basic product, then parameters are added and finally a workbench.

Here are examples of the progression from prototype through increasing levels of abstraction.

Software automates human effort to varying degrees. One dimension of automation is depth, in which software evolves from recording what people do through helping them and eventually to replacing them.

There is surprising pain and trouble of going from one stage of automation depth to the next. Unlike the progression to increasing levels of abstraction, customers tend to resist moving to the next stage of automation for various reasons including the fear of loss of control and power.

Here’s how the automation depth pattern plays out in “information access,” the set of facilities that enable people to find and use computer-based information for decision making.

The patterns of automation play out in multiple dimensions. In addition to automation depth, there is automation breadth.

Here are a couple of clear examples of the evolution of software applications to increasing automation breadth.

The evolution of spreadsheets is a good example of how these patterns work out in history, and clearly demonstrate the predictive power they have for anyone who cares to look.

As software evolves in these ways, it becomes increasingly nuts for a potential customer to build it for themselves. However, there are a surprising number of cases where a smart user can build a private version of commercially available software and win with it.

You would think that user interfaces would be thoroughly understood. When you look at a variety of UI’s you see that the underlying principles are clear but usually ignored.

Does Software Always Evolve?

There is a large body of core software that evolves extremely slowly.

Once a kind of software gets built, it tends to live long past the problem for which it was the solution. Data was so big you needed storage. Special SW invented to handle it. Now it will all fit in memory (for most applications). But the SW and code practices live on!

Yes, they’ve been obsoleted by modern hardware – but needed by software.

While there are things that change in software and management, a surprising number of common things just get new names. The “cloud” is a typical example.

Another example is pure software, shown with SOA and micro-services.

One of the explosive growth areas of the internet boom was the invention and spread of social media. Most of the people who look at it ignore its deep roots in non-digital media.

If and when serious study of computer software history and evolution finally starts to take place, perhaps Computer Science will start on the path to being, you know, scientific. And normal software development will stop being dominated by fashions.