3 ms·
In my experience, refactor vs rewrite is the wrong approach. Knowledge of the business must be maintained. If knowledge is on the team because the company is s
by cientifico 6y ago
In my experience, refactor vs rewrite is the wrong approach.
Knowledge of the business must be maintained.
If knowledge is on the team because the company is stable, rewrite. 37 signals is a clear example of this.
If the knowledge is in the code, because multiple people or teams worked on the code base over the past few years, refactor. A rewrite will be the recipe for disaster.
I never found an exception to this rule.
- dagss 6y agoI have been responsible for an exception to this rule. We were new people coming in to take over, decided to go for rewrite, and were successful. But part of the reason for the rewrite was that the logic (translation of business domain knowledge into code) in the old version was wrong resulting in unstable behavior. It could have been fixed in the old version (very many places) but the lack of a test suite too tipped the scales for rewrite (with test suite). You can say that we learned the domain (at least) as well as the authors of original system after coming in, but won't that be the case of any successful rewrite?..
- cientifico 6y agoIf you are able to get the domain knowledge fast enough, sure. Or as you said, the domain knowledge has changed from the original.
- rakoo 6y agoIt seems to me it's still not contradictory to GP: domain knowledge wasn't in the code, it was outside. The thing didn't work in all cases so you had to get the specs from something other than the code; rewriting according to this exterior source was the sensible thing to do
- chosenbreed37 6y agoGreat heuristic!