Chapter 38. An Ode to Code

All bad poetry springs from genuine feeling.

Oscar Wilde

Gerald was a coder who worked in a small team. The thing was: other coders coded code that was not clean. The mess was detrimental, distracting, diabolic; The inhumane detritus of an evil workaholic.

But Gerald had a conscience. He wouldn’t let this lie. He lay awake at night devising schemes to rectify The awful internal structure, the confusing variable names, And the contrived control flow that was consistently insane.

Those early days the “Boy Scout Rule” was how he planned to beat The bugs and turgid software that had formed beneath his feet. A tidy here, a bug fix there, refactors left and right. Pretty soon, he thought, (with work) they’ll all be out of sight.

But poor old Gerald, plan in action, missed one vital fact: To make a dent, all programmers must enter in the pact. His slapdash coding colleagues, just saw a rule to flout And continued writing drivel whilst he tried to sort it out.

One step forwards, two steps back. Gerald danced this dance. Until he learnt he needed a more militant stance. Agile teams are excellent and clean code is the best. To achieve this: the team, and not the code, would have to be addressed.

Conway’s law describes to us how software follows team— Sympathetic software is born from a well-oiled machine. If cogs get stuck or grate, and stop doing what they ought. Then there’s only one option: to remove them, Gerald thought.

So the team refactor started, with the pattern: “Parameterise from Above”: The manager, on his cycle home, received a surprise shove. He landed down a manhole. You might call it homocide. Gerald called it team hygiene. One problem had then died.

One by one his team mates met with unusual fates. The unsuspecting QA team were hit by flying plates. (The lesson learned from this event was: never hold team meetings In a diner with bad furniture, and poltergeisty leanings.)

The programmers who caused such ire each met a gory end. One “caught his tie in the printer”; his face will never mend. Another tripped atop the stairs on his way out for a break, A pile of deadly Unix manuals flying in his wake.

Gerald’s life was vastly better; the team was little more Than one coder, a sys admin, and the guy who manned the door. The problem with this setup, Gerald shortly found: The code got no worse—good!—but it hardly changed, as no coders were around.

Progress was slow and tough, though heroic Gerald tried. Deadlines made a “whooshing” sound as often they flew by. With features sadly lacking, the project was a farce. Then one day a policeman came, and put Gerald behind bars.

The moral of this simple tale is to react with care When callous coder colleagues deign to drive you to despair. The only sensible way there is to retaliate Is British: maintain a healthy level of pent-up angst and hate.

Coding Is a People Problem

Hopefully you’ve read the chapter on ethics, so you probably agree that it is inadvisable to perform such a dramatic cull of the poorly performing members of your software team. However, how should you react when working with team members who do not perform adequately, or seem to willfully make the code worse?

What if the software team leaders do not notice or comprehend the problem? What if, heaven forbid, they are part of the problem itself?

Sadly, at the bleeding edge of the codeface, this is not entirely unusual. Although some teams are full of awesome codesmiths, many are not. Unless you are unusually blessed in your coding career, you will at some point find yourself in sticky situations that seem to have no solution.

Key

Often, the tricky part of software development isn’t in the technical aspects of the code; it’s the people problems.

When the programmers just don’t seem to get it, and fail to understand that they are making things worse, not better, you must respond.

Consider introducing practices that promote responsibility for the code and illustrate (in a way that avoids apportioning blame) how to work most effectively: introduce pair programming, mentoring, design review meetings, or the like.

Set an excellent example yourself. Do not fall into a trap of those bad habits; it’s very easy to lose enthusiasm and cut corners because everyone else is. If you can’t beat them, don’t join them.

Key

When surrounded by coders who do not care about the code, maintain healthy attitudes yourself. Beware of absorbing bad practices by osmosis.

It will not be simple or rapid to change a coding culture and steer development back towards healthy principles. But that doesn’t mean that it can’t be done.

Questions . How healthy is your current development team? . How can you quickly recognise when a developer is not performing as diligently as she should? . Which is most likely: people work sloppily on purpose, or they are sloppy because they don’t appreciate how to work better? . How can you be sure that you’re not adopting sloppy practices yourself? How can you prevent yourself from slipping into bad practices in the future?

Example 38-1.

Consider whether you have adopted any bad habits recently. How can you rectify this?