Lifespan of Software: How often do you expect to do start from scratch?

Question

I've heard people say that the average lifespan of software is about 3 years, but that seems shockingly low to me. I don't buy it.

After all, some of my clients have lumbering mainframes that have been around for 20 years, and they're so entrenched that they might live forever.

I personally tend to start talking about severe refactoring when the platform gets so old that it's bad for our skills (we are contractors) and otherwise inefficient to keep maintaining the project. I'm thinking about ASP Classic here. That can be a 5 to 8 year window, and it doesn't even need to be a rewrite.

Of course, I have also seen projects that incurred a lot of technical debt because someone caved to stakeholders too often or a dev didn't know how to plan for change. Or the project was started on a weak platform that didn't scale well. That radically reduces the lifespan.

Maybe those projects are the ones that tend to live 3 years. Or less.

One last thought: Some studies have proven that it's cheaper to maintain old code than to write new, and I believe it. Rewriting large systems is always way harder and more expensive than it looks.

Does all of this conspire to indicate that developers tend to re-write too early, and perhaps naively? I'm thinking yes, and I can see how that's an easy mistake to make.

What are your experiences here?

Answer 1

My first employeer, we started building in 2000, the application still exists after 8 years on the same architechure. They started a process of rewritting it which has stalled; however the application is now considered legacy, and all new features are built on a new platform.

3 years seems really short.

Answer 2

Of course it depends on the technology domain, but three years seems a bit low. Some say it takes as long as ten years for good software to mature.

I've seen some projects where the stakeholders say "we can rewrite/replace [big system] in six months" and they are still trying several years later.

Answer 3

It's often impossible to justify a complete rewrite unless you can really quantify what the benefits to end users will be. Otherwise, you're leaving them with the same piece of software for 2 years while you go off and redesign yours. Meanwhile your competitors are busy adding new features instead of recreating existing features with new bugs. Maybe the decrease in maintenance costs will make it worth it in the long run, but you're risking a big loss in market share in the meantime.

I think you're better off with small, safe refactorings that can occur concurrently with new feature development. You might not be able to achieve everything you want but at least you'll have something shippable in the meantime.

Edit: in response to "What if the platform dies? As in ASP Classic again" - well then you're not rewriting your code every X years. Your platform has been discontinued. Of couse this doesn't mean that suddenly all ASP classic servers out there die, it just means that there won't be any more updates to the platform. Then you have to weigh the cost of redeveloping the application versus the cost of it being harder to attract/maintain people to work on it. Cobol could be considered a dead end but there are still a lot of Cobol apps out there that people are maintaining because the company thinks it's more economical to do that than to rewrite them. So the choice to rewrite or not is still a business decision.

Answer 4

The less often the better.

But honestly, 3 years is very short. Especially for an average.

The reality is that you generally only start over when you absolutely can't grow, when you're technical debt is so high it's better to go technically bankrupt. And even then you can often re-org your debt.

The key to long term success is to try to keep your technical debt to a minimum at all times.

Answer 5

The team that I'm working on has been developing the same web application for 6 years, and there's no end in sight. In that time, it's gone from Classic ASP to ASP.NET 1.1 to ASP.NET 2.0, so various modules have undergone incremental rewrites, but never anything like a from-scratch rewrite. Every so often somebody will say how nice it would be if we could start over, but we have 60,000+ users: there's no way they're going to wait the 12 to 18 months it would take while their updated functionality or features sit on a shelf.

I've only had the chance to do a ground-up rewrite twice. In both cases, the reason we had time and buy-in to do so was because we had a rather small group of customers using an already stable version. When we went to them with the new product, they all agreed that it was better than the old system, but very few of them bought it because they were already happy with what they had. It was a lot of fun for the programmers, but ultimately it was a loss for the business.

So, from personal experience, the things that you get to start from scratch every 3 years are likely not used by many people. When you've got a widely used application or service, especially in a corporate environment, it's hard enough to get buy-in to do gradual upgrades, let alone rewrites.

Answer 6

