4 ms·

"We'll do a rewrite, simplify everything, get rid of all the edge-cases." Guess what? It turns out that all those edge-cases were there for a reason. You neede

"We'll do a rewrite, simplify everything, get rid of all the edge-cases." Guess what? It turns out that all those edge-cases were there for a reason. You needed them. And by the time you've added them back, or equivalents, two things have happened. First, you've burned an order of magnitude more time than you budgeted for the rewrite. And second, you have a codebase every bit as gnarly as the one you started with. First rule of rewrites: don't do it. Second rule of rewrites (for experts only): don't do it yet.

FeepingCreature 8y ago
Sometimes the reason has not been relevant for ten years, though, like when a codebase is filled with horrible hacks to account for the fact that you only have 64MB of RAM, while running in a vm with 4GB.
- perlgeek 8y ago
  That is right, but you should be able to point at (preferable several) such assumptions that went into the original system, and verify that they are no longer necessary. Maybe you used to have much less RAM in the past, but also much less data, or not as many users etc.
- marktangotango 8y ago
  I worked on a java swing app that was deployed to a phone center as a Citrix app. Each instance was allowed only 64mb. Use if Citrix sidestepped all java version and deployment issues. Anecdote why memory limits can be relaxant today.
yen223 8y ago
Or maybe, the edge-cases were there because they were written on top of assumptions that proved to be obsolete.
- Waterluvian 8y ago
  Yup. I'm in the midst of rewriting a certain part of a robot fleet system. A lot of what we are replacing is obsolete or never needed or poorly implemented. But the first generation was good for its own reason: get a functioning system to market before everyone else and start learning everything about what's right and wrong with the design. I really hate this cute quote about rewriting because it's elitist (you have to be an expert to do it right) and generally sells the false idea that rewrites aren't a valid part of iterative product building.
havkom 8y ago
It is often junior ppl who request rewrites. Junior as in * have been exposed to few real-world development projects, or, * have little understanding for the interplay between development and business. (The junior developer may however be very good at programming in languages X, Y and Z.) Many developers will be junior under this definition for all of their career. The exception I have seen from this is consultant sales ppl, who want to use the hype of the new often untested (or for the task non-optimal) technology or paradigm X. When the original system was written by developers who were not junior, as is often the case with large successes systems that have survived, the result from letting junior developers rewrite the system, will be predictable. Tip: Be cautious when listen to developers that talk about “technical debt” and similar. Make sure they are not junior developers under the definition above or are just not that good at reading code and understanding real world systems. Similarly, when listening to a sales pitch by a consultancy firm, make sure they have your interest in mind.
alkonaut 8y ago
The edge cases aren’t removed, they are considered in the architecture of the rewrite while they were square pegs in round holes in the old system. So rewriting and knowing the full scope is a luxury that allows a much better design. The problem is that in the new system there will be new cases that don’t fit the new design. Rewriting shouldn’t be a decision taken lightly but it also shouldn’t be avoided at all cost. The alternative isn’t massaging your old system when the technical debt weighs it down too much. The alternative is just maintaining it without improving it, which eventually sees the system overtaken by competitors.
davemp 8y ago
This is a harmful tautology. There really is a such thing as bad code. Some edge cases are introduced by the bad code itself and changing the paradigm can make many difficulties disappear. Having the same people who wrote the code work on the rewrite is silly though. How could they be expected to produce something better?
- stormking 8y ago
  > Having the same people who wrote the code work on the rewrite is silly though. How could they be expected to produce something better? By learning from their mistakes?
  - davemp 8y ago
    Here’s a famous quote about organizing personnel: “I divide my officers into four classes as follows: The clever, the industrious, the lazy, and the stupid. Each officer always possesses two of these qualities. Those who are clever and industrious I appoint to the General Staff. Use can under certain circumstances be made of those who are stupid and lazy. The man who is clever and lazy qualifies for the highest leadership posts. He has the requisite nerves and the mental clarity for difficult decisions. But whoever is stupid and industrious must be got rid of, for he is too dangerous.” I would say the 4th class of people are the ones likely to churn out a horrifying codebase. Such people are also unlikely to be able to recognize and learn from their mistakes.
    - sosborn 8y ago
      Your premise falls apart if you consider the role that management/leadership plays in the process.
      - davemp 8y ago
        I disagree. The quote is for where to place personnel in a leadership hierarchy. A leader without the appropriate aptitude is obviously harmful; but I would say there are actually no grunts in software. Every developer has to lead at least themselves.
radicalbyte 8y ago
It depends. One system I worked on was an information system in VB6 which was being used as a base platform to build domain-specific ERP implementations. Deployment in their environment to anything non-browser-based was a nightmare. There was overlap between domains although there was shared data (customer and supplier information, product database, that kind of thing). The obvious thing to do here was to let each domain (i.e. team) build their own solutions in the most effective platform for their domain whilst integrating via defined interfaces. That's not what happened; when I left few teams had anything working and those who did spent the majority of their time on deployment issues. Another system I worked on was initially built by a very junior team under tight time and budget pressure under leader who believed in never saying "no" to the customer. They created a horrible mess (most of the code was in a couple of files). The system was deployed by two/three customers. Testing was done during deployment; the first version worked well enough to go into production. A year later everything had ground to a halt; there was no formalised testing and the developers couldn't fix one bug without introducing several more. One very smart developer started to "rewrite from the inside" by implementing new features using clean and modern techniques. At that point I took over the team. We doubled down on this "rewrite" whilst adding manual tests (and later automated tests) to cover the most important flows. We only rewrote features when they needed to change and in some cases removed functionality when particularly hairy features no longer worked. Otherwise I advise against rewrites; if the system was reasonably built and the platform viable then rewriting is just a waste of money.
tonyedgecombe 8y ago
Yes, there is often a lot of domain knowledge embedded in that legacy code. The sort of information that is difficult to tease out of the business or understand by looking at the code.

