A Human Wave Bubble Ready to Burst

It is clear that there is an ever growing need for software in the world. When there is need, supply forms naturally. Unfortunately Software is a difficult industry, and it takes a special kind of people to deliver it. We are not talking of something like manufacturing. Software is even in a special class of engineering. It is close to science, and the amount of concepts to absorb to deliver it is daunting.

The Bubble grows every time somebody is faced with a software demand, and realizes that to satisfy it, they won't find capable professionals on the market. By "capable" we mean able to handle the tools of the day. The temptation is great to accept using inferior tools, easier to use, to find people ready to work with them.

Why is it a problem? Because it is a slippery downwards slope. Demand far exceeds supply, and accepting to "degrade" the quality of hires iterates over itself. Give it enough time, and soon, IT professionals use conceptual tools (seemingly new) which are outdated, and write off decades of software engineering progress.

A concrete example among many nowadays, is the growing use of JavaScript in back-ends. JavaScript was invented as a convenient technology to run code in a browser. It is a fairly easy programming language, without types, and, with the growing interest in browser-based solutions, a large number of professionals in the world master it. It gives a false feeling of modernity, because it is from the "Web". However, it was invented only for the Web, not for back-end solutions. Yet, we witness a big surge of JavaScript usage in back-ends. Should we follow this trendy move? JavaScript is relatively recent, but for what it was meant to do, it did not bother introducing the concept of type. Types were adopted in the mainstream of software engineering in the 1970s, half a century ago, among many reasons, to give guarantees about the quality of a program. The compiler validates the program, and allows you to sleep better at night, being reassured that your software was deemed "correct" by a very picky and thorough validator: a machine running the compiler. JavaScript delivers nothing of that. JavaScript, although it is relatively recent, is based on concepts which are half a century old. Convenient for a browser, completely unadapted for back-ends. All the intermediary steps which brought us gradually here are troubling, and should push us to do some introspection.

But some people would say "who cares?", my software was delivered. I had to hire a bunch of people to deliver the solution, both for programming and quality assurance, but at least I delivered. It is better than not delivering at all, isn't it?

Alas, this reasoning is incorrect. The reason for that is that software is not just delivered with people, but with software as well. Software helps delivering software. And what software does best is to automate what people do.

Writing off half a century of progress, and surrendering on leveraging the more and more difficult conceptual path to automation exposes entire organizations, masses of people, to being part of a large bubble, and suddenly, like with all bubbles, brutally eliminated. Using tools which are apparently new, being reassured by following what the large community of professionals is doing, is precisely what makes the professionals inside the bubble vulnerable. With the number of programmers doubling every 3.4 years, the average experience of programmers is very short. It makes the vast majority of programmers in the world blind to any threat to their way of working. Real progress continues without them, until it will be too late.

The comparison with electronics is quite striking. It is as if there was a shortage of people capable of creating Integrated Circuits, and to satisfy demand, hoards of people soldering large outdated components (resistors, capacitors, etc.) were hired.

So, we ask, are we really doing a service to people by promising them an entire career, spanning decades, based on manually soldering components to a board? Is it really a good deed?

Should we have sympathy for "sour grapes" views where technical employees claim that the science in ICs is too complex? That performance does not matter? That hiring inexpensive offshore resources will beat technology progress? We think not. Machines are cheaper than people.

We must embrace the full progress of software, and use it for what it is very good at: automating. That includes automating software production. And then we will see true progress, and solutions will be feature-rich, will perform well, and new opportunities will arise, including for all professionals ready to adjust.