01 December 2005

Maintenance costs and software engineering decisions

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:

  1. Software shops are shortsighted. They should refactor more.

  2. Engineers don't distinguish between productive refactoring and useless tinkering. Managers can't tell the difference either.

  3. 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.

  4. 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).

  5. So many projects fail that the best strategy is to get your project to the point of cancellation as soon as possible. (Too cynical?)

  6. 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?

1 comment:

Mattie said...

My comment would be along the same lines as the comment I posted before.

These topics are hard to answer. Here's a few random thoughts:

The shops I've worked for had a good bit of refactoring, it's just that we did very little refactoring work in the current release. It was always branched off and integrated back after the release (at significant expense) for the next version.

Obviously, the fundamental reason people choose maintenance over refactoring is because it is scary to alter the foundation you live on. We know that we're going to have costly incremental problems, but we have no idea how bad the regressions might be if it is refactored. (Hell, often these are the same wackos who designed it poorly in the first place.)

It's taking the known road over the unknown, and I feel the risk-aversion of established companies will push them down the known road again and again.

The customer feels this, too. It's not just the company. And it's not just in software.

I know when I buy a brand new, completely redesigned model of a car, I'm less confident on how it will behave (as opposed to one that is basically just an incremental change from the year before). I can't fall back on historical information on how many recalls, what the common problems are, etc. Sometimes I buy the new car because I want what's flashy, but it doesn't make me excited to be one of the first few owners of a model that hasn't been used by millions of people already.

Then again, I may just be a software engineer who sees a risk in refactoring (in terms of regressions) better than the average person. Who knows?

I think that's why TDD is so hyped right now-- they really try to give you back a little more comfort regarding a refactor. I.e., if you try to refactor at least you are guaranteed (in theory) to have a hell of a lot of unit tests to help you catch regressions and make you feel better about the change.