Things You Should Never Do, Part I (2000)
joelonsoftware.com
Things You Should Never Do, Part I (2000)
1–10 of 104 posts
Re: Things You Should Never Do, Part I (2000)
#2An oldie, but a goldie.
Re: Things You Should Never Do, Part I (2000)
#3My guess at the problem: we all feel a sense of relief when the codebase gets smaller, but making an existing, working codebase smaller is really, really hard work. Deleting it and starting over front loads all the reward
Re: Things You Should Never Do, Part I (2000)
#4Related:
Things You Should Never Do, Part I - https://news.ycombinator.com/item?id=31122975 - April 2022 (7 comments)
It’s harder to read code than to write it - https://news.ycombinator.com/item?id=31117277 - April 2022 (2 comments)
Things You Should Never Do (2000) - https://news.ycombinator.com/item?id=23725867 - July 2020 (83 comments)
Things You Should Never Do, Part I (2000) - https://news.ycombinator.com/item?id=6327021 - Sept 2013 (154 comments)
Things You Should Never Do, Part I - https://news.ycombinator.com/item?id=3624830 - Feb 2012 (40 comments)
Things You Should Never Do [2000] - https://news.ycombinator.com/item?id=3449953 - Jan 2012 (2 comments)
Things You Should Never Do, Part I - https://news.ycombinator.com/item?id=608431 - May 2009 (40 comments)
Re: Things You Should Never Do, Part I (2000)
#5I always thought it was easier to read code than to write it.
Re: Things You Should Never Do, Part I (2000)
#6Meh. I rewrilote our backend in about 3 month, and in the end of rewriting another service. All good so far!
Sometimes stuff is broken so badly you better start over
Re: Things You Should Never Do, Part I (2000)
#7I think people tend to want to rewrite software for the psychological break from the old, bad and ugly thing they don't want to have anything to do with anymore.
It is so easy to think "If only I could start everything from scratch, life will be so beautiful and I will be so successful and everybody will be happy. I will fix all the problems of the current codebase and people will forever sing songs about how amazingly I turned everything around."
What more frequnetly (much more frequnetly) happens is usually some mix of:
* developers not really understanding why exactly the previous version failed,
* developers not really understanding what actually worked well in the previous version,
* developers completely underestimating actual amount of accumulated knowledge in the old system that they now have to replicate. Obviously, they only discover it along the way when it is suddenly too late to fix the design to take all of that stuff into account.
* developers not appreciating the fact they are in a much very different (worse) situation than original creators of the previous version. The creators of the previous version had time to build the system and then slowly evolve it. But the current team has typically a short time horizon to replicate ALL of it.
* as the resources are shifted from the maintenance of the old system to the development of the new, suddenly the clock starts ticking and the stakeholders are impatient to see the result. The pressure grows quickly and with it comes inevitable compromises and technical debt.
* at some point development team is told they have to start maintaining the old app. The resources devoted to the rewrite shrink, the work grinds to a halt. I have seen many more systems that have been in a state of perpetual migration than I have seen ones that have been successfully completed rewrite.
Re: Things You Should Never Do, Part I (2000)
#8I keep hearing this nonsense over and over. I've led two full and very successful software 50-100K LOC rewrites, both with the team and stakeholders who had a lot of experience in the problem space. We replaced unmaintainable systems by a much fresher, MUCH faster codebase. They used largely boring and reliable technology. Rewriting 1%, 10% or even 50% would make no sense and essentially get us little or nothing.
Yes, you need to know what you're doing if you plan to rewrite anything, and make sure that the people who know the little legacy details of your system are around, but it's absolutely the right thing to do in many situations.
Re: Things You Should Never Do, Part I (2000)
#9The HN story immediately above this one is "A Social History of Jell-O Salad".
A perfect pairing.
Re: Things You Should Never Do, Part I (2000)
#10I keep hearing this nonsense over and over. I've led two full and very successful software 50-100K LOC rewrites, both with the team and stakeholders who had a lot of experience in the problem space. We replaced unmaintainable systems by a much fresher, MUCH faster codebase. They used largely boring and reliable technology. Rewriting 1%, 10% or even 50% would make no sense and essentially get us little or nothing. Yes…
50-100K LOC are less than the amount of code for the build system in a couple of projects I worked on.