3 ms·

I 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 l

I 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.

cyberax 3y ago
50-100K LOC are less than the amount of code for the build system in a couple of projects I worked on.
- prmph 3y ago
  Then you've got bigger problems
  - pixl97 3y ago
    It turns out a lot of people have a lot of problems bigger than yours.
  - selcuka 3y ago
    You would think that it would have been standardised by 2024, but building stuff is still a surprisingly hard problem.
  - cyberax 3y ago
    Oh, for sure. Giant C++ projects have lots and lots of issues. Yet, they do useful work and just abandoning them in-place and rewriting them from scratch is rarely a good solution for these problems.
asadotzler 3y ago
that's a tiny project. call back when you've got millions of lines
- Chris_Newton 3y ago
  The thing is, there are a lot of small systems maintained by a lot of small teams. Unfortunately, when Joel wrote “They did it by making the single worst strategic mistake that any software company can make: They decided to rewrite the code from scratch.” some people took the “any software company” to heart and now apply the same principle even in those smaller contexts when sometimes the code really is that bad and rewriting the whole thing really is by far the best plan. I’ve seen very senior people citing the Netscape case study to support a no-rewrite position while discussing a 10kLOC system that could be rewritten from scratch in a couple of weeks by a single developer.

cyberax 3y ago

50-100K LOC are less than the amount of code for the build system in a couple of projects I worked on.

prmph 3y ago
Then you've got bigger problems
- pixl97 3y ago
  It turns out a lot of people have a lot of problems bigger than yours.
- selcuka 3y ago
  You would think that it would have been standardised by 2024, but building stuff is still a surprisingly hard problem.
- cyberax 3y ago
  Oh, for sure. Giant C++ projects have lots and lots of issues. Yet, they do useful work and just abandoning them in-place and rewriting them from scratch is rarely a good solution for these problems.

asadotzler 3y ago

that's a tiny project. call back when you've got millions of lines

Chris_Newton 3y ago
The thing is, there are a lot of small systems maintained by a lot of small teams. Unfortunately, when Joel wrote “They did it by making the single worst strategic mistake that any software company can make: They decided to rewrite the code from scratch.” some people took the “any software company” to heart and now apply the same principle even in those smaller contexts when sometimes the code really is that bad and rewriting the whole thing really is by far the best plan. I’ve seen very senior people citing the Netscape case study to support a no-rewrite position while discussing a 10kLOC system that could be rewritten from scratch in a couple of weeks by a single developer.