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

It all boils down to individual task management.

[stienman]

Each programmer should have a good grasp of their assigned duties/tasks. It doesn't matter whether the tasks are maintenance, new work, documentation, training, etc. It all boils down to time and task management. If you are stretched too thin maintaining previous projects such that it's impacting current work you need to re-prioritize, often with your superior.

The problem is that people don't leave time for these little tasks, and they accept them without rescheduling other (perhaps more pressing) tasks.

Eventually you'll have to drop maintenance for a project, or reassign that task to another programmer. But most important is to listen to the sales person describe the problem, then point out that they need to go to your superior to have the 'new' project approved and let him push other deadlines around to suit his schedule. If it's your responsability to juggle all these tasks then you'll spend more time doing management than programming eventually, but you'll have to weight and prioritize each task.

In other words, I suspect it's not discussed/researched because it's really a non-issue. The real problem is time and project management.

-Adam

Change jobs

[crow]

People wonder why tech workers have a tradition of changing jobs. This is one reason. When you move to a new job, you rarely have any legacy projects to support in addition to the one you're assigned to.

Re:Change jobs

[Kris_J]

When you move to a new job, you rarely have any legacy projects to support in addition to the one you're assigned to.

Ha! Not only do you have to try and repair other people's dodgy code you typically have to learn to do it with new tools and sometimes in a new language.

Just keep working at the problems in your current job. If you're good, maintenance on prior jobs will slowly decrease.

Nah

[Anonymous Coward]

Products have life-cycles. Work on a product does not stop on the day of release - a good manager knows that. But a good manager also knows that nobody lives forever and software doesn't either. So when the product has reached its end-of-life status, programmers should not devote more time to the "dead" project and instead devote their time to new projects. Programmers and managers alike sometimes need a nudge to recognize this essential fact.

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

[pthisis]

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

Hopefully that doesn't mean deprecated. Most projects I've been involved with (I'm talking internal projects here) start from scratch, have a heavy design, development, and testing phase, and then launch live. The first month or two sees heavy maintenance work, and then the code stabilizes and requires basically no hands-on work.

Obviously when new feature requests come in they destabilize the codebase for some time, but you can and usually do get equilibrium: projects that have no development going on generally need no maintenance after they've had a bit of time to mellow.

And that's what I see as a mature project. The ultimate goal of every project I'm on is to reach maturity and just run.

Sumner

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.

Stabilization period

[pthisis]

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.

That is a problem. You need to get managers to understand that once a project launches, there's going to be a stabilization period that's just as intense as the development period. It can be short or long depending on the project, but it needs to happen.

And you need to get programmers to believe that they _can_, in fact, get the code to a state where it just runs. That means having watchdogs to monitor it rather than people (sending email when it dies, and avoiding false positives). That means taking the 2-3 (or 20) hours to fix things that require "just 5 minutes" of attention every day. It also means isolating the system into as many independent parts as possible so that it's manageable and easy to work with.

As an example, I worked on developing a massive dynamic content system for a past job. It required a GUI for content authors to do input with, a way to schedule and deploy changes, a server to select content based on user parameters, a way to track content to see what was served where, inventory analysis of what web space would be available, etc. It took over a year to develop, had more than 15 seperate executables built from 75,000 lines of code, and was hell when it launched in terms of making sure it ran happily with all the other systems in place. One daemon needed to be restarted occasionally; sometimes unforeseen log data screwed up reports; etc. We could have just gone ahead and restarted that daemon when it needed it, fixed the logs by hand, and so forth--instead we put the up-front time into fixing the root causes of each of the tiny maintenance chores as we identified them.

Within 3 months it was pretty much hands off, and would send email alerts when something went wrong that the watchdogs couldn't handle. Moreover, because it was 15 seperate components, feature enhancements were generally easy: change one small program instead of a huge monolithic one. We went through several iterations of feature requests over the following year, each one followed by a stabilization period, and eventually got it to the point where it does everything we needed done and did it without needing handholding (and serves 6 billion requests per year).

That's what you need to aim for as a programmer--ongoing maintenance tasks when you don't have feature requests coming in is a sign that the code needs to be more robust.

Sumner

You must be new...

[xagon7]

Here is how it works in the REAL world...

Developer is hired by the company.

Developer maintains legacy code left by previous employee.

Developer gets ancy and an opportunity to perform new development.

The new project is released.

Developer has to maintain "his" project while performing other duties and gets burned out.

Developer finds another company, and the whole cycle starts over again for both parties.

Refactor

[Webmonger]

The solution to this sort of problem is easy to say:
Refactor.

You will get feature requests, and sometimes you'll just have to bolt them on. But look for the general case that this new feature is a specific instance of. Sure the feature may be "change the text on the cover page", but the general case may be "make it easy to customize the text on the cover page".

Sometimes the generalizations aren't easy to find, even though you intuit a connection between things. Flip through Design Patterns, and see if anything sparks. You may have to just bolt it on for now, but keep thinking.

Refactoring will reduce the number of lines in your code. And it will make the code easier to understand and maintain.

Re:Refactor

[shoppa]

GOF patterns are for people who don't know how to properly use a database

That statement, my dear sir, is a glowing example of a specific anti-pattern: Golden Hammer.

Yes, relational databases are one way of solving a problem. The instant you decide that it's the only way to solve the problem, you become part of the problem.

Not about writing code?

[Anonymous Brave Guy]

I coulda sworn Code Complete was one of the best books I'd ever read about good style in writing code. Were you perhaps thinking of Rapid Development by the same author?