"All software has an expiration date by which time it must be rewritten from scratch." [closed]

Question

I stumbled upon a discussion between senior engineers and people from non-technical backgrounds and this seems to be a strongly held belief in some places.

I'm of the opinion that such a situation is purely down to incompetence on the side of the developers and project managers, those involved in creating the original system and those struggling to modify it now. Especial those who intersect both these groups.

Am I wrong? If so why?

If not, how can I convince developers twice my age that they need to change their approach to software development to overcome this problem and that rewriting the system from scratch every 2-3 years is not just an unavoidable fact of life.

Are there books or influential programmers I can quote on this issue?

Answer 1

Here's an influential programmer's opinion on the subject : "the single worst strategic mistake that any software company can make: They decided to rewrite the code from scratch."[1] -- Joel Spolsky

Answer 2

Consider just how many things can change over a short timescale: New OSs appear. Existing OSs get rebuilt. 3rd party packages appear, develop, drop off support or go obsolete. New hardware appears, including completely new devices and paradigms (eg. touch-screens becoming the norm).
Existing paradigms are exposed as having exploitable flaws and are abandoned, or just fade away from the market. All of these require your application to change, and none are down to incompetence of your seniors.

I wouldn't agree that software always has to be rewritten from scratch, but the only (and superior) alternative to rewrites is regular ongoing refactoring. The idea that you can write a whole application and it's done for all time is just plain wrong.

Answer 3

I used to work for a company that had source code that had "copyright 1984" at the top of the file. It was still in the codebase because it worked, and it hadn't been removed or replaced because it still worked.

There's a lot that does get rewritten eventually, but its so rare that it might as well be never. eg. TCP/IP is still with us even though we're attempting to get the rewrite of IP implemented. HTTP is still here even though it got a little refactored in HTTP 1.1, its still pretty much the same as it always was. There's plenty more examples.

The rewrite all the time crowd just don't know how to design software right first time.

Answer 4

“All software has an expiration date by which time it must be rewritten from scratch.”

That is true only for improperly designed and implemented software. For properly designed software it is true that:

"All sofware is completely replaced every so often."

But this is same as "Cells in human body are completely replaced every 7-10 years". That doesn't mean that person is completely reborn after time period passes, but bits and pieces are continuously replaced so there are no cells older than 10 years. Properly designed software should have same property. Especially if it is complex and big system. When platforms, frameworks and languages change, then it becomes much more expensive to develop for the previous ones. But replacing the whole system in one big rewrite is terrible idea, just like Joel Spolsky says. Instead, rewriting pieces that are too expensive to maintain is much more realistic idea. So over course of few years, you could replace practically whole codebase while minimizing the impact of not having working software for prolonged period of time.

Answer 5

Depends on the code, what it does, and who wrote it.

The right answer, of course, is to design and implement your software in such a way that it can be easily updated without having to be completely scrapped and rewritten every few years. Factor aggressively, deploy incrementally, test test test, and think ahead.

But...

There are some data centers that still run on '80s-vintage hardware and software because the risk of moving over to a new platform is unreasonably high; these are very high volume online transaction processing systems, such as an investment bank or an order management system for a multi-billion dollar coporation, where downtime is measured in millions of dollars per minute. Any switchover to a new platform¹ would have to be effectively instantaneous (less than a few minutes of downtime), and the new system would have to perform at least as well and as reliably as the existing system; from the end user's POV, the transition would have to be invisible.

That code isn't going to be scrapped anytime soon. Where possible, migrations are being done in a piecemeal fashion, but a lot of these systems are monolithic COBOL apps and not easily refactored; it simply wasn't a consideration back then.

---

^{1. Hardware, OS, database engine, application code, etc.; do you feel lucky?}

Answer 6

I can't imagine designing a system that would have to be scrapped, redesigned and rewritten after just 2 to 3 years, but I also don't want to make a blanket statement that it isn't a possibility. As there are many application domains in software development all with different needs and practices that are required to keep a company competitive. I suppose those companies where "time to market" is of utmost importance would fall in that category. Unfortunately, I bet 99% of the companies that make that claim, really aren't as "time to market" as important as they believe they are. A more robust application a few months later would likely serve their interests far better, but then building robust applications takes skill and patience, so it is easier to just make the blanket claim that time to market is why we aren't doing it right.

Anyways, I have worked with a fair number of "Senior" developers that I have ticked off immensely because I have made them redo work (sometimes many times over) that would have resulted in the 2-3 year easier to scrap than fix system if I let their work make it into the product. So being "Senior" doesn't necessarily mean that the person knows how to effectively develop software.

I don't believe there is a "right" answer to your question without knowing details about the application domain you are working in. Are the "rebuilt" systems essentially the same system with enhancements or are they really new applications? If they are essentially the same then your "senior" guys are dead wrong. They obviously are lacking in skills in many areas. On the other hand, if the new application is really a "new" application that only shares some similar traits as the previous application then maybe the "senior" guys are taking the more efficient approach.

Answer 7

Rewriting from scratch every 2-3 years seems extreme to me. But a reason one might decide to rewrite from scratch is because the requirements of the current system have changed so much they bear no resemblance to the original specs. Which means that the underlying architecture might not be the right one for the current requirements. So instead of a properly designed and coded system, you have a system that consists of patches and weird design changes that only make sense when you look at the progression of the requirements from day one.