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

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.

Re:Change jobs

[smittyoneeach]

And you run into amateur work. I was really quite fascinated, after much study, to realize that some goofball had used JavaScript to force radio buttons to work as combo boxes...