5 ms·

> Cooper decided to promptly throw away the 25,000 lines of messy prototype C code that comprised Tripod and start over from scratch, feeling like it was so irr

> Cooper decided to promptly throw away the 25,000 lines of messy prototype C code that comprised Tripod and start over from scratch, feeling like it was so irredeemably full of time-pressured hacks, it'd simply be easier to rewrite it with a cleaner design. Usually this is either a sign of a terrible programmer or a very competent and experienced one, and it's hard to know which without seeing their other work. But I've done this before, and to good effect. Writing code is not hard. Figuring things out is hard. But once the things are figured out and well understood, rewriting them in a cleaner design is especially easy. Granted, it still takes time, that sometimes that time can be on a scale of months. But the more experienced you are, the more you can estimate that time more accurately.

0xbadcafebee 1y ago
It's always a bad idea. Eight decades of software has shown it to be true, multiple books written on it. The inherent problem with it is the idea that writing a replacement is somehow going to be easy or fast. But if it were easy or fast, somebody would have done it already! Then come the additional problems of a rewrite like second system effect, inherent complexity, human error. It's impossible to predict how long it could take to finish making it, so fast-or-easy goes out the window. Even though it's a bad idea, in very rare cases it can be the least-bad idea. But like you said, that takes an expert to figure out, and there's not a lot of experts floating around.
- 90s_dev 1y ago
  Several times in the past few months, while working on my project, I spent a week writing something exploratory within it, and after all the lessons were fully learned and absorbed, erased that whole part and rewrote it in just a day. I could have kept the week long buggy and badly designed version of it and saved a day of work, but it would have drastically slowed down both development and maintenance of the overall project.
  - jimnotgym 1y ago
    Isn't that one of the tenets of Extreme Programming, write a sketch, throw it away, write it properly?
    - 90s_dev 1y ago
      I don't know, I'm not a real programmer, I still don't understand what SOLID is. I just write code and try to fix it when it doesn't work.
  - manicminer 1y ago
    The Mikado Method
  - 0xbadcafebee 1y ago
    That is very different from having an existing complex system and attempting a complete rewrite from scratch. If you have a car, and you disassemble the car and reassemble the car 10 times in a row, each time trying it out, then when you finally disassemble-and-reassemble an 11th time, without the defects you've seen the last 10 times, that will be pretty easy and fast. If you disassemble and reassemble a car 10 times, but only once a month, it's not going to be as easy. If you disassemble and reassemble it only once a year, it'll be even harder. If you have never disassembled and reassembled it, and you want to not only disassemble it, but redesign all its parts, and then reassemble it, in one go, that will be incredibly time-consuming and error-prone. That is the prototypical "entire software rewrite" which is just a bad idea, full-stop. It's not that it's impossible to work; you can eventually get the car to work again. It's just way more expensive, time-consuming, and error-prone, than people realize when they start it. The whole argument for it is that it'll somehow be quicker and cheaper, and that has never been the case. It is attractive because it feels less complex than a process of incremental improvement of an existing legacy system. But the reality is that it's often more complex, due to all the problems involved in a first-time tear-down, re-design, and re-build. I am not the only person who has noticed this... - https://en.wikipedia.org/wiki/The_Mythical_Man-Month - https://www.onstartups.com/tabid/3339/bid/2596/Why-You-Should-Almost-Never-Rewrite-Your-Software.aspx - https://testdouble.com/insights/managing-legacy-code-rewrite-vs-renovate - https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ - https://www.reddit.com/r/ExperiencedDevs/comments/sr8zyf/why_exactly_does_most_software_rewrite_fail/ - https://daedtech.com/the-myth-of-the-software-rewrite/ - https://levelup.gitconnected.com/why-rewriting-applications-from-scratch-is-almost-always-a-bad-idea-5402d1715006
- mpweiher 1y ago
  > It's always a bad idea. A significant chunk of my software career has been complete rewrites of existing systems. Every one was a huge success. You should always beware of claims of universality ;-)
  - Bjartr 1y ago
    What would you say is most important for a rewrite to be successful?
