Supporting other people’s work

A fellow developer recently posed a question on LinkedIn, along the lines of “Should I take on the support of an organically-grown legacy software system?”.

Written as advice to the developer, our response was:

Imagine you’re a mechanic who is asked to work on a car. You can see that all the doors have been replaced as they are all slightly different colours. One of the windows has plastic sheeting over it, but that doesn’t matter because nobody ever sits in that seat. The badge on the back says it’s a Honda but that really does look like a Citroen gearbox. You get it up on the ramp and have a look underneath it. Oh dear: you can see that at least one well-meaning amateur has gone at it with a welder in one hand and a lump hammer in the other. There’s a nice new clutch, though, which apparently is still under warranty. You take it for a drive and it rattles like nobody’s business and if you take your hands off the wheel it pulls to the left. It’s not looking great.

You’ve been working on cars for the last ten years, and have certificates to prove it. You’ve seen some shockers in your time but – this!! You know and I know that the owner needs to scrap it and buy a nice little Toyota with a 5-year warranty. But he loves it to bits and nothing else quite drives the same. Besides, look at all the money he’s spent on getting it fixed over the years. (And it brings such enjoyment too, ever since he bought his own welding kit a while back, too… Sunday afternoons are such fun now! Next weekend his wife and kids are away, he might have a go at fitting some sails, and turning it in to an amphibious craft. You can’t do THAT with a new Toyota!)

If this car comes in to your garage for a new windscreen, fit one. But you’re there to fit a windscreen. Don’t be taking the blame when he drives away and the exhaust falls off.

This is not meant as criticism of the client: it is not his fault that he doesn’t understand the best practices of welding. Furthermore, sure as anything, the developer wouldn’t be able to run the client’s business the way the client can. Each of us is expert in our own field, so what is needed here is an honest and respectful exchange of viewpoints. A compromise can probably be reached, but neither client nor developer should enter in to this sort of arrangement without a full understanding of the facts as seen by the other party. It’ll vary from case to case what is in the best interest of the developer, the client, and the client’s business.

The LinkedIn article can be found here: http://lnkd.in/saAW-X