Apps

Managers, let your developers go

Is a manager's desire to keep a programmer on after the completion of a project a poor use of that programmer's skills?

An important systems development project has just been completed. It is only natural to want one or more developers to remain behind. What if something goes wrong? What if everything grinds to a halt and you have a crisis on your hands? No manager wants that.

As a developer, I have always found a manager's desire to keep me on after the completion of a project a poor use of my skills and very frustrating. I would like to share some of my experiences with you and discuss how and when it is best to let a developer move on to the next project.

Hanging on to developers after project completion

At one company I was personally requested to automate the manpower reporting. At the completion of the project the same finance manager who requested my services wanted me to remain to support and maintain the system. This required very little of my time, and I became bored, unchallenged, and dissatisfied with the situation. I didn't want to offend the manager who provided work for me, but I needed to cut the ties and move on to a new project.

I did find a new project to work on by asking other department managers if they needed my services. Hopefully I didn't burn any bridges in the process. Both the company and I benefited by putting my skills to work on a completely different kind of system that was badly needed. The finance manager found another employee to run and support the manpower reporting system one day a week, and I was still available to maintain the system. Out of respect I should have done a better job communicating my frustration and needs directly to the finance manager, but I have no regrets about seeking a new project to work on.

How long should the developer stay?

A developer should not complete a project, pack his or her bag, and run for the door either. The support baton should be handed off to the appropriate in-house professional. Yes, the developer should be available for training, but the documentation should be the basis for the information passed on to the users and the support team. Testing the documentation is just as important as testing the software. There is no better way to do that than to have someone unfamiliar with the system try to support it by using the system documentation. If the documentation is lacking, the developer should update it just as he or she would a software update.

How long should the developer stay? The answer is until the system is performing as designed and can be run without the developer's help. That could be five days or five months. Consider a formal sign-off of the system by checking off each successfully completed task.

Managers should, when possible, let a developer develop. Good developers are by nature creative and need to be working on new projects. I also understand that there are times when a manager needs a developer to remain on to support the system and provide fixes or upgrades. If this is the case, let the developer know why he or she is needed to stay on.

The final word

I don't want to understate the importance of the support role. I know from personal experience how important and difficult that job function can be. I accepted my last IT position at CSC after hearing of the need for a VB programmer. Somehow I ended up spending more than a year in a support role for systems I knew nothing about. Surprisingly I wasn't bitter about it. I do remember saying out loud when leaving work one day "What am I still doing here? I should be writing VB code," or some such venting of my frustration.

I didn't learn many skills that could be used as a developer. You don't learn many useful technical skills building an OS/2 based data bridge and supporting systems long since past their prime. I learned that support wasn't for me. I also learned some project leadership and people skills. I was very fortunate to work with some exceptional support personnel in Norwich, Connecticut, willing to help me with the project.

I don't know how pervasive the use of developers as support personnel is among IT managers. I would like to hear from developers who feel they were stuck supporting systems after the project completion. If you are a manager, please share your perspective as well in the forum.

About

Alan Norton began using PCs in 1981, when they were called microcomputers. He has worked at companies like Hughes Aircraft and CSC, where he developed client/server-based applications. Alan is currently semi-retired and starting a new career as a wri...

23 comments
binduv
binduv

existing development team member as support team will expediate the support process. as the developer will be well informed about the system.

anandsham2007
anandsham2007

Rolling model will work. 6 month as developer and 2 month as support executive. It will help organization as well as developer to grow.

AhmedAba
AhmedAba

Maintenance role is for junior programmers, its a good chance for them to learn how experience programmers do smart coding and tricks. One of my ways to learn a new language is maintaining an application written by the desired language.

Bernard Bana
Bernard Bana

"Maintenance role is for junior programmers, its a good chance for them to learn how experience programmers do smart coding and tricks. One of my ways to learn a new language is maintaining an application written by the desired language." -------- Yes! This can be a good idea. Just make sure that all changes are properly tested and documented to avoid creating more harm. But please, not on a critical production environment. And in any case, ensuring that all codings and revisions were checked-in on your version control system will do the trick. Thus, strenghtening your statement that juniors or even non-original programmers will be able to learn while sustaining a previously developed software.

Tony Hopkinson
Tony Hopkinson

