What do we really mean when we say that software is ‘dead’ or ‘dying’?

“The report of my death was an exaggeration,” Mark Twain once wrote in a letter to journalist Frank Marshall White. Twain's quip is a fitting refrain for much of the software industry. Year after year there is a new wave of opinion from experts declaring this or that software or trend to be dead or, if it’s lucky, merely dying.

I was inclined to think this was a relatively new phenomenon, but the topic comes up on Jeff Atwood’s blog Coding Horror as far back as 2009. Atwood quotes from an article from influential software engineer Tom DeMarco in which DeMarco writes that “software engineering is an idea whose time has come and gone.” (The hyperlink that points to DeMarco’s piece is, ironically, now dead). So, it’s clearly not something new to the software industry.

In fact, this rhetorical trope can tell us a lot about identity, change, and power in tech. Declaring something to be dead is an expression of insecurity, curiosity and sometimes plain obnoxiousness.

Consider these questions from Quora - all of them appear to reflect an odd combination of status anxiety and technical interest:

• Is DevOps dead?
• Is React.js dead?
• Is Linux dead? Why? (yes, really)
• Is web development a dying career? (It’s also something I wrote about last year.)

These questions don’t come out of a vacuum. They’re responses to existing opinions and discussions that are ongoing in different areas. To a certain extent they’re valuable: asking questions like those above and using these sorts of metaphors are ways of assessing the value and relevance of different technologies.

That being said, they probably should be taken with a pinch of salt. Although they can be an indicator of community feeling towards a particular approach or tool (the plural of anecdote isn’t exactly data, but it’s not as far off as many people pretend it is), they often tell you as much about the person doing the talking as the thing they’re talking about. To be explicit: saying something is dead or dying is very often a mark of perspective or even identity.

This might be frustrating, but it nevertheless provides an insight on how different technologies are valued or being used at any given time. What’s important, then, is to be mindful about why someone would describe this or that technology as dead. What might they be really trying to say?

“X software is dead because companies just aren’t hiring for it”

One of the reasons you might hear people proclaim a certain technology to be dead is because companies are, apparently, no longer hiring for those skills. It stops appearing on job boards; it’s no longer ‘in-demand’.

While this undoubtedly makes sense, and it’s true that what’s in demand will shift and change over time, all too often assertions that ‘no one is hiring x developers any more’ is anecdotal.

For example, although there have been many attempts to start rumors that JavaScript is ‘dead’ or that its time has come - like this article from a few years back in which the writer claims that JavaScript developers have been “mind-fucked into thinking that JavaScript is a good programming language” - research done earlier this year shows that 70% of companies are searching for JavaScript developers.

So, far from dead.

In the same survey Java came out as another programming language that is eagerly sought out by companies: 48% were on the lookout for Java developers. And while this percentage has almost certainly decreased over the last decade (admittedly I couldn’t find any research to back this up), that’s still a significant chunk to debunk the notion that Java is ‘dead’ or ‘dying.’

Software ecosystems don't develop chronologically

This write up of the research by Free Code Camp argues that it shows that variation can be found “not between tech stacks but within them.” This suggests that the tech world isn’t quite as Darwinian as it’s often made out to be. It’s not a case of life and death, but instead different ecosystems all evolving in different ways and at different times. So, yes, maybe there is some death (after all, there aren’t as many people using Ember or Backbone as there were in 2014), but, as with many things, it’s actually a little more complicated…

“X software is dead because no one’s learning it”

If no one’s learning something, it’s presumably a good sign that X technology is dead or dying, right? Well, to a certain extent. It might give you an indication of how wider trends are evolving and even the types of problems that engineers and their employers are trying to solve, but again, it’s important to be cautious.

It sounds obvious but just because no one seems to be learning something, it doesn’t mean that people aren’t. So yes, in certain developer communities it might be weird to consider people are learning Java. But with such a significant employer demand there are undoubtedly thousands of people trying to get to grips with it. Indeed, they might well be starting out in their career - but you can’t overlook the importance of established languages as a stepping stone into more niche and specialised roles and into more ‘exclusive’ communities.

That said, what people are learning can be instructive in the context of the argument made in the Free Code Camp article mentioned above. If variation inside tech stacks is where change and fluctuation is actually happening, then the fact that people are learning a given library or framework will give a clear indication as to how that specific ecosystem is evolving.

Software only really dies when their use cases do

But even then, it’s still a leap to say that something’s dead. It’s also somewhat misleading and unhelpful. So, although it might be the case that more people are learning React or Kotlin than other related technologies, that doesn’t cancel out the fact that those other technologies may still have a part to play in a particular use case.

Another important aspect to consider when thinking about what people are learning is that it’s often part of the whole economics of the hype cycle. The more something gets talked about, the more individual developers might be intrigued about how it actually works. This doesn’t, of course, mean they would necessarily start using it for professional projects or that we’d start to see adoption across large enterprises. There is a mesh of different forces at play when thinking about tech life cycles - sometimes our metaphors don’t really capture what’s going on.

