18 March 2009

Swamp Waders and Watchmakers

I used to be a nasty hacker. I mean I used to write horribly twisted unmaintainable code.

It was as if this was my manual. It was fun!

But much later, after I finished high school and then university and eventually started being paid to write code, I started to work on systems which did not have the property that all of the concepts and implementation details of the system were in my head.

I began to prefer cleaner code.

Cleaner code led to fewer mistakes, faster changes and relied less on memory of the system when returning to it after an absence.

When I started to prefer cleaner code and worked for a while on systems where the code was comparatively clean, I started to sense a kind of allergic reaction whenever working on code which was disogranised, inconsistent and swamp-like.

It disgusted me and my occasions of exposure to the swamp were overwhelming. I have worked with guys who slithered past the many traps and gotchas, unmoved to clean up. I remembered that I used to be like them.

I remember never really thinking about the meaning of names. Why not just "x" or "w", or "foo" or "grandma"? I expected just to have my own symbol table in my head. Keeping all the mess in my head was a sharply honed skill.

I was a swamp wader. But I have since evolved.

I had become more like a watchmaker. I chose to keep things in their proper place. All the delicate sprockets and springs, neatly arrayed on sea green felt.

With everything in its place I refactor with confidence to bring the few strays into line. I revisit forgotten code and my expectations of being insulated from failures in unrelated parts of the code are capably met by the beautiful mechanisms. Names infer purpose. The code speaks for itself. I sought to only work with like minds.

Unneeded, my swamp-wading skills dwindled.

But sporadic outings into swamp lands were disorienting so I started to worry that being a pure watchmaker put me at a disadvantage. What if a nuclear holocaust wiped out all the quality code and I was forced to fend for myself in the swamp? How would I put food on the table and gadgets in my pocket?

I knew I needed to train myself. To follow a regime of tortuous swampy puzzles. Like writing Perl. And assembly. To maintain my mental toughness.

These days, decades after I began in the swamps I no longer suffer from the watchmaker's nervous discomfort in the presence of swampy code. I wade in when I have to. I do tend to cultivate things a little here and there but resist creating islands of pond-scum topiary amidst the impossible wilds. When I can I will isolate and subdivide. I'll leave signs and make paths. If there is time I may do more, but sometimes I just have to get dirty.


  1. Please elaborate specifically on the traits of swampmakers and watchmakers. You cover their actions; but I think you are thinking about more than you shared in the post.

  2. Hi Grant,

    Yes I was quite severe in editing my original draft (though perhaps it doesn't show). I hope it didn't make the post too obtuse.

    The traits of Swamp Waders and Watchmakers are not mutually exclusive in an individual, however, they are features of different strategies for management of complexity in code.

    Swamp Waders are able to navigate complexity without cleaning it up. They do not expect order to be present and rely less on the hygiene of the system in order to proceed. Their strength is that they are optimised for poorly organised code which is prevalent in some places.

    Critically, Swamp Waders can make modifications to messy systems without a negative emotional reaction to greater unforeseen problems which comes with this approach. They expect that things are always like this and probably estimate it better than Watchmakers. Perhaps being faced with this kind of complexity is an adrenalin rush. Many young coders like creating little jungles for their own enjoyment!

    Watchmakers are less able to navigate complexity during fix work. They prefer to make changes in isolation of other effects because they like the predictability. When code is organised and well factored (and obviously well unit tested) then there are fewer surprises. Predictability allows the developer to commit time without concern that it will be wasted by the need to do rework.

    Watchmakers are characterised by a sharp dislike of rework and late discovery of hidden work and the conviction that better organisation could often avoid the rework and make more of the task visible before starting.

    What do you think? Does this accord with anything you know about effective developer discipline?