4 ms·

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

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
- 90s_dev 1y ago
  It depends on the size of the (sub)system, the inherent complexity of any version vs incidental complexity of the initial version, and the time given for a rewrite.

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

90s_dev 1y ago
It depends on the size of the (sub)system, the inherent complexity of any version vs incidental complexity of the initial version, and the time given for a rewrite.