I first read this as a 22-year-old software engineer. Re-reading it as a 46-year-old CTO, it still tracks and still is truer than not. Most re-writes happen because the engineers want to, not because they really need to.
Things You Should Never Do, Part I (2000)
11–20 of 104 posts
Re: Things You Should Never Do, Part I (2000)
#12I always thought it was easier to read code than to write it.
Other way around in my estimation.
Re: Things You Should Never Do, Part I (2000)
#13I 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.
Then you've got bigger problems
Re: Things You Should Never Do, Part I (2000)
#14Code may not rust, but it may be broken out of the gate. Joel and others may not have seen really bad code, but it exists. All of us have written code in our careers that we're not proud of. And there's code written by people who are proud of everything they've written or code written by people who just don't care. These two are usually good candidates for rewrites.
Re: Things You Should Never Do, Part I (2000)
#15I often share this article to new team members as a part of the onboarding journey.
Re: Things You Should Never Do, Part I (2000)
#16I 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 amazing…
> * 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.
On the other hand, developers writing the new system have the major benefit that the requirements are known. Second system effect is real, but if you can avoid it, and focus on addressing the real requirements (as determined by the lived experience of the first system), you can get something good. Sometimes, something really good, if the old system was built on the wrong abstractions, and the new system has better fitting abstractions.
Of course, if you don't actually know what the current system is doing, you're not really in a better place to design the second system.
Re: Things You Should Never Do, Part I (2000)
#17Code may not rust, but it may be broken out of the gate. Joel and others may not have seen really bad code, but it exists. All of us have written code in our careers that we're not proud of. And there's code written by people who are proud of everything they've written or code written by people who just don't care. These two are usually good candidates for rewrites.
You are right. But IMO you're still missing his main point. His thesis is in that case, to rewrite ONLY THE REALLY BAD CODE.
There is not team that is 100% bad so you don't need a full rewrite of 100% of the code base.
Re: Things You Should Never Do, Part I (2000)
#18I 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 amazing…
> * 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. On the other hand, developers writing the new system have the major benefit that the requirements are know…
that only really works for static or mostly stable requirements. not so great for something like the fast evolving web platform of the late 90s when we re-wrote the Netscape/Mozilla rendering engine.
Re: Things You Should Never Do, Part I (2000)
#19I 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…
that's a tiny project. call back when you've got millions of lines
Re: Things You Should Never Do, Part I (2000)
#20Meh. 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
Sure do that for a few lines or even tens of thousands of lines. Don't do that for millions of lines without real serious consideration, and I'd add, a good reading of Joel's post.