3 ms·

Another thing I hate with pure maintenance programming is that you're generally told to touch as little code as possible. If it 'works', don't change it. Somet

Another thing I hate with pure maintenance programming is that you're generally told to touch as little code as possible. If it 'works', don't change it. Sometimes you'd love to refactor a bit of 10 year old C code to be more readable, or less bug-prone. But you can't because it's not a bug. In some cases it's even worse and you can't even fix bugs that you find. Only bugs reported by customers count as bugs. Of course, a customer will eventually stumble on it, but heh. I don't mind maintaining code as long as it's focused on structural improvement, not on manouvring through the code very carefully hoping the whole thing won't collapse.

gregjor 16y ago
There is code that really needs to be rewritten. If it's so creaky that you can't make any change without breaking other things, and you aren't allowed to refactor, that's trouble. I don't take on projects like that. But in my experience it's more common with web applications to find code that has lots of room for improvement, but isn't really falling apart. Most freelance developers/consultants immediately go to "we have to rewrite it," which the business can't afford right now, and therefore deprive themselves of the maintenance business.