Wicked Code

There is a particular class of problem, a Wicked Problem, that denies solution.

These problems are difficult or impossible to solve due to their complexity, a shifting or evolving context, and that’s if you can even find and identify them.

[caption id=“attachment_47” align=“alignright” width=“150”] Inigo Montoya: Wicked Code killed his father, craftsmanship will avenge![/caption]

Wicked Code is similar. Where Wicked Problems deny solutions, Wicked Code denies understanding.

The code might be misleading, with stale deceptive comments, or inappropriately named variables or functions. It might have such poor cohesion that it’s hard to find all the code that relates to an idea or function. Or it might be so tightly coupled that every change you make causes an avalanche of successive change.

I wish more developers practiced the Principle of Least Astonishment, and they might if they realized that they may only be astonishing their future selves.

Measuring your team’s adherence to the Principle of Least Astonishment is easy - just follow the WTF’s per hour metric. How many times an hour does someone on your team pause, staring blankly at their monitor, and mutter, maybe quietly, maybe loudly, “What The Absolute F!!!???”

Anybody who’s spent any amount of time in this field has lived with Wicked Code and tried to refactor it into submission. Once it’s gotten a foot-hold, it’s hard to shake. You might be familiar with the pattern: fork, try to fix, delete fork, repeat.

Wicked Code is curbed by good craftsmanship. Careful attention to how you express intent in your code. Careful naming. Be mindful of how you’re practicing disciplines and principles like the Principle of Least Astonishment.

As a software craftsman, it’s your duty to keep Wicked Code under control, lest you or your team fall into it’s spiral.