Why „coding monkeys“ inevitably produce „banana software“

We much too often run into the conception of programmers as „coding monkeys“. Which is more or less the believe, that the work of a programmer is neither very complex, nor any ambitious and can literally be done by a monkey. I would like to spend some time trying to illustrate why this conception is not only horribly rude, but totally misleading and will run your software business in the ground. Why inevitably recruiting „coding monkeys“ will make you end up with „banana software“.

Writing software is – quite literally – writing a text. What programmers do is writing down instructions to a machine. An incredibly stupid machine. Take a second and think about the both most inexperienced and stubborn person you have ever met in your life. Now multiply that by a thousand. About that stupid. Perhaps even more. Computers are machines that do exactly as they are told. And by that, computers don’t have any meaning of common sense. Not the slightest bit. So if your instructions are not 100% precise, the computer might either not do anything at all or it would find a way out of your instructions and do something completely unexpected. But only sometimes. On other times it would work miraculously smoothly. For no good reason.

To stay at the analogy, writing software is most similar to instructing a five-year-old to go to bed. The more precise the instructions, the more likely he will end up in bed as you intended: in his pyjamas, teeth’s brushed, been to the toilet, hands and face washed, without any toys, but with his beloved teddy bear, and of cause without watching „just this one episode“ of whatever on the TV. Or the tablet. Or your mobile. I think you get the idea.

Generating all these small additions and translations between the original instruction of „get the kid to bed“ or the even broader „I want to have my peace and quiet“ into instructions that reliably get your kid to bed as you intended – that is what a programmer does. He is analyzing the customers‘ needs, finding the appropriate instructions and their appropriate order and writing them down. He is adding all the „common sense“ the computer simply doesn’t have. To be able to do so, he has to know the context of your instruction. He has to know about all relevant circumstances in order to perform his task effectively and efficiently.

However, let’s get back to our example:  The programmer has to know something about the kid and the bed. He has to know about the necessary tasks to be performed before he simply puts the kid in the bed. He has to know about their natural order. Otherwise he could just act like a „monkey“ and do literally take the kid as it is and put it in the bed as instructed. Alternatively, in the broader instruction of „I want my peace and quiet“ – he actually has to know ABOUT the kid and the bed. Otherwise he might do even worse and get to a more final version of getting you to „your peace and quiet“.

A programmer has to take the time to understand the situation and the intentions of his customer rather than simply following his instructions. He has to add the common sense required – simply because the computer can’t. Having these tasks performed by a „monkey“, you will – rather sooner than later – end up in a catastrophic misconception. Someone who doesn’t think „outside the box“, someone who isn’t ambitious, someone who just simply follows instructions – a „monkey“ – simply won’t do the job. Or if he would do the job, he won’t be good at it and you will end up with „banana software“. Software that is full of misconceptions and „matures at the customers site“.

Don’t get me wrong: instructions can and will be misconceived. In every software development. That’s a matter of fact. It’s always a matter of creativity to figure out the real intention, to find the optimal solution to solve an issue. And you might always fail in doing so. „Coding monkeys“ are just more likely to fail than talented, well-educated (and well-paid) programmers. Therefore, if you intend to use them for they are „cheaper“, you should only leave trivial tasks to them. Unfortunately, the efforts to be spent to analyse the customers needs to find the appropriate instructions and their appropriate order is almost 80% of the work. If you ever wondered why developers seem to almost never spend time actually typing code – that’s why. Typing the code in the end – the task you would be actually able to give to a „coding monkey“ – is always just a small fracture of the actual work of software development.

The common solution of introducing a second class of software developers – the software architect – to do all the heavy lifting of understanding and breaking everything down for the „coding monkeys“ tends to fall short. If the non-trivial work amounts to 80% of the work, you could only hand the remaining 20% to a „coding monkey“. Therefore, the potential for cost reduction is quite limited from the very beginning. For the „coding monkey“ to successfully do his job, he needs detailed instructions to be given to him by the software architect. Writing these instructions in a manner to be understood and executed correctly by a „coding monkey“ is likely almost the same effort than just coding it himself – if not more. Giving less detailed instructions would on the other hand make you end up in a similar or even worse situation than the one you tried to solve by the introduction of the software architects in the first place.

Inevitably treating your programmers as „coding monkeys“ will lead to big portions of the code being written by programmers that are aware that they are distrusted and disrespected. Keeping your programmers under close surveillance, neither wanting nor trusting their inputs, discourages and frustrates them and will finally result in a self-fulfilling prophecy. The bad habit of disrespecting a developer as „coding monkey“ does inevitably lead to work-to-rule habits. Maybe not today, not tomorrow, but throughout time. And work-to-rule habits and simple „do as you’re told“-attitudes do not match the work we require programmers to do. Software leaving „coding monkey“-development will most certainly be less ready for production and require more rigorous testing than software developed by well trained and respected programmers. The additional testing required will consume even the last financial benefits gathered by the usage of the „code monkeys“. Skipping this rigorous testing to keep the financial benefits will hereby inevitably lead to „banana software“ – software that matures at the customers‘ site.

In the end, the picture seems quite clear: If the work of a programmer would be simply „typing code into a machine“, using „coding monkeys“ might be a thing. However, the job of a programmer is much more complex than that. It requires tons of communication and multiple skills of different domains. You simply have to understand the world to be able to describe it to a computer. Introducing the software architect as a „cure“ to this problem while maintaining the idea of a coding monkey has proven neither to be effective nor efficient throughout the industry, but simply leads to the software architects dilemma which I will lay out in a different post.

Dieser Beitrag wurde unter Bosch Connect veröffentlicht. Setze ein Lesezeichen auf den Permalink.