- GrumpyGoblin 1y ago
  A lot of disagreement apparently but I agree with you. Been doing this a long time and never seen it be a good idea. I completed one successfully and it paralyzed a team of five for a year. Thankfully it was an internal product being rewritten for sale so the affect on users was minimal, but we also lost a year of potential sales. Every other attempt I've seen has started with beautiful ideas, rainbows and pots of gold at the end, but went south after the first 20% code written and things got hard. It's possible to do if you're willing to cripple development efforts or progress for an extended period and understand the result will have it's own issues and a rewrite isn't a silver bullet.

0xbadcafebee 1y ago

It's always a bad idea. Eight decades of software has shown it to be true, multiple books written on it. The inherent problem with it is the idea that writing a replacement is somehow going to be easy or fast. But if it were easy or fast, somebody would have done it already! Then come the additional problems of a rewrite like second system effect, inherent complexity, human error. It's impossible to predict how long it could take to finish making it, so fast-or-easy goes out the window. Even though it's a bad idea, in very rare cases it can be the least-bad idea. But like you said, that takes an expert to figure out, and there's not a lot of experts floating around.

90s_dev 1y ago
Several times in the past few months, while working on my project, I spent a week writing something exploratory within it, and after all the lessons were fully learned and absorbed, erased that whole part and rewrote it in just a day. I could have kept the week long buggy and badly designed version of it and saved a day of work, but it would have drastically slowed down both development and maintenance of the overall project.
- jimnotgym 1y ago
  Isn't that one of the tenets of Extreme Programming, write a sketch, throw it away, write it properly?
  - 90s_dev 1y ago
    I don't know, I'm not a real programmer, I still don't understand what SOLID is. I just write code and try to fix it when it doesn't work.
- manicminer 1y ago
  The Mikado Method
- 0xbadcafebee 1y ago
  That is very different from having an existing complex system and attempting a complete rewrite from scratch. If you have a car, and you disassemble the car and reassemble the car 10 times in a row, each time trying it out, then when you finally disassemble-and-reassemble an 11th time, without the defects you've seen the last 10 times, that will be pretty easy and fast. If you disassemble and reassemble a car 10 times, but only once a month, it's not going to be as easy. If you disassemble and reassemble it only once a year, it'll be even harder. If you have never disassembled and reassembled it, and you want to not only disassemble it, but redesign all its parts, and then reassemble it, in one go, that will be incredibly time-consuming and error-prone. That is the prototypical "entire software rewrite" which is just a bad idea, full-stop. It's not that it's impossible to work; you can eventually get the car to work again. It's just way more expensive, time-consuming, and error-prone, than people realize when they start it. The whole argument for it is that it'll somehow be quicker and cheaper, and that has never been the case. It is attractive because it feels less complex than a process of incremental improvement of an existing legacy system. But the reality is that it's often more complex, due to all the problems involved in a first-time tear-down, re-design, and re-build. I am not the only person who has noticed this... - https://en.wikipedia.org/wiki/The_Mythical_Man-Month - https://www.onstartups.com/tabid/3339/bid/2596/Why-You-Should-Almost-Never-Rewrite-Your-Software.aspx - https://testdouble.com/insights/managing-legacy-code-rewrite-vs-renovate - https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ - https://www.reddit.com/r/ExperiencedDevs/comments/sr8zyf/why_exactly_does_most_software_rewrite_fail/ - https://daedtech.com/the-myth-of-the-software-rewrite/ - https://levelup.gitconnected.com/why-rewriting-applications-from-scratch-is-almost-always-a-bad-idea-5402d1715006
mpweiher 1y ago
> It's always a bad idea. A significant chunk of my software career has been complete rewrites of existing systems. Every one was a huge success. You should always beware of claims of universality ;-)
- Bjartr 1y ago
  What would you say is most important for a rewrite to be successful?
GrumpyGoblin 1y ago
A lot of disagreement apparently but I agree with you. Been doing this a long time and never seen it be a good idea. I completed one successfully and it paralyzed a team of five for a year. Thankfully it was an internal product being rewritten for sale so the affect on users was minimal, but we also lost a year of potential sales. Every other attempt I've seen has started with beautiful ideas, rainbows and pots of gold at the end, but went south after the first 20% code written and things got hard. It's possible to do if you're willing to cripple development efforts or progress for an extended period and understand the result will have it's own issues and a rewrite isn't a silver bullet.