It cannot be due to a lack of fluctuation, because according to a LinkedIn study , the software industry has the highest fluctuation rate of all industries. On average, large companies such as Google or Amazon manage to retain employees for approximately one year .
Silicon Valley managers report that the lower bound for the retention time of developers is now around six months. Six months! This is frightening for a number of reasons. Employees have to start planning their departure practically immediately after they start working. Seriously: how can you really arrive at a company in such a short time, build social relationships, and create trust? Can one ever make a really valuable contribution to the company in such a short time?
Why should the company send the employee to a conference or training ? This would only increase the employee's market value, and they would then possibly switch directly to a competitor for a higher salary. So instead of investing in employee training, the company would rather offer massages, fitness club memberships as well as snacks and drinks. Fortunately, fluctuation is not (yet) as high here in Germany, even though cities like Berlin seem to be well on the way to emulating Silicon Valley.
No matter how high it is, fluctuation alone is not enough to solve the problem of developer scarcity, because fluctuation is only a redistribution. The industry has been growing more or less unchecked for decades, even faster than the economy as a whole . Robert „ Uncle Bob “ Martin has shown that the software industry has a growth rate where the number of programmers doubles about every five years . He draws an interesting conclusion from this: due to this growth, every second programmer has permanently less than five years of professional experience.
Rapid Growth
In times of automation and digitization, most business models are designed to allow companies to scale quickly; this is of course especially true when digital goods are produced or distributed. It is precisely here that developers are increasingly needed, but even for small and medium-sized companies, which primarily seem to have nothing to do with IT at all, it is not unusual today to have their own development department. Let's take a look at how PHP developers are being recruited today by randomly looking at some job ads I found on the Internet.
One company, for example, is looking for employees who will take over the support and further development of our web portals and other applications . Another is offering work on highly scalable PHP 7 products hosted in a cloud-based infrastructure . How about commissioning and customizing of our products at customers , second-level support of existing applications , or maintenance and further development of software. If bugfixing and software testing doesn't appeal to you, you might find your luck in driving forward existing international B2B customer projects .
You don't even have to read between the lines or in the small print to discover maintenance of existing applications . And this despite the fact that programmers, developers, IT engineers, software developers or even "web backend developers" are being sought.
If a large part of the job is maintenance of existing software, why are you looking for developers and not maintainers?
I know of cases in which the job advertisement praises the use of the latest technologies and working techniques, only to have the newly hired developer work on bugfix tickets in a legacy system. Where does it actually come from that nobody makes a difference between development and maintenance in the job description?
By the way, in many industries there is – in contrast to the software industry – a very clear separation between development and maintenance. For example, an engineer at Airbus designs aircraft. An engineer at Lufthansa, on the other hand, is responsible for the maintenance of aircraft during operation. Both activities are important, but have a completely different requirement profile. Who would think of using the same engineer for both activities? In the case of the software "developer", nobody seems to see a problem in letting one person juggle both tasks.
Software maintenance is essential for ongoing business operations, possibly even more important than the development of new functionalities. After all, existing solutions must be adapted to changing legal requirements or market demands, otherwise it may not be possible for the company to create economically meaningful value after a short time. Nevertheless: everybody is looking for developers, but nobody is looking for maintainers. There are numerous branches of industry that are based solely on maintenance.
A car mechanic, for example, is responsible for the maintenance and repair of existing vehicles. A janitor ensures the smooth "operations" of a property. Nobody would think of hiring a janitor to build a new property. And the average car mechanic would probably be just as unsuitable for building a new vehicle "from scratch" as a Volkswagen catalyst development engineer is qualified to provide roadside assistance at night.
Software development is a young discipline, significantly younger than 100 years. Apart from the very early beginnings with Charles Babbage and Ada Lovelace , the professional profile of the programmer emerged with the emergence of electron computing during the Second World War. No wonder that we have little experience compared to other industries and professions.
Mankind has been building houses for about 8000 years. A lot of time to gain a lot of experience. Nevertheless, just a few hundred years ago it was not very surprising when a cathedral under construction collapsed in parts and had to be rebuilt. Against this background, it is not so surprising that even today most software projects (at least partially) fail .
The Software Crisis
In 1968, a group of experts met in Garmisch-Partenkirchen for a conference sponsored by NATO to address the "software crisis". Even then, it was recognized that scaling the programmers was a bigger problem than scaling the computers themselves. Edsger Dijkstra said in 1972:
As long as there were no machines, programming was no problem at all; when we had a few weak computers, programming became a mild problem, and now we have gigantic computers, programming has become an equally gigantic problem.
If only Dijkstra could have imagined at that time how powerful computers would be in just a few decades!
It is interesting to note that in the early days of computer science, a distinction was made between the programmer and the coder. The programmer was a professional user who developed an algorithm and wrote it down by hand. The coder was then the one who encoded the program on paper tape and executed it with the computer. Even today, we still refer colloquially to programmers as "coders", even though the profession of programmer has long since become independent of the business user. The term "code" in itself is highly problematic, because "code" is something mysterious, obfuscated and difficult to read. Developers should not write code.
The "code" is what gives computer science the mysterious touch of a secret science. A few selected technology experts create black boxes behind closed doors that normal people cannot – or should not – understand. This may have worked in the past to secure the existence of individual programmers – or at least the attempted glorification of individual departments – time and again. Today, however, most companies have realized that a low bus factor is a serious risk for a project. The bus factor of a project can be increased by avoiding knowledge islands, reducing complexity or better documenting. Should one explain unreadable programs ("code") by documentation, or write the programs from the beginning in a way that they are self-explanatory? Martin Fowler once said:
Any fool can write code that a computer can understand. Good programmers write code that humans can understand.
Most developers would probably say that they are not given enough leeway in the company to develop "good", i.e. readable software. It is also a fact, however, that many developers usually do not succeed in writing high-quality software well enough on first attempt. Only through rigorous and targeted refactoring can the desired readability be achieved. In fact, once programs are in production, they are often only slightly modified, mostly because there is too little test automation, and the manual testing effort would be too high . Whether this is a failure on the part of the developers, or the company will be discussed elsewhere.
An electrician doing a house installation will follow a standardized color coding of the wires, so that every other specialist who will later work on this system will immediately know which wires carry electricity and which ones, for example, have to be connected to the housing as grounding. The fact that every electrician, who cares about his own life and the lives of his customers, will still take a second look, of course, remains unaffected.
In computer science, we are able to attach the results of such measurements, which could also be called documentation, directly to the project in the form of automated tests , so that those who come after us not only receive documentation at the touch of a button, but can also be sure that it corresponds to the existing computer program.
If we as developers do not succeed in writing sustainable software that is not only low-risk to maintain, but perhaps even fun to use, will companies punish us by requiring us to maintain this very software in the coming years? Even if that were the case, this calculation would not work out. After all, the next job offer is only a mouse click away. But what can you expect there –
Development or Maintenance?
It seems that in many job advertisements people like to work with new technologies and current buzzwords, but then they want to spend more than 50% of their working time on maintaining existing systems. In the best case this leads to dissatisfaction because the employee is not allowed to introduce all these great technologies into the legacy software, in the worst case it leads to the employee doing just that and creating more and more complexity that quickly becomes unmanageable. Of course, there are cases where outdated technologies need to be replaced. But the driver for this is the outdated technology and not the existence of a new, apparently much better alternative.
If a company is suggested to look for a maintainer for existing software instead of a developer, it is usually rejected reflexively "because nobody wants that". In my experience this is not true. I know many developers, some of whom are very, very good in their field, but who do not enjoy developing new software because they do not cope well with the uncertainties involved.
How many people enjoy retro-computing or repairing old devices in workshops? Perhaps the fear that "developers" always want to do new things is no longer so justified as our industry grows older.
Companies should show more courage and look for personnel explicitly for the maintenance of software and systems.
However, in order to bring about a real change, newly developed software must become even more maintenance-friendly than it regularly is today. Imagine an electrician is supposed to do maintenance work. In a house, he encounters an incomprehensible variety of installed cables in different thicknesses and colors. Current-carrying lines are criss-crossed with signal-carrying lines, and it is completely unclear which wires are the ground, let alone the protective earth.
What would our electrician do? Instead of reverse engineering to find out what is connected to where and what purpose it serves, he would refer to industry standards that are not being met, pinch off all the wires and rebuild everything from scratch.