What will you do with the no-longer-effective programmer?

Question

A programmer on your team is great at maintaining the old legacy system. But the company has switched to a new technology/platform.

What do you do with the no-longer-effective developer?

Answer 1

Try to smoothly move him to the new technology/platform - first give him small assignments, then bigger ones, then move him completely.

If he's a good programmer he will learn and adapt, if not, explain to him that he will have to think of another position - either in the same company or in another one. It's business, not his playground.

Answer 2

Presumably the company is still in the same business so this guy would have years of hard earned domain knowledge which could be leveraged in a technical/project management or BA role. Also, if you have existing clients that are reluctant to move to the new platform he'll be invaluable in a support role as none of the new guys will understand the legacy stuff.

Answer 3

People can become 'no-longer-effective' for a variety of reasons ranging from loss of enthusiasm, personal problems, disillusion with the company or management, fear or weariness of technological change, inappropriate use of recreational drugs, etc, etc.

Presumably they were once valued and effective employees. A humane response is to find out what the problem is and then find a way to make that person feel good about themself and their job again, so that they can once again help the enterprise become productive. A person in the position that you describe is obviously not happy about now being unproductive or being seen by other, luckier or more talented colleagues as 'no-longer-effective'.

So I don't like the way your question is framed, as if that person has become a problem and a burden: it lacks humanity. If you phrased it this way, the answer might become clearer to you more quickly.

"I find that I'm no longer an effective developer and I'm scared that I'll soon be unemployable. The world has changed around me. What can I do to get my employer to help me through this and bring back my sense of worth and self-esteem?"

PS I'm 52 and have managed to keep at the cutting edge, mainly through contracting and always using new technology, but I see a lot of people in the position you describe. They're human beings before they are programmers or employees.

Answer 4

Tell him to learn the new technology, and provide a reasonable amount of time and help to do so.

Answer 5

If you can't train him on the new system, you will have to let him go. Or you could promote him to "project manager" and wait until he screws up, then fire him.

Answer 6

I think that until you have old software in production, you always need guys with knowledge of the old platform. Imagine if all people that can work on your 20 year old cobol program are gone away, and one day the customer call you telling that something is wrong..... I've already seen this situation before ;)

Speak with the member of the team, explain to him that the company is moving towards different tec/language/platform etc, and offer him the possibility to have courses or training material to keep up to date with company business.

If he do not want to spent time to learn new stuff, you can always try to use him in different areas. Experience is always important, even in technologies you do not use.

Suppose you work for a company that work in visual basic .net, you have two programmers to choose from, the first has 1 year of experience with visual basic .net, the other has 15 years of experience in low level C++/assembly programming. I probably will hire the second one, even if he does not know anything about visual basic, he surely have great amount of experience to share.

alk.

Answer 7

Keep him, for at least two reasons:

• If the old legacy system is still in production, he is still competent for maintaining it.

• He surely knows better than anybody not only how the old system works but also what it does in its most hidden parts. This knowledge is greatly valuable when specifying and designing the new system. Your guy has a role to play in building the new system, even if he is not involved in new technology.

Answer 8

The best approach is proactive: make sure to give employees programming legacy systems some percentage of tasks that involve new technologies. This makes them more valuable to the organization, and increases their job satisfaction. What's not to like about that? ;-)

And if you are the person involved in legacy code, do spend time learning new technologies, on your own time if you have to.

If you can't directly apply what you learn to your legacy code, you can always leverage newer technologies for peripheral software engineering tasks such as source code control, configuration management, bug tracking, project management (eg, the Scrum approach to agile project management), documentation, support, and so on.

Answer 9

Aside of what has been said, I think you should also consider whether or not the legacy system has back up value. Especially if you have just made the move.

Consider the hypothetical scenario below:

Step 1. Implement brand new shinny tech.

Step 2. Move legacy tech programmer to whatever else (or fire)

Step 3. Discover a critical bug in new tech, or vital data/processes supported in legacy system but not by the new one.

Step 4. Oups...

If the guy has been "great" there are very reasonable chances he will be able to learn the new system. He may not know the technology involved, but he does know the purposes & features of the system. He knows what the system does and why, you just have to show him how.

Now of course, if he really can't get it and that you are sure that the legacy system is ready to be donated to a museum...

Answer 10

You have asked this question, means you are in a dilemma, means you like this guy's work and you did say that he is good with the legacy code.

One who is good at one thing can be good at others too (I believe so)

Tell your programmer that CHANGE is inevitable and tell him to start change his technology and set a realistic and mutually beneficial goal and enforce the schedule stringently.

If he can adopt he will survive else he will learn to find a new job. [Note: My comments and suggestions are what I though would help you but it does not guarantee 100% success.]

Answer 11

The obvious, non-funny answer, is to give him training. Not give him a book and tell him to learn the new system, but give him proper training, send him on a course, have him learn the system from the people currently using it, shadow them at their work for a while, ask questions and so on.

Answer 12

There are several factors here:

1. Size of the company
2. Likelihood of returning to the old tech
3. Willingness of the employee to switch to the new tech.
4. Company's perspective on the value of employees

If you are talking about a small company (<10 people); it is probably far better to cut bait and search for new talent than to spend time retraining that employee; both for the company and that person. Companies that small can't afford having unproductive people on payroll for very long.

For a larger company, the other 3 items take precedence. If there is even a hint of going back, then keeping that person is pure insurance. Likewise, if the employee is enthusiastic about moving to the new tech (and ways of doing things) then they can bring all of their past experience to bear on forging ahead.

Finally, if the company actually values their employees they will attempt to encourage that person to mold themselves into the new environment. Be careful here though, encouraging an employee who has no interest in change doesn't work out for anyone.

---

I've seen this issue go both ways. In one case an employee was happy about the switch and spent vast amounts of their own time getting up to speed; they were ultimately able to provide a lot of insight and value.

I've also seen those who went along with the tech change kicking and screaming: they should have been let go much earlier than they were. However, the company felt an obligation to keep trying with them. I ran into one such person a year after they finally cut him: he was far happier in his new job.