6 ms·
#1 Keep track of the most important updates #2 Don’t rewrite what you don’t have to #3 Maintain good documentation, gather the necessary knowledge
by mgl 4y ago
#1 Keep track of the most important updates
#2 Don’t rewrite what you don’t have to
#3 Maintain good documentation, gather the necessary knowledge
- ramraj07 4y ago#2 is not universal. There’s a lot of legacy software with outrageous workarounds and sometimes it’s simpler to rewrite part of the system than to even maintain it for a month. It’s all about good judgement.
- grvdrm 4y agoFun question to think about what you have to rewrite vs not. This reminded me of my last firm where we had a C# system with tons of Task Parallel Library code, nearly all of it written poorly or not written for the correct use-cases. My colleague and I weren’t part of the development team responsible for putting it together but it was clear it has been haphazardly built that way over time. We were quite convinced the team needed to rewrite but then things like cost, time, priorities stepped in. We needed other areas addressed. So, the code stayer because it worked, enough, unfortunately.
- SoftTalker 4y agoThat’s often the first impression but in my career I’ve never seen a rewrite work substantially better or save any money. Sometimes they are necessary for other reasons but those two are the arguments usually made and they don’t really hold up.
- switchbak 4y agoI've got experiences in both camps. Well managed rewrites (typically portions of a system) can fix a lot of problems in one fell swoop, but you have to really know what you're doing and actually have concrete plans for improvements. If not, all you've done is just replaced a bad system with another bad system. I've also seen that lately. You're right that often it's just "different" and not better, and that makes it hard to sell the case when a rewrite is truly needed.
- jamesfinlayson 4y agoAgreed - I've worked with one rewrite from scratch and it convinced me that rewriting from scratch is never a good idea. Incidentally, I can see why the company decided on a rewrite from scratch (no separation of MVC logic, no framework, almost no tests, only ran on special environments, production had an extra set of patches that for some reason would never get merged back to master) - honestly, it really was too far gone.
- indymike 4y ago> it’s simpler to rewrite part of the system than to even maintain it for a month. This is often a career limiting decision. Rewrites are often much more difficult, particularly when you are dealing with a system that is not fully understood. This often leads to what should be a quick re-write taking > 3x more time and money than projected. In the end no one will remember why the technical reason for the rewrite, but they will remember who made the decision. I've made this mistake a few times in my career, and I always thought, this project, it is the exception to the no-rewrites rule.
- layer8 4y agoThe trick is to make someone else make the decision.
- anonuser123456 4y agoUntil you find out there is some essential complexity you missed that’s encoded in the convoluted logic… and then your rewrite doesn’t function and you look foolish.
- layer8 4y agoDepending on the case, it at least has the benefit that the essential complexity is now known and can be documented.
- goto11 4y agoYes but before you can make that call you need to have a reliable estimate of how costly it will be to rewrite the system. This in turn requires a through understanding of the current behavior of the system, which means you will have to study and understand the code anyway.
- Dalewyn 4y agoRule 0 in Engineering: If it ain't broke, don't fix it.