Small maintenance patches are a fairly low risk way of introducing a new / junior developer into your environment and the domain, equally so with an experienced one but new in some way. I can't believe the first sentence. I mean you have got to be kidding. Much of the code I've been asked to maintain, which only an idiot would let a junior touch is chock full of the worst coding examples you could find. That's why I'm maintaining IT!

Alan Norton
Alan Norton

That's a great way to learn and it frees up more senior developers to do what they do best - develop. The question is whether junior programmers can modify existing code without completely messing it up. Perhaps they could with the proper supervision. It's an excellent suggestion. Thank you for taking the time to share it.

erica.j.henson
erica.j.henson

I only believe having junior devs doing maintenance on applications gives them a sink-or-swim opportunity to learn an environment first-hand for future opportunities. There are few teachers better suited for "here's our mess and learn it". However, unguided by more experienced creators of the mess they're supporting, the context is missing and I think that is a recipe for disaster. I also think it is a very bad practice to have a lesser experienced crowd handle the majority of the app support for a dev group, especially on critical applications. We have that here and it is pretty much Fail. It only works on near-legacy applications because they've been around forever and the knowledgebase there is solid. Because the support analysts also make maintenance changes, it ends up being a snowball of frustration. Support is frustrated because they didn't create the app, nor were they included in any real design or dev discussion. Devs are frustrated because they end up having to half-support their code when it changes (and it always has to change at some point). This model does not work from what I see and have seen. The only thing I've seen successfully work is a hybrid-type approach where you have senior devs include the support staff initially (and those are two distinct groups) and the support staff has enough coding ability to understand what is being created. In the middle, there must be knowledgeable, strong managers who can help ensure there is balance between the two and that the relationship between support and development is solid. This helps both the devs turn over their apps and move to the next new project and it helps the support group understand and (god I hate this word) synergize with the dev group to get the support context that is mandated. Without the knowledgeable manager to help bridge those situations, it falls apart. (I've seen that more often than not. And especially where EMPIRE is more important to upper management than sound development practice, it is worse.) Just my two cents. :) E.

Tony Hopkinson
Tony Hopkinson

But you need pretty good retention rates. The two real problems are. Academia does not teach people how to write maintainable code. In commercial sofware development, rapidly evolving requirements, technologies, and rate of change in business goals, means quality gets sacrificed on a regular basis. Generally that means, no documentation, no standards, no testability, useless audit trails, and misleading annotation. Note poor or incomplete documentation is often worse than none. At that point you need the guy or girl :D who did it, because they are the only ones with a vague clue, how we got into this tip. Who's 'fault' it was is irrelevant. Any developer who said to me I'm too good for the maintenance cycle, I would bin on the spot. Anyone who was happy to stay in existing and not work on new I would cherish, until they were no longer required....

Tony Hopkinson
Tony Hopkinson

What part of maintenance is not development? What happens if, when developing you do not bear maintenance in mind? How many changes to the requirement while devloping, do not get implemented exactly the best way? How many changes do not get implemented at all? How much documententation gets produced, during the development cycle? Particulary the why. How much of the cost of maintenance is comprehension? Pair of you have just illustrated the real IT business divide. All software changes, all code has to be maintained, any measure that makes this more difficult increases cost and reduces quality, none more so than the feeble minded assumption, the because a product has been released to market that it's well written and well designed. Can be sold at a profit, is the only requirement, therefore good enough now, is all that is desired.

Tony Hopkinson
Tony Hopkinson

Other people's code is what I do. I'm good at it for a very simple reason. My first major project required me to do 3rd line support and devlopment and to train 1st and second. Get woken up at two in the morning by a big hairy shop floor type, losing 40% of his wage, because you can't understand your own code a few times, you'd learn it too, and fast. :p I'd add it to your list if I were you, at least the rose tinted glasses you are wearing would be ditched. You wouldn't want big Fred to think you were a puff as well as incompetent. :p "IT manager who knew what he wanted", where did you find such a paragon? I've never met one, well not one that didn't turn out to be lying, or seriously into self deception. Maintenance coding in a live system, requires far more ability than greenfield, only a total nut would let some untrained newbie at their live system. This is actual revenue, not potential.

Alan Norton
Alan Norton

No Tony, I am not kidding. "What part of maintenance is not development?" At a large IT services company where I worked, support and development were separate groups - very wisely in my opinion. This can't always be done, for example, in smaller companies. "How many changes to the requirement while devloping, do not get implemented exactly the best way? "How many changes do not get implemented at all? "How much documententation gets produced, during the development cycle? Particulary the why." Last week I was looking through some of the notes for one of my consulting jobs. I had printed out emails detailing all of the changes requested to the system I was developing. Fortunately I was working with an IT manager who knew what he wanted and told me exactly what changes should be made. I noticed that I had checked them off, one by one, as I had completed each item - and there were a LOT of them. I made sure all user and system documentation was complete and all requested changes were made before asking for the final sign-off. The sign-off was a mere formality. I had delivered what the IT manager wanted. I have developed a number of client-server systems. I have only been contacted once due to a problem with one of the systems. That is not to say there were not changes made. No doubt changes were made, but the original developer didn't need to be consulted. Edit: Formatting

Bernard Bana
Bernard Bana

I am managing a group of highly talented systems developers and one of the biggest challenge that I need to handle is how to keep them motivated. Assigning them on one sigle project will suppress their creativeness and boredom will creep in because everything will be routinary eventually. The next time you know it, attrition is already on top of the pareto of your organizational issues. I should know, I am a developer by heart. Being a manager, we should be able to put our resources to where it could add the best value to the company. If we allow our programmers to handle the sustaining tasks after they completed the development phase, we are placing them on the lower scale of the value chain. Not beneficial for the company, our department, and for the staff. The key here is to ensure that the developer is following a established systems development process. A practice that takes care of the development, testing, training, change management portion, etc. The same process will enable us to develop agility and flexibility on our operations. In addition, we could already involve the person whom we are eyeeing to sustain the system even on the early stages of the SDLC. Making it easy for the original developer to transition to his new projects.

Alan Norton
Alan Norton

Bernard, "Being a manager, we should be able to put our resources to where it could add the best value to the company" Brilliant statement. You are absolutely right, but often a manager's performance is measured by a set of metrics. I know - I collected and reported such metrics for years. The manager focuses his energies and the department's resources trying to improve those numbers. The best use of corporate talent is difficult to measure and as you say, often it is attrition numbers that are used. That is rather like shutting the barn door after the horse has galloped off down the shady lane. I don't envy your challenge motivating your group of 'highly talented systems developers'. Just your awareness of the issue puts you way ahead of the game.

Tony Hopkinson
Tony Hopkinson

Find things for them to develop, and the reward them for success. Demotivating them is equally easy and often seen as a business imperative, don't let them develop and then reward them accordingly. Support/maintenance should be far more challenging than greenfield. If you've got people who shy away from that, replace them. Of course that's a waste of time, if you think reducing cyclometic complexity is a waste of money, or that making code readble is unncessary, or that refactoring is only for people who can't get it right first time....

sysdev
sysdev

I have been in data processing for 45 years (yes 45) in many different roles from computer operator, then programmer, and several other through senior management and then consulting (only 34 years). One of the really stupid things I see regularly is letting people go once a project is implemented. The problem is that when something happens (days weeks or years later), the knowledge is gone. There is a mainframe payroll/personnel system which has been around for 30 years and is used to pay millions of people every week or month. The company has been sold several times, but they have managed to retain (as consultants) a couple of people who have some knowledge. There are thousands of programs in the system and millions of lines of code. Most of that code is untouched because there is no knowledge about how and why the code works. This is astoundingly dangerous and when the few who have any knowledge retire or die, there are going to be major problems. This is only one example of several similar 'time bombs' I have seen. If you do not keep the people around long enought to get the knowledge transferred, you have just turned on a 'time bomb'. There are lots of ways to slit your throat. This may not be the nastiest, but sure is expensive.

ppg
ppg

If you have developers that can?t or won?t do maintenance you should take a serious look at the way staff is selected. There is nothing like knowing you will have to maintain a program to ensure that it is designed to be maintainable. The model that is used in our department is that there are only programmer analysts and they move from maintenance to development as required. Only on large projects are contract developers brought in and it always works best if there is strong in-house involvement in design decisions.

Tony Hopkinson
Tony Hopkinson

The only reason knowing you have will have to maintain encourages writing maintainable code, is it justifies the unpaid overtime, trying to make tomorrow easier. If unmaintainable code is being produced. There are only two reasons They were stupid enough to hire incompetents. They were too stupid to resource doing it properly. Writing maintainable code is a set of good habits you develop (no pun intended) as you gain experience. After a while it's easier and quicker to do so. The reason people get into this mess is they take as a given the dividing line between getting to market and staying in the market. It's just coding and designing, phase is only relevant in terms of a different set of constraints. Code you don't need to maintain is dead, change is a given.

Tony Hopkinson
Tony Hopkinson

Never seen a complete IT project of any description ever. Not making them managers, that's a different ball game altogther. You are n't keeping a devloper by doing that, you are swapping him for in general,a crap manager. Not because devlopers are universally crap at management, but becasue you can't do both jobs well at the same time.

pawelbrodzinski
pawelbrodzinski

There's a bit of conflict of interests. Typically developer would like to move on and manager would like to keep someone to maintain software once it is completed. What worked for me a number of times was aggregating new projects along with some maintenance work within one team. Then you can either choose a person who does all maintenance for different systems but just for some time (e.g. month or two) and then switch to another person or you may just keep people maintaining their own work for some time during a week when they don't work on new projects.

Alan Norton
Alan Norton

Interesting concept. A compromise of sorts by sharing the support task among the team. That is certainly better than sticking a developer in a support role without a clear end date. Thanks.

erica.j.henson
erica.j.henson

I've been both manager and developer and still flirt with both roles presently. I manage integration processes and software releases, but I have a solid background in software engineering and still automate build functions in that role. I definitely agree with the perspective that most developers (not all, because I wasn't) just want to develop and can be nearly pathological when asked to deviate from that role. I also have seen where money and hiring freezes can really dictate the enforcing of an unnatural fit of "we need you to do this and you need a job" kind of thing. Letting go of a "developer" means there's a hole to fill and you can have Catbert-esque HR groups that stranglehold an ability to fill that hole. When that is the case, the ability to keep a developer in their happy place (which IS better long-term for the PROJECT as well) doesn't happen. It creates a situation where a software creator becomes software supporter and you are absolutely right where it chokes the life out of the creative spark most devs have. I've been there. I personally enjoyed the aspects of support, however, and it gave me a very solid idea of how integration should work. Without a background in support, how to pin a beautiful app into an existing flawed architecture would have been missing. I do think a lot of developers should check their attitudes and want to learn this important lesson if they ever want to graduate past "code monkey". From another management viewpoint, I think there's either an overall misunderstanding of the animal known as "developer" and what that entails, or there is a total lack of concern because funding/position seem to dictate what can happen and cannot. It's not clear to a lot of "managers" that you would not hire and force a banker, for instance, to give guidance on how to lay the foundation of a house you're building. The banker might arrange the financing of the sale of the house, but the skillset required to actually build the house has nothing to do with that. In some situations, it can be dismissed as "well, both job functions are about x application so it is the same." Ill-informed belief compounds an already misunderstood skillset embraced by programmers. It may be that you've opened Pandora's Box. :) E.

Alan Norton
Alan Norton

Erica, "I do think a lot of developers should check their attitudes and want to learn this important lesson if they ever want to graduate past "code monkey". Attitudes - yes that is a good word for it. For the most part I have done what was asked of me and always tried my best. But when I was younger I had that 'attitude'. I write about it in the article. You can call it ambition or desire to climb the corporate ladder. To my manager I have little doubt that it was called 'attitude'. "From another management viewpoint, I think there's either an overall misunderstanding of the animal known as "developer" and what that entails, or there is a total lack of concern because funding/position seem to dictate what can happen and cannot" I think so too. I also believe that most managers, even IT managers, never really knew exactly what I did as a developer. Worse, I never was very good at marketing my accomplishments. The two roles are very different and really require different breeds of IT professionals. Having a developer support systems they never created is like asking a rock singer/writer to catalog country music. Sure, he could do it but he probably won't like it and the only 'lesson learned' will likely be that he doesn't like country music or cataloging! He knew that already. I value your comments since you have done and are doing both. Thank you for taking the time to share them and in such an articulate way. You really are quite quotable!