FeepingCreature 8y ago

Sometimes the reason has not been relevant for ten years, though, like when a codebase is filled with horrible hacks to account for the fact that you only have 64MB of RAM, while running in a vm with 4GB.

perlgeek 8y ago
That is right, but you should be able to point at (preferable several) such assumptions that went into the original system, and verify that they are no longer necessary. Maybe you used to have much less RAM in the past, but also much less data, or not as many users etc.
marktangotango 8y ago
I worked on a java swing app that was deployed to a phone center as a Citrix app. Each instance was allowed only 64mb. Use if Citrix sidestepped all java version and deployment issues. Anecdote why memory limits can be relaxant today.

yen223 8y ago

Or maybe, the edge-cases were there because they were written on top of assumptions that proved to be obsolete.

Waterluvian 8y ago
Yup. I'm in the midst of rewriting a certain part of a robot fleet system. A lot of what we are replacing is obsolete or never needed or poorly implemented. But the first generation was good for its own reason: get a functioning system to market before everyone else and start learning everything about what's right and wrong with the design. I really hate this cute quote about rewriting because it's elitist (you have to be an expert to do it right) and generally sells the false idea that rewrites aren't a valid part of iterative product building.

havkom 8y ago

It is often junior ppl who request rewrites. Junior as in * have been exposed to few real-world development projects, or, * have little understanding for the interplay between development and business. (The junior developer may however be very good at programming in languages X, Y and Z.) Many developers will be junior under this definition for all of their career. The exception I have seen from this is consultant sales ppl, who want to use the hype of the new often untested (or for the task non-optimal) technology or paradigm X. When the original system was written by developers who were not junior, as is often the case with large successes systems that have survived, the result from letting junior developers rewrite the system, will be predictable. Tip: Be cautious when listen to developers that talk about “technical debt” and similar. Make sure they are not junior developers under the definition above or are just not that good at reading code and understanding real world systems. Similarly, when listening to a sales pitch by a consultancy firm, make sure they have your interest in mind.

alkonaut 8y ago

The edge cases aren’t removed, they are considered in the architecture of the rewrite while they were square pegs in round holes in the old system. So rewriting and knowing the full scope is a luxury that allows a much better design. The problem is that in the new system there will be new cases that don’t fit the new design. Rewriting shouldn’t be a decision taken lightly but it also shouldn’t be avoided at all cost. The alternative isn’t massaging your old system when the technical debt weighs it down too much. The alternative is just maintaining it without improving it, which eventually sees the system overtaken by competitors.

davemp 8y ago

This is a harmful tautology. There really is a such thing as bad code. Some edge cases are introduced by the bad code itself and changing the paradigm can make many difficulties disappear. Having the same people who wrote the code work on the rewrite is silly though. How could they be expected to produce something better?

stormking 8y ago
> Having the same people who wrote the code work on the rewrite is silly though. How could they be expected to produce something better? By learning from their mistakes?
- davemp 8y ago
  Here’s a famous quote about organizing personnel: “I divide my officers into four classes as follows: The clever, the industrious, the lazy, and the stupid. Each officer always possesses two of these qualities. Those who are clever and industrious I appoint to the General Staff. Use can under certain circumstances be made of those who are stupid and lazy. The man who is clever and lazy qualifies for the highest leadership posts. He has the requisite nerves and the mental clarity for difficult decisions. But whoever is stupid and industrious must be got rid of, for he is too dangerous.” I would say the 4th class of people are the ones likely to churn out a horrifying codebase. Such people are also unlikely to be able to recognize and learn from their mistakes.
  - sosborn 8y ago
    Your premise falls apart if you consider the role that management/leadership plays in the process.
    - davemp 8y ago
      I disagree. The quote is for where to place personnel in a leadership hierarchy. A leader without the appropriate aptitude is obviously harmful; but I would say there are actually no grunts in software. Every developer has to lead at least themselves.

radicalbyte 8y ago

It depends. One system I worked on was an information system in VB6 which was being used as a base platform to build domain-specific ERP implementations. Deployment in their environment to anything non-browser-based was a nightmare. There was overlap between domains although there was shared data (customer and supplier information, product database, that kind of thing). The obvious thing to do here was to let each domain (i.e. team) build their own solutions in the most effective platform for their domain whilst integrating via defined interfaces. That's not what happened; when I left few teams had anything working and those who did spent the majority of their time on deployment issues. Another system I worked on was initially built by a very junior team under tight time and budget pressure under leader who believed in never saying "no" to the customer. They created a horrible mess (most of the code was in a couple of files). The system was deployed by two/three customers. Testing was done during deployment; the first version worked well enough to go into production. A year later everything had ground to a halt; there was no formalised testing and the developers couldn't fix one bug without introducing several more. One very smart developer started to "rewrite from the inside" by implementing new features using clean and modern techniques. At that point I took over the team. We doubled down on this "rewrite" whilst adding manual tests (and later automated tests) to cover the most important flows. We only rewrote features when they needed to change and in some cases removed functionality when particularly hairy features no longer worked. Otherwise I advise against rewrites; if the system was reasonably built and the platform viable then rewriting is just a waste of money.

tonyedgecombe 8y ago

Yes, there is often a lot of domain knowledge embedded in that legacy code. The sort of information that is difficult to tease out of the business or understand by looking at the code.