Jan Drábek

In my (programming) life I have discovered that attitudes to the bad code in projects can be classified basically into three groups. This classification emerged from an excerpt of the book named Saturnin, called after main very pro-active servant not unlike Jeeves of Wodehouse. Shortened relevant excerpt:

Dr. Witherspoon used to categorise people according to the way they behaved in a half-empty cafe when confronted by a plate of doughnuts. (…)

(…) If you are allegedly a person without imagination, any dynamic passions or a sence of humour, you will subject the doughnuts to a dull and thoughless gaze until perhaps midday. Then you will rise to your feed and take yourself off to lunch.

(…) At the sight of the doughnuts a member of the second category enjoys reflexing on what it would be like if someone, quite out of the blue and without warning, employed these pastries as missiles and began bombarding the other customers in the cafe.

(…) If fate had not brought me into the path of Saturnin, I would never have believed that a third category of people existed, the members of which are rare as white crows. I mean those people for whome the idea of doughnut whistling through the air is such an anticement that they get up and actually make it happen.

Although the passage is talking about doughnuts it can be freely adapted to bad code as it describes also the inner process that happen inside our minds. In the first case there is literally no process, in the second case there is an idea – a forseen potential and finally in the third case there is also a strong affection towards it:

1. People which just stare at the bad code without much though, mostly doing their assigned tasks, leaving as soon as they finish their tasks. Not saying anything, not taking care about any qualities of the developed outcome and for that reason more output control needs to be done.
2. People which have some ideas or imagination when seeing bad code, and can imagine better design/implemen­tation/orches­tration… but for some reason may not be able to carry it out on their own or mention it to somebody.
3. People as Saturnin not only having imagination, but the willpower and impudence to actually to implement it whenever they are. In programming these are not that rare as described in the excerpt, though they are also not that common.

Sure, nice mental exercise, so why to bother with this classification? It can actually help you see how are your team colleagues different and treat it properly to maintain their work satisfaction (and attempt to prevent their/your burnout).

Some of (my) observations:

• Unless you have a good process for ensuring desired qualities or large project, which only needs simple work labour, you typically do not want type 1, however sometimes it's the only option we can get on current job market.
• When you have to deal with type 1, you typically don't want to put them in front of any challenges such as new non-typical functionality or refactorings.
• Type 2 needs to be carefully talked to in order to encourage the imagination and its implementation, good team values and behaviours can be very handy together with team leaders 1:1.
• Type 2 hesitations can also be caused by missing experience, missing self-confidence or implicitly inferred lack of management support to pay off the technical debt.
• Type 3 needs not to be punished for its insolence, though some guidance is needed, though this can easily lead for them to rather quit than be limited in what needs to be done.
• Type 3 can also cause a lot of damage when their ideas are somehow weird (happens with bad programmers) or too frenetic.
• When ideas remains only ideas, burnout of types 2 and 3 is very likely.
• Type 3 is considered to be a unicorn by some and therefore wanted into teams as much as possible. That is not advisable as this can lead to dead-by-refactoring, destructivity in the team, or solitude. Beware of this shortcut as this classification says nothing about the quality!

These observations seem to quite intuitively follow from the classification and there will a lot more.

All this can be very handy to project managers and team leaders who can use it for the team benefits, for example to evaluate their bad code attitude culture, see different behaviour in their team and adapt to what they have or they want to have.

Enjoy your new tool and don't forget that not everything is a nail.