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

Development model

[Nyarly]

The most evident source of the problem you're describing is that how you model development in your organization. There's an old model called the Waterfall, that basically says, you get requirements, you write spec, you design to spec, code to design, test the code, and release. It's called the Waterfall Model because each step assumes that the previous step is finished; in other words, you never go back.

First of all, the premise of the Waterfall Model is just wrong. Of course you go back. You'll always find a flaw in the req's in mid-spec, and a flaw in spec in mid-design (and a flaw in req when you go back to fix the spec) etc. There's an entire class of development models that are just fixes on the Waterfall Model. But the basis is flawed, and any model based on it is going to be flawed as well.

The solution to your specific problem is one that you've seen other companies use, possibly without knowing. Once a piece of software is feature complete and passes QA (so you release it), a certain number of developer hours need to be devoted to maintenance. Probably that means hiring a junior coder to maintain the well written code of more senior coders.

There comes a point, of course, where software is no longer paying for its maintenance. It's always legitimate to move an old version to a "mature" state, where it's no longer supported. If Microsoft can do that to Windows98, I don't see why any other company can't do that with (say) their Win98 software.

Re:Development model

[ed1park]

The Waterfall Method is a methodology of software development that exists because certain software projects have very little room for error. (think NASA, life support, avionic systems, etc.)

Proponents of the waterfall method reason that for such critical software systems the normal write/test/debug cycle is too dangerous.

To simply dismiss this methodology with such a blanket statement is irresponsible.

Re:They think it's done

[Prior Restraint]

My situation is a little different. I work on internal development, so "customers" means other employees of the same company. Anyway, our customers give completely inflexible deadlines: Deploy what you have done, period. They control IT's budget, so we have no real say-so. We allegedly have a maintenance team, but since they have zero understanding of the system, even from an end-user's perspective, all the bug-fixing, etc., invariably falls back on us. Since the customer doesn't understand the concept of maintenance, they can't figure out why we aren't spending 100% of our time on the new project.

An interesting corrolary (sp?) is that no money is allotted for maintenance, so all maintenance gets charged to the current project, which is already thread-bare as it is. In theory, if this keeps up long enough, we'll someday have a project whose budget is all spent on maintenance.

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.