Here’s another acronym for your skillset: PITA

Let me tell you a scenario, and see if it sounds familiar. I know I’ve seen it in many manifestations over the years.

You start work at a new company. You meet the other developers who have been there for a while. They are intelligent, competent people who are up to date with the latest technology; they can talk sensibly about best practises and understand what makes good system design and implementation. And yet they are writing really dodgy code, or piling patch upon patch onto a godawful legacy system: trying to make the unscalable scale, or extend the inextensible. I don’t pretend to be immune; I’ve found myself doing it, on occasion. Why is this so common?

The obvious answer is that it’s someone else’s fault: the cowboy coder that put together the system in the first place, or the unreasonable demands of management. And there is certainly a degree of truth in these arguments. But while they give the comfort of being able to blame someone else, they don’t help you in a practical way. Unless you want to be stuck in a frustrated limbo forever, muttering “I can’t work with these amateurs!”, at some point you need to do something about it.

I am not suggesting a technical solution. For one thing, there is no silver bullet to dealing with legacy systems; each problem of this nature needs to be assessed, and a solution devised that takes into account the different technical, financial and human requirements and obstacles. Also, I assume that, if you identify with what I’m saying here, you will already be fully aware of a better way of doing things than Crappy Legacy System That We Somehow Got Stuck With.

The solution is actually simple: be a pain the arse. Don’t just say “Yes we can do this” to producers that want a feature added: explain to them, in terms they will understand, but without babying them, what the risks are in continuing to polish the turd / apply band aids to a fundamentally broken system / add features when stability is the main issue. Explain the damage it can do to the company’s reputation when things fall apart; how it will reflect badly on them, personally; and summarise the benefits of getting to a better place, and how much it will cost.

Don’t be inflexible. Suggest different ways of achieiving the objectives; rather than insisting on stopping development for three months while the whole team does a ground-up rewrite, perhaps suggest forking the tree and map out a strategy for dividing the work so that the system can improve while progress can still be made, and that new features are developed with a view to porting to the new branch once it’s stable. Try to be amenable and understanding, but don’t be a yes-man; that’s not doing anyone any good, not the producer or management or you. Much better to be a polite, gentle, but absolutely firm, PITA.

Another important thing is to stay in constant communication with the producer / project manager about any deviations between plan and reality, throughout the SDLC. A really common (and understanable) way that developers code themselves into a corner is when schedules are slipping, and they are afraid to tell the producer so - for fear, I suppose, of being considered incompetent. Don’t allow this to happen. If there’s a problem, keep them posted, and explain to them what slippage might be the result, and why. This is much better for you, because you don’t end up writing dodgy hacks at the last minute that you or your fellow devs will later have to support, and better for them, too, because they don’t get a nasty surprise days (or hours!) before an important milestone. Of course, if you’re slipping behind because you’ve pretended to know how to do something and you really don’t, well … learn your lesson and don’t do that again! :)

Also, try not to invest emotion in your suggested solutions. Stand back from the problem and weigh up your options. Don’t be afraid to be the bringer of bad news. If your input is not been taken on board, then there is something wrong with the company. You can always just walk away; at least in my neck of the woods (Sydney, Australia) the job market for a Flash/Flex dev is pretty sunny.

I should credit my old boss David Hargreave for a lot of the ideas in this post: he was very supportive to his team of developers, and an absolute towering PITA to the sales team and management on our behalf. Onya David.