Slashdot Mirror
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!"
I don't know how they can think it's done since they are the ones who told you to work the bugs out while it's in production. It went out the door buggy, and so it stays buggy, because some incompetent ass had no clue why you were begging him to wait to ship it.
Anyone else have problems with this?
/* oops I accidentally made a comment, sorry */
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
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.
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.
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
rage, rage against the dying of the light
There is, of course, a "simple" business solution. Rule 1. The only things that get done here are the things that we have been paid to do. We only do things that will get us paid (X times) more than it costs to do. (or, at least, *think* we will get paid to do. If we think wrong, too big or too often, we go out of business.) :)
Rule 2. The only things we pay to get done are those things that (we think) will get us more money than we spend to do it.
If you are a developer, see Rule 1.
Your customer should be using Rule 2, unless it is a public entity, where they use Rule 3: Is the action perceived as contributing to a final goal or thought to contribute to a realized goal (support) that still has money on the contract?
You may now shoot holes in my explanation...
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
rage, rage against the dying of the light
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.