3 ms·
I'd rather do the Ship of Theseus thing and just harden the prototype as required, and only when faced with real-world evidence. The problem with rewriting is
by GMoromisato 3y ago
I'd rather do the Ship of Theseus thing and just harden the prototype as required, and only when faced with real-world evidence.
The problem with rewriting is that sometimes you face second-system syndrome[1] where you overengineer everything.
Believe me--it happened to me at Groove Networks after Lotus Notes (ask your grandparents about that).
[1] https://en.wikipedia.org/wiki/Second-system_effect https://en.wikipedia.org/wiki/Second-system_effect
- fritzo 3y agoYet I find when rewriting from scratch there's a countering force of simplification where I find myself thinking "We spent way too much complexity on that part, and we can entirely do away with that other part, and we turned out never to use features X and Y."
- GMoromisato 3y agoYeah, that makes sense too. I think it just boils down to "keep writing systems and you'll get better at it." But there's no bait on that kind of link.
- bell-cot 3y ago> "...and we turned out never to use features X and Y." THIS. Often, the best way to start the rewrite is to go straight to the database, and start asking "what allowed values for all these fields have never actually been used?". EDIT: Whether it's rewriting, or refactoring, or adding some "if( Deprecated_Feature_Allow !== true ) ... ErrorDie( Feature_Deprecated )" logic here and there, or updating training material, or whatever - knowing that Software_Feature got ~zero real-world use is d*mned useful.
- GMoromisato 3y agoAgreed--every software engineer I know loves deleting useless code. But this is not incompatible with refactoring instead of rewriting.