Afterwood

Starting work on a mature codebase is always an interesting prospect. In some ways it’s like moving into a fully furnished home. As you wander around your new abode you’ll wince at the choice of wallpaper, soft furnishings, carpets and cabinets. As time passes those more superficial distractions will fade away and be replaced by the more niggly issues which actually affect your day-to-day life like the temperamental door lock, the broken light over the sink, and the low ceiling in the cellar. While it’s somewhat disingenuous to liken all mature codebases to the derelict house renovated by Mary Bailey (Donna Reed) in It’s a Wonderful Life, the scenes of frustration where George Bailey (James Stewart) accidentally pulls the finial off the top of the newel post every time he goes upstairs has a familiar ring to it.

It is all too easy when we come across some code we don’t like to be highly dismissive and even vocalise our displeasure. I don’t know about builders, plumbers and electricians in other countries but here in the UK they are renowned for looking at somebody else’s handiwork, shaking their head and then telling you they wouldn’t have done it like that. I guess that somehow that’s meant to make you feel more confident in their abilities because they can spot bad workmanship in others and by logical deduction theirs must be better?

The late, great Jerry Weinberg has some advice that’s worth bearing in mind when approaching a codebase that’s been around the block: “everything got the way it is one logical step at a time”. The evolution of the system happened under many constraints that we will not be aware of and it behoves us to be respectful of the choices that were made even if we don’t personally agree with them. Similarly ‘The Prime Directive’ which is commonly read out before a retrospective reminds us that we consider that people make choices which are a product of the environment they work in rather than through any personal weaknesses – the environment should not set you up to fail.

It’s easy for us when attempting to reshape a system towards new ends to become frustrated with the code as it stands and to lash out at the misgivings of our predecessors, even if that person is us. This negativity, which perhaps feels justified, does little to help the situation and if left unchecked begins to affect those around us. That famous poster from the Second World War tells us “careless talk costs lives” and badmouthing other people’s work when those involved may easily be in earshot or in the social network of those around us does little to make them feel any better about the choices they may have had to take. It always starts very innocently, often just a bit of ‘banter’, but slowly that negativity can become the norm. Sarcasm is a dangerous tool to wield in an open plan office where information disseminates by osmosis pieced together from fragments of other conversations within earshot.

But it’s our house, right? Surely that gives us permission to shape it as we see fit? Yes, but only insofar as we shape what’s necessary to allow us to overcome any hurdles placed in our way as a consequence of earlier choices. You do not automatically gain permission to simply remove the woodchip wallpaper because your personal preference is for painted walls. Aside from the waste of time and money it is disrespectful and does little to engender respect for yourself and your choices as your successors reflect on your actions in the future. Collaboration is not simply about communication with those present in the here-and-now but also with those who went before us and will be there to take over once we have moved on. Entropy always wins and therefore we need to be aware that those who come after us will likely be dealing with more complexity than we ever had to so let’s not make it any harder by throwing unrelated noise into the mix when it’s not an impediment to our current progress.

When a spot of refactoring is beneficial it can be a struggle to remain focused when we see paint starting to peel off the walls, the tap in the bathroom dripping and know the kitchen door needs a few drops of oil to stop it squeaking. None of these imperfections significantly hinder our day-to-day living but are just symptoms of age, and codebases accrete similar blemishes over time as the people, tools, and practices change – unsightly does not imply a liability.

Lucius Cary (2nd Viscount Falkland, according to Wikipedia) once said “Where it is not necessary to change, it is necessary not to change.” Taken too literally you might not even bother to consider the practice of refactoring or cleaning up code at all, let alone use it as a guide to reign in any overzealous changes that appear to involve tidying up every piece of unrelated code you passed through when debugging. The problem is that change is occurring all around us and therefore it may become necessary to change, despite not changing ourselves. While software doesn’t rot in the physical sense it could be said to deteriorate when inconsistencies in the idioms, layout, domain language, design, etc. begin to affect comprehension, at which point that may well become an impediment. Sometimes change is so slow that it is imperceptible at first, like an unused house decaying. Then, as the Broken Windows theory posits, a tipping point is reached where upon that dwelling rapidly deteriorates into the dilapidated form where Mary and George Bailey spend their honeymoon and eventually set up home.

Both refactoring and the (Boy) Scout Rule can, and often are, held up as a cause under which it’s okay to make sweeping changes in a codebase because they are ‘best practice’ and it makes the code ‘better’. Like many programmers I have my own personal crusades such as the banishment of ‘get’ in favour of more expressive verbs such as make, format or derive, and wider acceptance of domain types instead of an obsession with primitives. But they are just that – personal preferences – it is entirely possible to write a correctly functioning system without them.

Making changes in sympathy with how a system has already evolved, and will continue to evolve is hard. The temptation to ‘fix’ everything is very real but first we need to get straight in our heads what is actually broken or untenable and what is simply unappealing.

Chris Oldwood Chris Oldwood is a freelance programmer who started out as a bedroom coder in the 80’s writing assembler on 8-bit micros. These days it’s enterprise grade technology in plush corporate offices. He also commentates on the Godmanchester duck race.