Does working with Legacy code need a change in attitude?

Sometimes I can’t resist the urge to grumble to colleagues when confronted with systems developed in a way I would not have chosen. Maybe I just need A change in attitude.

On the other hand, often the frustration comes from knowing that there is a better way, and I’m not sure that learning to love legacy code is that easy.

One Comment

  1. As an ambitious contractor thirsty both for new and exciting stuff and for delivering the goods quickly, I often find working on legacy code as frustrating as you do – though as we know from working together, Frank, I’m often disappointingly less radical than you in dealing with it! Because it’s a significant source of stress in my working life, I’m always on the lookout for anything which will help me change my attitude – which is partly a matter of exhibiting more humility. It isn’t easy.

    One starting point involves reflecting on an analogy with taxi driving. I worked on a job which involved taking 2 or 3 taxis a day, and I got to know some of the drivers pretty well. (Many were burnt-out ex-company directors, interestingly.) One of them said to me: “When the traffic was awful, or some idiot was driving like an arse in front of me, I used to get really angry. Then one day I realised that if I carried on this way, I was going to have an early heart attack. The traffic jams, the idiot drivers – they’re just part of the job. Unfortunate though it might be, my job is not to drive at 30 miles an hour through the city – if it was, I’d constantly be thwarted. Instead, it’s to get someone to their destination as soon as possible given all the frustrations over which I have no control and given all the skills I have in minimising constraints over which I do have some influence.”

    I find the analogy between software development and taxi driving useful. ‘Legacy’ code isn’t (usually) code written by idiots, any more than most traffic jams are generated by incompetent driving; it’s just code you weren’t involved in writing. And much of the value of a skilled developer lies in their ability to choose safe routes through less than ideal territory – though unlike the taxi driver, we can sometimes build entirely new roads.

    And again by analogy: like most drivers, I am a hypocrite. I curse someone for driving too close; then within minutes do the same thing myself. Equally, I’m sure my code is as often the cause of WTF moments as the code I’ve inherited. But just as it behoves drivers to pay attention to the quality of their own driving, I am well aware of the need to minimise the WTF-ness of my own output. Accordingly, I try to make it expressive, testable, etc etc. I know that however good I am at that, though, there will come a time when someone lands on a particular piece of code I’ve written and say “why on earth did you architect things that way?” – and that this may simply be because they haven’t been through the same journey I and the rest of the team have. In other words, all code is legacy – with all that that implies – to those who don’t share the mental model developed by the team who wrote it. Most teams I’ve worked with have done too little to make that mental model readily accessible to those who come after them.

Comments are closed.