“It’s dead because there are better options out there”

There’s one thing I haven’t really touched on that’s important when thinking about death and decline in the context of software: the fact that there are always options.

You use one tool, language, framework, library, whatever, because it’s the best suited to your needs. If one option comes to supersede another for whatever reason it’s only natural to regard what came before as obsolete in some way.

You can see this way of thinking on a large scale in the context of infrastructure - from virtual machines, to containers, to serverless, the technologies that enable each of those various phases might be considered ‘dead’ as we move from one to the other.

Except that just isn’t the case. While containerized solutions might be more popular than virtual machines, and while serverless hints at an alternative to containers, each of these different approaches are still very much in play. Indeed, you might even see these various approaches inside the same software architecture - virtual machines might make sense here, but for this part of an application over there serverless functions are the best option for the job.

With this in mind, throwing around the D word is - as mentioned above - misleading. In truth it’s really just a way for the speaker to signal that X just doesn’t work for them anymore and that Y is a much better option for what they’re trying to do.

The vanity of performed expertise

And that’s fine - learning from other people’s experiences is arguably the best way to learn when it comes to technology (far better than, say, a one dimensional manual or bone dry documentation). But when we use the word ‘dead’ we hide what actually might still be interesting or valuable about a given technology. In our bid to signal our own expertise and knowledge we close down avenues of exploration. And vanity only feeds the potentially damaging circus of hype cycles and burn out even more.

So, if Kotlin really is a better option for you then that’s great. But it doesn’t mean Java is dead or dying. Indeed, it’s more likely the case that what we’re seeing are use cases growing and proliferating, with engineering teams and organizations requiring a more diverse set of options for an increasingly diverse and multi faceted range of options.

If software does indeed die, then it’s not really a linear process. Various use cases will all evolve and over time they will start to impact one another. Maybe eventually we’ll see Kotlin replace Java as the language evolves to tackle a wider range of use cases.

“X software pays more money, so Y software must be dying”

The idea that certain technologies are worth more than others feeds into the narrative that certain technologies and tools are dying. But it’s just a myth - and a dangerous one at that.

Although there is some research on which technologies are the most high paying, much of it lacks context.

So, although this piece on Forbes might look insightful (wow, HBase engineers earn more than $120K!) it doesn’t really give you the wider picture of why these technologies command certain salaries. And, more to the point, it ignores the fact that these technologies are just tools used by people in certain job roles. Indeed, it’s more accurate to say that big data engineers and architects are commanding high salaries than to think anything as trite as Kafka developers are really well-respected by their employers!

Talent gaps and industry needs

It’s probably more useful to look at variation within specific job roles. By this I mean look at what tools the highest earning full-stack developers or architects are using. At least that would be a little more interesting and instructive. But even then it wouldn’t necessarily tell you whether something has ‘died’. It would simply hint at two things: where the talent gaps are, and what organizations are trying to do.

That might give you a flavor of how something is evolving - indeed, it might be useful if you’re a developer or engineer looking for a new job. However, it doesn’t mean that something is dead.

Java developers might not be paid a great deal but that doesn’t mean the language is dead. If anything, the opposite is true. It’s alive and well with a massive pool of programmers from which employers can choose. The hype cycle might give us an indication of new opportunities and new solutions, but it doesn’t necessarily offer the solutions we need right now.

But what about versioning? And end of life software?

Okay, these are important issues. In reality, yes, these are examples of when software really is dead.

Well, not quite - there are still complications. For example, even as a new version of a particular technology is released it still takes time for individual projects and wider communities to make the move.

Even end of life software that's no longer supported by vendors or maintainers can still have an afterlife in poorly managed projects (the existence of this articles like this suggest that this is more common than you’d hope). In a sense this is zombie software that keeps on living years after debates about whether its alive or dead have ceased.

In theory, versioning should be the formal way through which we manage death in the software industry. But the fact that even then our nicely ordered systems still fail to properly bury and retire editions of software packages, languages, and tools, highlights that in reality it's actually really hard to properly kill off software. For all the communities that want to kill software, there are always other groups, whether through force of will or plain old laziness, that want to keep it alive.

Conclusion: Software is hard to kill

Perhaps that’s why we like to say that certain technologies are dead: not only do such proclamations help to signify how we identify (ie. the type of developer we are), it’s also a rhetorical trick that banishes nuance and complexity.

If we are managing complexity and solving tricky and nuanced problems every day, the idea that we can simplify our own area of expertise into something that is digestible - quotable, even - is a way of establishing some sort of control in a field where it feels we have anything but.

So, if you’re tempted to ever say that one piece of software product is ‘dead,’ ask yourself what you really mean. And if you overhear someone obnoxiously proclaiming a framework, library or language to be dying, consider what they’re trying to say. Are they just trying to make a point about themselves? What’s the other side of the story? And even if they’re almost correct, to what extent aren’t they correct?