5

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?

Improve this question
20
  • 4
    all software is a bit too general, many a qsort work as well now since it was first implemented,
    – ratchet freak
    Feb 19, 2014 at 13:59
  • 1
    It feels like I've heard this quote apply to the American Constitution before.
    – Joe Z.
    Feb 19, 2014 at 14:14
  • 5
    2-3 years is rather extreme. 10 years, yes I'll support that. But 2-3? Unless the company makes money from the rewriting...in which this is a technical decision for business reasons.
    – Tundey
    Feb 19, 2014 at 14:57
  • 2
    I would agree that the majority of software designed to be native in appearance (ie: exclude webapps and software with its own look and feel) might need a face-lift every 2-3 years to match evolving OS aesthetic standards. This would match the difference between, for instance, Windows 7 and Windows 8, which certainly requires a rewrite to appear native. However, that shouldn't necessitate rewriting from scratch, assuming a strict separation of concerns was followed in the original architecture.
    – Michael
    Feb 19, 2014 at 15:02
  • 2
    Well, look at it this way. Software is written to meet requirements. If the requirements don't change, then the software doesn't need to change. It is possible for requirements to not change every 2-3 years. Also, what's your software stack? It matters, because some technologies tend to deprecate significantly faster than others (.NET vs COBOL, for example).
    – user16764
    Feb 19, 2014 at 15:15

7 Answers 7

Reset to default
20

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

Improve this answer
0
14

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.

Improve this answer
4
  • 1
    >The idea that you can write a whole application and it's done for all time is just plain wrong. Where does this idea come from? Are you sure you're answering the right question?
    – user2675345
    Feb 19, 2014 at 14:30
  • 1
    I'm not sure what you're arguing, then. You seem to be saying that the only reason for an all-out rewrite is incompetence. My point is, there are plenty of factors which simply cannot be anticipated which can force your hand.
    – Julia Hayward
    Feb 19, 2014 at 15:51
  • You listed reasons why code must change not why it must be rewritten from scratch which is what the question is actually about.
    – user2675345
    Feb 19, 2014 at 17:18
  • Eventually, you will reach a point where the fundamental design decisions, which were perfectly accurate at the time, no longer match the current world. There is only so much you can refactor and at some point you will likely reach a point where you have some type of performance/stability problem from this process. At that point, you are likely going to need to rewrite. I would stay away from the term "complete rewrite", because I think there will be plenty of code that is re-usable, but conceptually you need to break down the old model and build a new one.
    – cdkMoose
    Feb 19, 2014 at 17:29
10

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.

Improve this answer
8
  • I don't think the OP is talking about TCP/IP or HTTP.
    – Tundey
    Feb 19, 2014 at 14:11
  • why? its still software, though I take your point about it being more a design than an implementation, the implementations of them tend not to get rewritten either.
    – gbjbaanb
    Feb 19, 2014 at 14:21
  • 1
    HTTP at least is perhaps not the best example. HTTP is in many ways barely fit for the purposes we use it for, and HTTP2.0/SPDY was essentially pushed through by Google controlling enough of the stack to do it. If we could have updated HTTP we likely would have, but it's a shared protocol and that makes it a public API of a sort, which we all know is concrete and cannot be changed lightly. Heck, the HTTP spec misspelled "referrer", it's difficult to hold it up as perfection.
    – Phoshi
    Feb 19, 2014 at 14:22
  • @Phoshi it is possible to replace http - Chrome, Firefox et al just need to implement a new protocol and we can start using xyz://www.blah for sites that use the new protocol. Enough people use Google as a URL location service they wouldn't even notice!. However, http still works even though we are changing our requirements of it. Nevertheless, it shows that something that works is still better than a rewrite, if you can accept a fudge factor in using this old stuff then you don't have to spend all your time reinventing it and can do something more productive.
    – gbjbaanb
    Feb 19, 2014 at 14:43
  • I think HTTP and other well-spec'ed software aren't good examples because I don't think the "small company" the OP mentioned is talking about software on that level. There's been times when I look at some code and thought to myself "why the heck would you do it that way?" Then I remember, this codebase is old as heck and things have changed in the interim. I'll argue that code that old need a rewrite because their original purpose has changed so much since inception. HTTP's purpose hasn't changed that much. So that's not a good example.
    – Tundey
    Feb 19, 2014 at 14:55
6

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

Improve this answer
1
  • That's an interesting way of interpreting it thank you.
    – user2675345
    Feb 19, 2014 at 17:05
2

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 platform1 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?

Improve this answer
2

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.

Improve this answer
0

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.

Improve this answer
2
  • this post is rather hard to read (wall of text). Would you mind editing it into a better shape?
    – gnat
    Feb 20, 2014 at 6:35
  • I can't think of any way to make it more succinct. Feel free to make any edits you want.
    – Tundey
    Feb 20, 2014 at 16:36

Not the answer you're looking for? Browse other questions tagged or ask your own question.