There’s a story from this one scene in the interminably brilliant movie ‘Traffic‘ which I have never been able to forget (I went and found it on imDb).

You know, when they forced Khruschev out, he sat down and wrote two letters to his successor. He said – “When you get yourself into a situation you can’t get out of, open the first letter, and you’ll be safe. When you get yourself into another situation you can’t get out of, open the second letter”. Well, soon enough, this guy found himself into a tight place, so he opened the first letter. Which said – “Blame everything on me”. So he blames the old man, it worked like a charm. He got himself into a second situation he couldn’t get out of, he opened the second letter. It said – “Sit down, and write two letters”.

I’m not a very funny guy, but everyone I tell that story to, laughs … a lot

Recently, I’ve been thinking about it a lot in relation to software development. A few times in my career, I’ve come across a codebase that I thought was horrible/ridiculous/over-engineered/whatever, and my first reaction as a young developer was to ridicule or berate the the previous developer, loudly.

The funny thing is that it actually worked, initially anyway. The client was usually apologetic and cut me a lot of slack on deadlines and estimates. Then as I started to work on the code, I would begin to see why the developers made some of the decisions that they did. Maybe their pointy haired boss keeps pushing to get things done faster than is realistically possible, forcing the developer to write smelly code just to get done (“I’ll come back and fix it later!”), or there is some bureaucratic technical constraint that forces you to do things that appear very stupid at first glance. Sometimes, even, the developer was more advanced than I was and I couldn’t understand what they had written initially, so I just labeled it ‘overly complex’ because I couldn’t figure it out in one sitting.

The moral of the story is, professional courtesy matters. Always give the person that went before you the same kind of benefit of the doubt that you’d want someone coming after you to have for your work. Badmouthing the code you’re working on, can come back to bite you in the ass when you become its undisputed owner.  Be slow to do it, and if you must speak ill of the dead (so to speak), then be respectful, unless they absolutely deserve it (this is rare).

You see, the client/your boss will usually give you the time and resources to fix up the code, so you only get to blame the old guy for so long. Eventually, the question becomes “Why does the code still suck after all this time that you’ve been working on it?”. If you can’t answer that satisfactorily, you might find yourself out of a job, and who knows what the next guy is going to say about you?