Toss Me a Rope: Programming Yourself Into a Hole?

ksyrium queries: "Managers tend to think that once a project is out the door or 'live,' it's done and over with, and assigns developers new project. However, with each project, another portion of each developers' time becomes devoted to maintaining said project. I've seen co-workers reach thresholds where there can no longer take on new work for sake of maintaining existing code. How are Slashdotters (developers and managers alike!) approaching this problem? Obviously, well-written and documented code can allow for faster maintenance by both the original developer and others, but has there been any organizational research done in the area of managing this problem? While I code for a living, my degree is in business, and this was a question dodged in all of my Management of Information Systems and Project Management courses. Google and other search engines haven't turned up much in the way of research, so I'd like to know what Slashdot thinks!"

Comments

Minefields

[4of12]

This issue has so many facets I don't know where to begin.

1. Some people program conscientiously, with maintainability in mind, writing lucid code that is easy for them and others to understand. It is easy to change, to extend, and is less likely to need changes or fixes.
2. Some coders have twisted minds unlike anyone else's. They code in a fashion they believe makes perfect sense, but heaven help the person appointed maintainer of the project. "Whaddya mean the codes broken and hard to fix? Fred's one of our sharpest programmers, as evidenced by him critiquing everyone else and no one able to understand his high level of intellect!"
3. Some people hack in a straight line to the destination in the shortest amount of time. Then, they or their successors spend inordinate amounts of time patching leaky pipes with bubble gum, baling wire and duct tape.
4. Some people delight in being indispensible for a project's existence. The code complexity becomes job security.
5. Some managers err by seeking to fix the unfixable and appointing poor slobs to a task that really shouldn't be done. Scrap it and rewrite would be the better option.
6. Some managers err by neglecting maintenance completely. If it's not a brand new shiny project, then they don't think they'll look sufficiently cool to the C level folks. The bread and butter applications are left to languish while the glittery new buzzword compliant project gets showcased up the wazoo.

and that's just for starters.

All I can say is:

"Be careful out there!"

Re:Minefields

[rgmoore]

And one goal of good management should be to encourage everyone to be in a useful category. So given the categories above, one might suggest the following approaches:

1. [Consiencious programmers] Reward these people. Given them raises, praise them publically, and encourage other people to look at and understand why their code is good.
2. [Smart but difficult programmers] Force these guys to work together with somebody else. Pair programming might be a good idea. It might not make the code that much better, but at least there will be a second person who understands how it works and can explain it to everyone else.
3. [Straight line programmers] These might be a good type to pair with those in group 2. Other than that (and trying to train them to be more like group 1) they may not be easy to work with. Perhaps they should be used as code maintainers, where they'll be working on smaller, more discreet problems where a straight line approach might be less harmful.
4. [Job security by obscurity] Force these people to maintain their own code until their projects become obsolete and you can fire them. Even better, route around the problem by putting them in teams where they can't get away with their tricks.

These are obviously just suggestions and ideas, but they get the general picture. Part of the job of a manager is to figure out how to use the strengths and weaknesses of his subordinates to best effect.