When You're The Legacy System
Tuesday 24th September, 2013
There comes a time in any developer’s life when you, or rather the software you’ve developed becomes “legacy”. Chin up. This may have very little to do with old age, and quite a lot more to do with the internal politics of the situation, especially if you work for a large corporate. So what do you do?
Acceptance
It’s happened. It’s probably nothing you’ve done. It may not be because the current system, your system, has anything wrong with it. But if you’re a small systems developer, chances are your work is at the local scale, and a company-wide roll-out means exactly that. So goodbye to any ‘local colour’. As the great prophet Francis was heard to opine, “That’s Life”. Get over it.
Appreciate The Other Guy’s Position
Imagine if you’d been brought in to replace the existing system. The new guy has three problems. You’re the first one. Make his life easier - don’t be the ex-husband. Get out of the way. Start by making sure that the new guy actually only has two problems, one practical, one political. On their own, they’re big enough without you getting in the way. And more to the point, you can, and in fact you should, help with both.
Problem 1: Functionality
The new system has to replace the old in terms of function. The closer the match, the easier the transition will be. Make yourself available to the new guy, do it in a friendly manner, and don’t think you can necessarily charge for it. You need the transition from yours to his to be as smooth as can be. IF this means migrating data, explain your schema, and see how it will fit into his. Show him how to use your tools to do this. If you aren’t going to charge for it, it’s not unreasonable to make him do the work (as he is charging for it.) Figure out where his system is better than yours, and vice versa. Write it up for him, as a list of suggestions. He may thank you. (He may not, but the trick is to be as objective, even-handed, and fair as you can be.) Figure out workarounds for the users, who are used to doing things the old way.
Problem 2: Politics
Unless they’ve asked for it, I’ve found that users don’t always like novelty. In your own work, New Features either have to be ‘for free’ or require a low level of training before they’re immediately acceptable to the user community. Unless your legacy system was an entire dog’s breakfast, an entirely new system is going to be met with certain distrust and possibly hostility. Don’t make it harder, by whinging. (If the replacement does fall short, you’re much better praising the bits that work well and falling silent when the missing elements are discussed.) In short, don’t kvetch.
But Why Be Helpful?
- To do your best work, you need to sleep soundly at night. Give your conscience a rest.
- “It’s the professionalism stoopid”. Actually, yes it is. Call it what you like, do-unto-others, pride-in-your-work, whatever, but yes, it matters to you. Whining doesn’t make you a better developer, or person. (This is not the same as bending over and taking it.)
- Your client may have other work.
- It may still all go wrong. Yep, call me cynical, but I’ve seen it happen plenty of times. New brooms don’t always make the workplace any cleaner. If it’s clear that you’re not to blame, chances are they may ask you to clean up. Then you can decide whether you want to or not.
- You may learn stuff. As a client told me last week, “Every day’s a school day.” Indeed. The other guy’s technology may be useful, and there’s never a better time to see it in action than when the developer needs it to be on its best behaviour. The Law of Demonstrations means that things will go wrong, and you’ll get to see the weaknesses, and hopefully how to fix them.
- The other guy may have other work too.
- Cynical point #2: The other guy might not want your help, and may make this clear to you, and to others around you. You can only do so much for some people. Chances are if a developer is unwilling to accept help, then unless their name is Rodney McKay, chances are their going to come a cropper. The trick to car crashes is to be the non-participant observer. Make sure your are being helpful though, and not just pushy. Offer, but don’t press.
##Two Caveats Regarding Pronouns
I’ve said ‘him’ and ‘he’ throughout this. Yes, it’s just a shorthand, but sadly, until now, I’ve yet to meet a female developer in my line of work. Fingers-crossed though.
I’ve also written this from the point of view of your software being replaced; as an exercise, go back and re-read it with the pronouns his/your and he/you reversed.