When people complain about inadequate productivity in software development there are two recurring aspects: continuously changing demands and the fact that the work flow keeps getting interrupted by other colleagues, e-mail, phone calls etc.
Possibly it is the greatest accomplishment of agile methods like „Extreme Programming“ to deal with these aspects. If the development process assumes that change occurs, and if developers have to act out their social and communicative needs in Pair Programming, it is by far more productive than when with every occurring requirement a developer shares his plight with another, disrupting that one’s work flow as well. For in that case both developers would be equally unproductive.
This article deals with an other phenomenon: self-heroization, on encountering a minor problem. This symptom signifies a psychological disturbance, which – so this author’s assumption – develops in a fundamentally different way with a software developer than with a software bureaucrat.
Munchhausen Syndrome
We developers all would love to be shining heroes, who with their magical sword are fighting against dragons and trolls. When we celebrate our success in development, we can act out that urge. If our skills lack, we have to make up our own heroic sagas. In detail that might look like this: A developer finds a bug in his program, but he cannot find the cause. Before frustration about his own inability appears, the minor problem must become an enormous dragon. As a single person can adhere to this fable for a given time only, it has to be shared with colleagues immediately: There’s a monster within your program! And naturally the project leader has to learn about it: The developer is about to face a heroic fight on which depends the fate of the whole world. When after some hours the agitation within the team about the circumstance has calmed down, one has to further dramatize and eventually succumbs completely to the world of make-believe. „The dragon isn’t just a normal golden dragon, but is in league with evil, maybe it’s even driven by an evil curse.”
This is usually the moment, when a developer claims that the data base produces mistakes. He lives only inside his world of dreams and he is miles away from the solution of the problem. At the end of the day the mistake is found. Maybe it was NULL-values in the data base and one’s own knowledge about them was insufficient.
But even then the heroic developer (for it is mostly men who try to follow suit Siegfried) refuses self-criticism, but keeps spinning his tale: Allegedly the SAP documentation is bad, which basically means that the dragon indeed was in league with forces of evil.
Munchhausen by Proxy
Developers who are suffering from Munchhausen Syndrome might be a nuisance in the eyes of their colleagues and bosses, still they perform and do productive work. There is a much more dangerous version that tries to satisfy the increased need for posturing with pure destructivity. This phenomenon can be observed when a developer is unable to identify with his task or if he feels overburdened. Instead of tackling the problem, he will spend all his time coming up with reasons for why he can’t accomplish his work. He is not adequately trained, the technology is not ready yet, the requirements are unclear etc. All these complaints might be correct in detail, but if there is no interest in improvement, they are purely destructive and the first stage of Munchhausen by Proxy Syndrome (MBP) is reached.
The overall pathology is as follows: Developers do not care about architecture, talk technologies bad, that don’t agree with them instead of considering them an opportunity to gain experience and to tackle new challenges. Unknowingly or knowingly, their performance gets worse, sloppiness finds its way in and the project is sabotaged. The reasons are founded neither in the technology nor in the doubts about the project – they are nothing but calls for help. „I want to be needed! My experience is important! I don’t want to adapt my method of operation to other conditions!”
The developer suffering from MBP does not consider himself a Siegfried, but a tragic hero who is oppressed by adversity and sees his dearest and most important endangered. This is not his project but his need to stand in the spotlight. However, he immediately succeeds in gaining the attention he craves for, if he harms the project.
Lethargy
While Munchhausen by Proxy Syndrome is a quite rare dysfunction, lethargy is much more common – a chronic indifference and listlessness. According to Greek mythology, not even heroes are immune to memory loss. If they drink water from the river Lethe, they lose all memory. Software developer’s lethargy shows itself for example in laziness when it comes to testing: „My program ran once before. Therefore it can't be faulty.”
Someone who suffers from lethargy has lost all ideals. He doesn’t see himself as a hero anymore. He has nothing left to win, possibly even nothing left to lose. Perhaps there are even monsters in his world, but he won’t be the knight who slays them.
While already one single person who suffers from Munchhausen by Proxy syndrome can kill a project, the person suffering from lethargy won’t accomplish that. Well-meaning and naïve “heroes” will take over his assignments. Soon they are suffering from excessive labour and in the long term their performance won’t even satisfy themselves and they become tragic heroes who, with eyes wide open, run towards destruction. Developers suffering form lethargy thus cause the slow and painful death of a project, which for the hero means irrevocable damage – after all, which hero wants to lose against the dragon?
The State of Mind of Software Bureaucracy
As shown above, us developers suffer from a variety of psychological disorders. What about the state of software bureaucracy? Contrary to developers, the software bureaucrat knows the monsters quite well (amongst others, developers!): Each paralyzed bureaucracy has the one as an enemy, who only utters the least of critique against its edicts. The bureaucrat however, isn’t a shining hero like the one the developer longs to be. A software bureaucrat’s victory over the monster is more prosaic – he wins with a hex and thus shots down all changes on the process he once has defined.
This alone isn’t the psychological defect of a software bureaucrat. His problem is the unwillingness to compromise which he likes to act out. If he can’t prevail, he considers his position and thus his existence in danger. Therefore he slays heroes and dragons just the same. When all tremble in fear of him, his world is in order.
In my opinion the cause for these psychological disorders of a software bureaucrat is a solid structure of prejudices. The following variants are possible:
- Monsters are everywhere. They can only be controlled by comprehensive reglementations. This attitude manifests itself when there has to be a rule established for every problem that has emerged in the past. These rules have to stay even when the surroundings have totally changed and the problems don’t even exist anymore, when there are new solutions or the mistake isn’t repeated.
- Heroes are just as dangerous as the monsters which are fought by the heroes. Both have to be regularized just the same. This attitude is a form of arrogance, as it doesn’t trust the developers to do their job well. By the way, this point of view is irrational, as software bureaucracy usually can’t help, as it’s too far away from the operative business.
- There are no heroes – all developers suffer from lethargy and have to be continually regularized. This attitude is ultimate arrogance towards developers and bears no foundation for team work.
What Does a Sane Software Developer Do?
The life of a sane software developer is a bleak one. By day he fights the monsters. Can he subdue them, he has to deal with his colleagues who are suffering from Munchhausen and Munchhausen-by-proxy syndrome and who keep telling him outrageous lies.
Along the way he does the lethargics’ work – and he constantly has to pay attention that he doesn’t provoke the all compassing software bureaucrat for his revenge would be terrible. In the long run, there are only two solutions: Either to also drink the water of Lethe, or to retire from the operational business.
A good choice is a position in which you don’t do anything, but join every conversation. First of all he has to manage that he’s associated with important topics – which by the way is different from proven expertise. But that becomes less important, the further up he gets on the job ladder. Therefore brilliance in operative topics is no longer necessary.
Why do careerists succeed? The answer is simple: Contrary to lethergics and people suffering from MBP, they don’t cause harm. As they’re busy working on their profile, there’s no danger that they’ll clash with the all powerful software bureaucracy. While developers love to see themselves heroes and thus spend the day lying their tiny lizards into dangerous dragons, the careerist prospers in his neurotic environment.
The Moral of the Story
Naturally the thesis presented here is overly pointed, but its true core hopefully shows the cultural problem between developers and software bureaucrats: Good developers work with abandon for their thing and get attached to their product. They want good working conditions to realize the product with justifiable effort and good quality (even when measured on their own claims). The software bureaucrat has a totally different value system and thus his very own monsters.
One can accuse developers as well as software bureaucrats that they are dealing with monsters that aren’t even real. However, this awareness is already the first step towards a solution of the problem: When both parties acknowledge that the world isn’t just heroes and monsters, but many other creatures as well, reasonable work and therefore also productive team work is possible.
All the stereotypes presented in this text repeat the same mistake: They only deal with themselves, their heroic, assumingly tragic, desperate and allegedly overly powerful or ostensibly more excellent person. Their neuroses complement each other and therefore they are hard to treat.