I don't think the 3 year estimate is measuring time between total rewrites. It's more likely measuring the time between major releases of the same software (I'm thinking of Windows and MS-Office, for example). The next major version is very probably not going to be a complete rewrite, just an upgrade.

Answer 7

I'd say never.

Writing an app is much more than coding. When you rewriting everything, it's never from scrtch since you have the Xp from the previous analysis, the production run, the bugs reports, the day to day use, etc.

You have data you will have to port, too.

From scratch ? Nope. A lot of the job is already done, making it easier, and a lot of previous work needs to be adapted, making it harder. In the end, it takes as much time to create that the first time, but you did not do it ex nihilo.

Answer 8

Reasons I think 3 years is probably right.

1. A new major system (ERP, CRM, etc.) is implemented and it has an "integrated" module to replace the old app.

2. Same, but no integrated app - but the existing app is not adaptable (the people left, technology has changed, current IT policies have changed, users don't like the existing app.)

3. The company you acquired the basic app from, to customize it for your needs has disappeared.

4. Or you don't get along well with them any more.

5. The technology for the existing app is "obsolete" (according to the framework vendor/Microsoft/consultant/industry expert/new IT manager who has management's ear.)

6. "We're phasing out (Windows 95/Windows 98/Windows 2000/Windows XP/NT) and we need matching technology in our apps".

7. "We've learned a lot from (App Version n) and we'll do a lot better the second/third/fourth/n+1th time."

8. Job justification for developers/IT manager/Division VP/consulting company.

9. The users hate it.

10. We've merged/acquired a competitor/been acquired by a competitor and theirs is better.

That's just a start.

There are very few applications whose basic features weren't satisfactorily implemented a long time ago in dBASE running on DOS. Which could have been migrated and been available today via Foxpro. (And damn, they would run fast.) Notice Foxpro doesn't come up much around here - it just keeps purring along in the background. (Disclaimer - I haven't touched an xBase framework in 15 years.)

Answer 9

it depends on how well the business was modeled, including anticipated future areas of change, how involved the stakeholders/users were, and especially how well the software system was maintained.

For example, the first full business automation system i ever wrote "my way" (i.e. where the stakeholders listened to me and I listened to them and we took the time to interview all of the users and really do it right) is still going strong 21 years later. It will be gradually rewritten over the next couple of years not because there's anything wrong with the software, but because the IT Director thinks (and I agree, though he didn't ask me) that it would be better to migrate the apps from DataFlex to .NET.

Many of the application systems that I have written or contributed to are still going strong 5, 10, 15, and 20 years later. Without exception it is because the stakeholders/users were heavily involved in the process, we anticipated future changes to the business, we took the time to do it right, and we made sure that the maintenance team did the same.

On the other hand, from what I've seen, the average lifespan of bad software is about 3 years, because that's how long it takes for the users to get really sick of it, the managers to get tired of hearing about it, and the executives to decide to "do something" about it. Unfortunately, many 'rewrites' stipulate "keep the same interface" to avoid retraining, which leads to another bad system and starts another 3-year cycle ;-)

Answer 10

It depends entirely on what you do. For business software, longer wait times are almost always good. I make browser MMOs though, and I've found that with the sheer volume of editing, and rewriting large chunk of codes that I'm always doing to improve the games, it helps to rewrite from scratch or near scratch on a near annual basis.

Of course, being a couple guys working on relatively small projects, we don't have nearly the scaling issues that a lot of the rest of you do. It makes it a lot easier to justify redoing it.

Also, not having to report to managers probably helps us some, too.

Answer 11

The code base I work on started in 1980; there is still evidence of code from 1984 in places, if you know what you are looking for. There's little doubt in my mind that some, possibly even most, of that code should be improved (and no doubt that it could be improved). But a 3 year cycle is very short in comparison with that 30 year span. Some code has been thrown away since then; more probably should be. But planning to restart every three years would seem profligate to me. For a complex system - think Perl, Python, Ruby, a C compiler, a C++ compiler, a DBMS - you'd be laughed out of court with a 3 year throw-it-all-away cycle. At the end of 3 years, you might have a moderately decent system that another 5 years will bring to a nice polish. So, at least in my part of the world, you need to think in terms of code life in cycles of 10+ years.

Answer 12

I've got 19 year old code still in production, albeit with heavy modifications down the road.

In reality it should have been scrapped at least 5 years ago as it had grown FAR beyond the original design and is being constrained by design decisions that made sense when it was originally written but are nuts now.