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

Re:Refactor

[Tablizer]

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

"Refactor" is simply a buzz-euphemism for "rework the code to make it cleaner". Many managers are not too fond of this because there is a risk that you will break something that used to work. The official solution is unit regression testing, however, that practice may not be approved.

Regarding GOF design patters, in my very humble opinion, GOF patterns are for people who don't know how to properly use a database, and would rather hand-knit nodes (classes) together the old fashioned way rathre than use relational commands/techiques to automate that process.