The cause of decline quality among software developers. What seems to be the main cause?

               

The decline is real, the cause is simple — but there’s a solution too.

In the early days, the only people who would be able to successfully program were those who were the very top of the scale in terms of innate ability. As languages and tools have improved, programming has become possible for those lower down the scale. Those improvements make all developers more productive, yet do not change the proportional difference between a decent developer and a great one.

For a long time now, however, there hasn’t been a significant improvement in the languages and tools used by the majority of programmers. Productivity hasn’t changed much, but demand has grown hugely in terms of number of users, devices, and problems that today’s hardware can cost-effectively solve - if only we have the software.

Companies obviously aim to choose the best of the available candidates, so as time goes by and we need more programmers, the extra ones entering the market are on average worse than those already employed. At some point, we reach a stage where the new people are simply not able to program economically with the current tools, and the growth of programmers tails off.

The US hit that point in 2004: after becoming the most common job in the country (overtaking truck drivers), the number of programmers stopped growing.

Outsourcing played a role, but even after it declined again the number of US programmers has remained below that peak. Roughly speaking, all the people in the US who can productively program with current mainstream tools are already programming. The growth in global numbers is happening elsewhere, in countries where a smaller percentage of people are already employed as programmers. It won’t be long before we hit the limit globally, in all countries that are developed enough to educate programmers.

 

When we hit that limit, the only thing that can help will be to raise the level of productivity significantly, nearly an order of magnitude. That will open software development to a new section of the population. The only innovation I’ve seen that can do this is called Domain-Specific Modelling: languages designed for a narrow task, and using the point of view of the domain expert, not the programmer. A tool designed for a specific task is much more productive and much easier and safer to use: yes, you can core an apple with a table knife, but it’s time-consuming, risky, and the results are uneven; with an apple corer, it’s one push and you’re done.

For over 30 years, there have only been a couple of mainstream languages at a time: general purpose jacks-of-all-trades, masters of none: the table knives of software development. The challenge with the apple corer is that it’s useless for cutting your cheese, or slicing an egg - so we need more tools, for each domain. And as each domain will have its own domain experts and a different set of concepts and terms they use, we need different languages.

Historically, creating new languages and tools has been time-consuming and intimidating. A new kind of tool, called a language workbench, takes the hard work out of it. The best workbenches can enable even a non-programmer to create a new modelling language and full tool support in under a week, and in under a fortnight a programmer can add the code generation that turns any model made with the tool into running code that works first time. And that generation is what makes the modelling 5–10 times more productive than hand-coding for that domain. One of my working life’s greatest privileges is to have been able to see that magic happen in probably more domains than anyone else — and yet it still delights and impresses me every time.

While I think Domain-Specific Modeling is the long term answer, there is also a need for tools between the table knife and the apple corer. Find the kinds of system built most often by the greatest number of programmers, and make a somewhat specific solution for their customers to be able to make those systems mostly by themselves. This approach is called ‘low code’, and rather than using the concepts of the customer — one language for doctors and another for accountants — it aims for a more generic, yet still high level, modelling language, with bits of code as necessary. Rather than many hundreds of languages,

you can concentrate on a smaller number where you can offer customers tooling you’ve already made. Historically this has been seen in tools like Simulink and LabVIEW; today it’s being brought to the world of the web and Internet of Things by companies like Mendix.

 

So, the decline in quality is real, and inevitable — with current mainstream languages and tools. The interesting question is whether the software juggernaut can still turn. If it can’t, or stubbornly refuses to, it risks being overtaken by its own customers, producing their own software more productively with low code and Domain-Specific Modeling.