At different times, software has tried to solve different problems. The problem being solved at the time had a major impact not only on the design of the software but also how the software continued to be used.

Back in the ‘40s and ‘50s, we were just trying to get software to work; to do what it needed to do. That usually meant running accounting software for large organizations, or controlling missiles, or—much more rarely—spacecraft. Assembler code was the perfect solution for getting software to do these things.

In the ‘60s, software changed—along with everything else. We discovered that if you wanted human beings to work with software, it was important not only to be able to write the software—it was also important that these humans could read the software. And basically—with a few pointy-headed exceptions—no one could read assembler. And so the collective unconscious called forth Admiral Grace Hopper to build us a language that human beings could read. That language took over the decade and it was called COBOL.

In the ‘70s, the virtues of smallness, flexibility, and independence took hold in the computing community and we started working on much smaller systems. Software developers and their companies tried to build different things. No longer isolating software to accounting systems, we started trying to build computers that could play games. These computers with effectively no memory, very low processing speed, and little storage space started their transformation to the machines of today. We called forth from our teeming masses Dennis Ritchie to create the C programming language, in order to perform more complex tasks with 720k of disk space and 4k of RAM. It’s still perhaps the best language ever built for handling resource limitations. The ‘70s were about resource management and C is the answer to that problem.

In the ‘80s, we were all about networking. Everyone and their computers wanted to network with everyone else. We were no longer running small, independent systems. When we had a dozen computers in an office, we wanted data Ann entered on computer A to be available to Bob on computer B when he wanted to look at that data. We wanted our computer programs to be able to share data decently. Turns out, that was a hard problem—until Edgar Codd gave us SQL and the relational database paradigm. Fundamentally, the ‘80s were about how to hook our computers together and share data, and SQL solves most of that problem.

When the ‘90s replaced the ‘80s, we had to go back through and get rid of all the old uncool ‘80s stuff. In the beginning, there was the command line. But by the ‘90s, it too was uncool. So we got rid of our command lines. We got rid of them in ones and twos at first, but soon the entire industry was spending all of their time making graphical user interfaces where before there was only the command line. Our collective need for GUIs—like the one Steve Jobs had—convinced Bill Gates to command his company to bestow upon us Visual Basic. Visual Basic is probably the best language ever built to allow the connection of graphical user interfaces to SQL data stores. And since that’s what we needed in the ‘90s, that’s what people did. The ‘90s were about GUIs, and VB is still among the best languages ever built for that purpose.

When the ‘00s rolled around, the IT world—like the non IT-world—had a bunch of problems. First, there was the interweb. Second, we started trying to connect all our old systems to the internet as well. As we started trying to connect all our old systems to the internet we found something surprising. In every system we looked into, we found comments that looked like this:

/* Hey, this code really sucks, but it was the best I could do before we deployed. Make sure we fix it before our next release.

Kyle, April 1972.

*/

 

# I’ve never written such bad code in my life.

# We can fix it before our next release.

# Demetria, December 1974

 

— Please don’t go to production with this crap.

— It works, but it’s hideous. Burns my eyes when I look at it.

— Tom, July 1965

 

Every system where the programmers had bothered to comment at all had those comments. The rest of them had worse code but less polite programmers. What we discovered as we tried to move our code onto the web is that we had code that we couldn’t change. We needed maintainability, or changeability, in our code and we didn’t have it. We cast about looking for a savior, to give us a language that made maintainable code less difficult than it was. James Gosling gave us Java. As it stands, Java was the first mass market language (sorry, Smalltalk) that was written to take object orientation—and therefore maintainability—seriously. It’s still among the best languages for maintainability in popular usage.

More recently, the ‘10s rolled around. In the teens, software is trying to eat the world. Honestly, it’s doing a pretty good job of said world-eating. Raise the minimum wage in Seattle? Replace minimum wage workers with kiosks. Tired of taxis? Replace dispatchers with a set of competing apps. Hotels? Nah, let’s write an app. Maps? No, apps!

The motto became: We need more software, faster. In a huge number of cases, the name of the game is faster. What solves that problem? It’s not clear yet. Javascript and its modern frameworks (MEAN stack and others) will be the winners of the ‘10s, as Java is finally relegated back to a second-place language. Python also appears to be a big winner in this space. It’s too soon to tell. Certainly agile and agile-style methodologies and technical practices are a part of the solution.

Every software language and approach solves a set of problems well. Today’s problems are a blend of the aughts problem and the teens problem: how do you maintain code faster? And while the answer may be surprising, coming from us, the answer has a lot to do with this: write maintainable code.