It's an adage of software engineering that most of the cost of a project is maintenance after the initial development effort. But is this really true?
Organizations certainly don't seem to act like it's true. Software shops tend to discourage refactoring because the perceived short-term cost (in breakage) is more than the long-term benefit (in maintainability). Possible explanations:
Software shops are shortsighted. They should refactor more.
Engineers don't distinguish between productive refactoring and useless tinkering. Managers can't tell the difference either.
A lot of code doesn't benefit from refactoring. Most of the maintenance costs of a project are concentrated in certain areas of the code. The trouble is, it's impossible to tell which areas until you've already shouldered the maintenance load and it's too late.
The venture capital model of funding software development has an overwhelming cash flow problem that basically destroys any company that thinks long-term (before it gets to the stage where that strategy would pay off).
So many projects fail that the best strategy is to get your project to the point of cancellation as soon as possible. (Too cynical?)
Refactoring really works, but it's not the best use of your time. You can outgrow your debt. Invest your time in work that grows your company (like shipping the product sooner). The maintenance costs will seem insignificant tomorrow, as long as you keep growing. (Too optimistic?)
Hmm. Ideas 4, 5, and 6 all suggest that internal software departments in large non-software companies (intranets, accounting systems, that sort of thing) should have better code hygiene than hotshot startup companies. Is this true?
No comments:
Post a Comment