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!"
Fred lays out the data that was, even then, industry wisdom. According to the research IBM did, an average programmer can maintain 3 existing projects or work on 1 new one. But that's just an average. If the programmer is under 30 he can only maintain 1 (or be one of 3 junior programmers on a new project). If under 25 he is only fit to write documentation.
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?
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.