5 ms·

The temptation to throw away all of your code - be it a prototype or a "grown" code base - arises often. Often it is a bad idea. I get it, though, there is an

by kleiba 3y ago

The temptation to throw away all of your code - be it a prototype or a "grown" code base - arises often. Often it is a bad idea. I get it, though, there is an inherent attractiveness in the idea of starting fresh from a clean slate. Except, more likely than not, you'll soon find yourself in a similar situation to the one you started from. The fundamental problem is that it is easy to underestimate the edge cases. Sure, the main functionality is easily understood and straight-forward to conceptualize. But did you remember to think through all the smaller aspects of your software, too? Perhaps it's easier with a prototype implementation that in fact doesn't have a lot of features yet, but to completely replicate the functionality of a complex piece of software isn't an easy undertaking. Sure, getting 80% there is probably easy, but the last 20% is the part that's easy to overlook when considering a complete rewrite. Admittedly, there's nothing sexy about refactoring. And often it may seem like it's less work to just simply scrap everything and start over. However, that's fallacy a lot of times.

deleted 3y ago
[deleted]
m463 3y ago
It says to throw it away after a couple of DAYS, which seems to differ from other advice (like from joel-on-software) Maybe this is ok, given that time period? or will the rewrite have all these extra bells and whistles? or will the rewrite throw away the unneeded bells and whistles?
- HenryBemis 3y ago
  Ok, perhaps don't throw it away. When I come up with an idea (for an app usually), I use "a few" A4-sheets (anything between 5 and 20), scribble and draw on them with a pencil, draw screens, buttons, data flows, activities, write notes (in various font sizes). Then I use my CamScanner and call this a v1. Then email me the PDF and store the papers in a box, and a couple of days later I start the v2 (same process), then v3. By v4 it's 'good'. I also use the same method on my 9-5. I take VERY seriously the Abraham Lincoln quote “Give me six hours to chop down a tree and I will spend the first four sharpening the axe” on almost everything. I consider the v1, v2, v3 as the "sharpening the axe" and the v4 on the actual cutting. In that spirit, the article has a similar approach, as the v1, v2, and v3 may take you down an (more than) imperfect path.
Buttons840 3y ago
> The temptation to throw away all of your code - be it a prototype or a "grown" code base - arises often. I want an editor plugin which allows me to mark sections of code as reviewed or "perfect" (depending on how honest I'm being). Then, when I'm tempted to rewrite everything, I can go through and mark what I think is good, and then focus on refactoring the rest until I think it is good as well. I'm tempted to rewrite code because I lose track of what it's doing, or I've learned a lot since I wrote that old code and so I'm not sure if the old code is good anymore. It's not so much about rewriting the code as an exercise in getting familiar with the code I've already written. I want a tool to help me with this.
- gregmac 3y ago
  I would think a combination of git, unit tests, and comments would solve this problem? Unit tests prove the code works as intended, and are basically examples of what the code is doing. Whether the code is actually "good" is a bit more subjective -- but tests give you the freedom to modify it without breaking it. Checking into git frequently is also a way to give yourself some freedom. Commit at every milestone, like every time the next thing is "working". If you feel like refactoring, go for it -- you can reset back to working state in a few seconds. And lastly, leave comments in. You can always clean it up before you push. You can even squash or interactively rebase your history so no one else sees the gory details how the hot dog was actually made.
  - jon-wood 3y ago
    The theory and the practice of unit tests are often different things. In theory you’ll make changes to the code, and the unit tests will show whether they had the intended effects. In practice, because often the unit tests are mocking out all the classes they interact with (as is the recommended style for isolated tests) you’ll either have all the tests explode constantly because the interface being mocked has changed, or you’ll have tests that confidently tell you things are working despite the methods they call no longer existing.
- quickthrower2 3y ago
  If you could modularize code in such a way the sizable chunks could “just sit still!” then entire modules could be marked as perfect. But you wouldn’t have to since you wouldn’t naturally need to touch them (e.g. how many codebases are using a fork of core-utils, for example, … to exaggerate a conways law effect). But unfortunately the modules don’t make themselves apparent at the start of the project. So it needs refactoring discipline.
nemetroid 3y ago
Throwing away an established code base is a completely different thing from throwing away a few-days-old prototype, and not what the article is suggesting. The points you mention don't apply to the prototype case.
- tuwtuwtuwtuw 3y ago
  Yeah, this thread is a somewhat strange read. People don't seem to understand what "draft" or "prototype" means. Odd.
  - redblacktree 3y ago
    Just like management. I can't tell you how many times I've written a "Proof of Concept" that became production code.
    - doublerabbit 3y ago
      I did that today. Rewrote a bash script in to a perl script as Proof of Concept. it's now in UAT... but I like perl, hey ho.
    - Vicinity9635 3y ago
      [dead]
    - gillesjacobs 3y ago
      This has caused me so much grief. I find it key to communicate to all stakeholders the production process from PoC to MVP to MVP+. Still managers always push against redoing work they can see working for the happy flow.
    - Tokumei-no-hito 3y ago
      I feel this. What I do now is increase the points of the PoC (real estimated PoC time + optimization). I get the PoC down asap then as soon as it’s proven (privately to myself) I move onto optimizing. If it fails then I communicate early to discuss a change of scope. Assuming it succeeds, by the time I present it I have already done significant work making it production ready. So to request an extra 10-25% time to “smooth out the edges” goes over easy after the demo. In reality I end up with 50-75% time to get it prod ready. The rest is QA + prod bug fixes to take it over the (practically scoped) finish line.
hot_gril 3y ago
I've thrown away and redone a lot of code, both mine and others', and I've never regretted the time spent vs continuing to use the old thing.
withinboredom 3y ago
> Admittedly, there's nothing sexy about refactoring. There's the "strangler fig" (my favorite) method of refactoring. It's where you rewrite just a small portion of the software, little bits at a time. Instead of doing a full rewrite. IMHO, it's the best way to refactor. You can switch out both "old" and "new" versions at-will until you're 100% sure you've covered all the edge cases.
eternityforest 3y ago
I don't really feel that attraction to complete rewriting. I wonder if the people who do are very smart, and thus able to hold more state in their head, so ugly code bothers them more even if it's not actively a problem, because they are able to have background tasks in their mind to worry about it? And at the same time, perhaps their code is less encapsulated, because they didn't optimize for abstraction, they optimized for beauty. A leaky abstraction doesn't bother them, because ALL abstractions are leaky to them, they probably have a sense of internal workings even whem using household appliances, but ugly code tucked away somewhere bothers them a lot, and they might dislike using popular large libraries even if they work great, just because they're not comfortable using what they don't understand deeply. My evidence of this is the fact that suckless exists and people actually use it, I assume their experience of thought is very different from anything I have experienced.
- jwells89 3y ago
  Speaking personally my urge to rewrite at least partially comes from not truly understanding the problem and the solutions to it until I've written something reasonably functional. It doesn't matter how much time I put into sitting and theorizing, there's always things I didn't anticipate and assumptions that turned out to be incorrect. This usually means that rewrites are significant improvements across the board, especially if they're done a relatively short time after the original is finished since it's all still fresh in my head. This may be a weakness of sorts on my part though, I lack formal engineering training which might be why purely mental modeling (no code) doesn't work all that well for me.
  - extr 3y ago
    Yeah, I find that the desire to rewrite often comes from the final (working) solution having poor code ergonomics. It's not necessarily that it's wrong, it's that it's awkward or clumsy to understand/use, because my mental model of how it worked didn't take into account the actual practical day to day usage of the code.
    - eternityforest 3y ago
josephg 3y ago
> Admittedly, there's nothing sexy about refactoring. And often it may seem like it's less work to just simply scrap everything and start over. However, that's fallacy a lot of times. Agreed. Though sometimes you need to refactor the core of an application, in a way which will touch the entire app. To do that I often make a new, empty project. Then I rewrite the core of my project into the new folder (in whatever new structure I’m trying out). When that works, I slowly copy the content from the old project into the new project - refactoring and testing along the way. But it’s not perfect. About half the time I do this, I discover halfway through that I didn’t understand some aspect of the system. My new design is wrong or useless and I throw away all the new code. Or I figure out that I can just make the changes in place in the old project folder after all, and I bail on the new code and go back to a traditional refactor. But no matter what happens, I don’t think I’ve ever regretted a refactoring attempt like this. I always come away feeling like I’ve learned something. How much you’ve learned from a project is measured by the number of lines of code you threw away in the process.
- majikandy 3y ago
  I find refactoring sexy. Just saying.
robaato 3y ago
Rather than "throw away" I would "start from scratch" meaning I can refer to prototype but reimplement with respect to appropriate norms. As a version control fanatic, very little gets really thrown away in my book. Just hidden.
- tnecniv 3y ago
  Yeah normally when I do this, it’s because I picked bad abstractions. The main business logic I can bring over almost line by line, but I want to reshape the abstractions / data structures / interface to that logic
trentnix 3y ago
Ah yes, starting from a clean slate. https://devrant.com/rants/816880/i-ve-done-it-again https://devrant.com/rants/816880/i-ve-done-it-again
barbariangrunge 3y ago
Game companies implicitly do this, throwing out old versions of their code (sort of). You make a game. Ship it. Start on a new game. Your previous game is now sort of a practice run for making a new game from scratch. Continue, ad infinitum. It's weird: you rarely have to maintain something for 20+ years, and you get to always improve and iterate on how you did things last time. But, are you training yourself to write hard to maintain code, since you don't really have to maintain it past a certain period? Or does the learning-from-iteration actually make writing-maintainable-code easier? I know some people do keep developing their games for decades, look at Dwarf Fortress, I'm just talking in general.
- throwaway14356 3y ago
  what you do you get good at. if you don't have to maintain there is no point in getting good at it or any reason to think you will gradually get better at it.
- glouwbug 3y ago
  Minecraft is reaching that 15+ year mark
  - hathchip 3y ago
    That's the most successful game of all time, hardly a typical case.
wpietri 3y ago
Nah. I think a prototype is something you definitionally should throw away. There's a huge freedom to knowing that instead of taking on tech debt, you're committed to declaring tech bankruptcy and throwing away the code. It lets you try things, cut corners, and generally experiment. It's great for thinking through what everybody really wants. I do agree that it's generally a bad idea to just throw out a long-lived code base. But for me that's not an estimation issue. It's because the urge to throw it out is usually a response to upstream problems that haven't gotten fixed. For example, a lot of code bases are a mess due to time pressure. But if you don't fix the process problems that turn time pressure into mess, then you're just doing to end up with another mess. Possibly a bigger one, in that stopping all productive output in favor of a rewrite usually makes business stakeholders crazy, causing increased time pressure.
duxup 3y ago
Required link to Joel on Software: https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-... Granted Joel is taking about a wholesale rewrite of proven / established code. Code and has had had the advantage of time. Personally, I end up rewriting parts of my code often. It usually takes a mile for me to find exactly the right way it should be based on how are people use it. You absolutely should rewrite prototypes, and re-factor important chunks of code. I rewrote something 3 times today, it was better each time. At the same time you should be wary…
- ideamotor 3y ago
  Of the reasons he says engineers want to rewrite the code, he says: badly organized code, slow processing time, and ugly code. Maybe I’m not an engineer, because I bet perfectly pretty fast code is an indicator you should reorganize it to make it easier to adapt, add more capabilities even if it runs slow, and put some ugly fixes in there so it’s useful for the end user. Agreed that wanting to over-engineer and perfect something that should be constantly evolving is not a good reason to rewrite it. That sounds like back office bubble pretend-work.
tuwtuwtuwtuw 3y ago
RTFA
Tozen 3y ago
A possible alternative is to use a different programming language for doing the prototyping than the one which will be used in production. The urge to hang on to prototype code can be removed, because you are going to do a rewrite in a different language, regardless. By using 2 different languages, there is more freedom to just make a demo, discuss, and then decide what to keep or what direction to go.

by kleiba 3y ago

deleted 3y ago

[deleted]

m463 3y ago

It says to throw it away after a couple of DAYS, which seems to differ from other advice (like from joel-on-software) Maybe this is ok, given that time period? or will the rewrite have all these extra bells and whistles? or will the rewrite throw away the unneeded bells and whistles?

HenryBemis 3y ago
Ok, perhaps don't throw it away. When I come up with an idea (for an app usually), I use "a few" A4-sheets (anything between 5 and 20), scribble and draw on them with a pencil, draw screens, buttons, data flows, activities, write notes (in various font sizes). Then I use my CamScanner and call this a v1. Then email me the PDF and store the papers in a box, and a couple of days later I start the v2 (same process), then v3. By v4 it's 'good'. I also use the same method on my 9-5. I take VERY seriously the Abraham Lincoln quote “Give me six hours to chop down a tree and I will spend the first four sharpening the axe” on almost everything. I consider the v1, v2, v3 as the "sharpening the axe" and the v4 on the actual cutting. In that spirit, the article has a similar approach, as the v1, v2, and v3 may take you down an (more than) imperfect path.

Buttons840 3y ago

> The temptation to throw away all of your code - be it a prototype or a "grown" code base - arises often. I want an editor plugin which allows me to mark sections of code as reviewed or "perfect" (depending on how honest I'm being). Then, when I'm tempted to rewrite everything, I can go through and mark what I think is good, and then focus on refactoring the rest until I think it is good as well. I'm tempted to rewrite code because I lose track of what it's doing, or I've learned a lot since I wrote that old code and so I'm not sure if the old code is good anymore. It's not so much about rewriting the code as an exercise in getting familiar with the code I've already written. I want a tool to help me with this.

gregmac 3y ago
I would think a combination of git, unit tests, and comments would solve this problem? Unit tests prove the code works as intended, and are basically examples of what the code is doing. Whether the code is actually "good" is a bit more subjective -- but tests give you the freedom to modify it without breaking it. Checking into git frequently is also a way to give yourself some freedom. Commit at every milestone, like every time the next thing is "working". If you feel like refactoring, go for it -- you can reset back to working state in a few seconds. And lastly, leave comments in. You can always clean it up before you push. You can even squash or interactively rebase your history so no one else sees the gory details how the hot dog was actually made.
- jon-wood 3y ago
  The theory and the practice of unit tests are often different things. In theory you’ll make changes to the code, and the unit tests will show whether they had the intended effects. In practice, because often the unit tests are mocking out all the classes they interact with (as is the recommended style for isolated tests) you’ll either have all the tests explode constantly because the interface being mocked has changed, or you’ll have tests that confidently tell you things are working despite the methods they call no longer existing.
quickthrower2 3y ago
If you could modularize code in such a way the sizable chunks could “just sit still!” then entire modules could be marked as perfect. But you wouldn’t have to since you wouldn’t naturally need to touch them (e.g. how many codebases are using a fork of core-utils, for example, … to exaggerate a conways law effect). But unfortunately the modules don’t make themselves apparent at the start of the project. So it needs refactoring discipline.

nemetroid 3y ago

Throwing away an established code base is a completely different thing from throwing away a few-days-old prototype, and not what the article is suggesting. The points you mention don't apply to the prototype case.

tuwtuwtuwtuw 3y ago
Yeah, this thread is a somewhat strange read. People don't seem to understand what "draft" or "prototype" means. Odd.
- redblacktree 3y ago
  Just like management. I can't tell you how many times I've written a "Proof of Concept" that became production code.
  - doublerabbit 3y ago
    I did that today. Rewrote a bash script in to a perl script as Proof of Concept. it's now in UAT... but I like perl, hey ho.
  - Vicinity9635 3y ago
    [dead]
  - gillesjacobs 3y ago
    This has caused me so much grief. I find it key to communicate to all stakeholders the production process from PoC to MVP to MVP+. Still managers always push against redoing work they can see working for the happy flow.
  - Tokumei-no-hito 3y ago
    I feel this. What I do now is increase the points of the PoC (real estimated PoC time + optimization). I get the PoC down asap then as soon as it’s proven (privately to myself) I move onto optimizing. If it fails then I communicate early to discuss a change of scope. Assuming it succeeds, by the time I present it I have already done significant work making it production ready. So to request an extra 10-25% time to “smooth out the edges” goes over easy after the demo. In reality I end up with 50-75% time to get it prod ready. The rest is QA + prod bug fixes to take it over the (practically scoped) finish line.

hot_gril 3y ago

I've thrown away and redone a lot of code, both mine and others', and I've never regretted the time spent vs continuing to use the old thing.

withinboredom 3y ago

> Admittedly, there's nothing sexy about refactoring. There's the "strangler fig" (my favorite) method of refactoring. It's where you rewrite just a small portion of the software, little bits at a time. Instead of doing a full rewrite. IMHO, it's the best way to refactor. You can switch out both "old" and "new" versions at-will until you're 100% sure you've covered all the edge cases.

eternityforest 3y ago

I don't really feel that attraction to complete rewriting. I wonder if the people who do are very smart, and thus able to hold more state in their head, so ugly code bothers them more even if it's not actively a problem, because they are able to have background tasks in their mind to worry about it? And at the same time, perhaps their code is less encapsulated, because they didn't optimize for abstraction, they optimized for beauty. A leaky abstraction doesn't bother them, because ALL abstractions are leaky to them, they probably have a sense of internal workings even whem using household appliances, but ugly code tucked away somewhere bothers them a lot, and they might dislike using popular large libraries even if they work great, just because they're not comfortable using what they don't understand deeply. My evidence of this is the fact that suckless exists and people actually use it, I assume their experience of thought is very different from anything I have experienced.

jwells89 3y ago
Speaking personally my urge to rewrite at least partially comes from not truly understanding the problem and the solutions to it until I've written something reasonably functional. It doesn't matter how much time I put into sitting and theorizing, there's always things I didn't anticipate and assumptions that turned out to be incorrect. This usually means that rewrites are significant improvements across the board, especially if they're done a relatively short time after the original is finished since it's all still fresh in my head. This may be a weakness of sorts on my part though, I lack formal engineering training which might be why purely mental modeling (no code) doesn't work all that well for me.
- extr 3y ago
  Yeah, I find that the desire to rewrite often comes from the final (working) solution having poor code ergonomics. It's not necessarily that it's wrong, it's that it's awkward or clumsy to understand/use, because my mental model of how it worked didn't take into account the actual practical day to day usage of the code.
  - eternityforest 3y ago

josephg 3y ago

> Admittedly, there's nothing sexy about refactoring. And often it may seem like it's less work to just simply scrap everything and start over. However, that's fallacy a lot of times. Agreed. Though sometimes you need to refactor the core of an application, in a way which will touch the entire app. To do that I often make a new, empty project. Then I rewrite the core of my project into the new folder (in whatever new structure I’m trying out). When that works, I slowly copy the content from the old project into the new project - refactoring and testing along the way. But it’s not perfect. About half the time I do this, I discover halfway through that I didn’t understand some aspect of the system. My new design is wrong or useless and I throw away all the new code. Or I figure out that I can just make the changes in place in the old project folder after all, and I bail on the new code and go back to a traditional refactor. But no matter what happens, I don’t think I’ve ever regretted a refactoring attempt like this. I always come away feeling like I’ve learned something. How much you’ve learned from a project is measured by the number of lines of code you threw away in the process.

majikandy 3y ago
I find refactoring sexy. Just saying.

robaato 3y ago

Rather than "throw away" I would "start from scratch" meaning I can refer to prototype but reimplement with respect to appropriate norms. As a version control fanatic, very little gets really thrown away in my book. Just hidden.

tnecniv 3y ago
Yeah normally when I do this, it’s because I picked bad abstractions. The main business logic I can bring over almost line by line, but I want to reshape the abstractions / data structures / interface to that logic

trentnix 3y ago

Ah yes, starting from a clean slate. https://devrant.com/rants/816880/i-ve-done-it-again https://devrant.com/rants/816880/i-ve-done-it-again

barbariangrunge 3y ago

Game companies implicitly do this, throwing out old versions of their code (sort of). You make a game. Ship it. Start on a new game. Your previous game is now sort of a practice run for making a new game from scratch. Continue, ad infinitum. It's weird: you rarely have to maintain something for 20+ years, and you get to always improve and iterate on how you did things last time. But, are you training yourself to write hard to maintain code, since you don't really have to maintain it past a certain period? Or does the learning-from-iteration actually make writing-maintainable-code easier? I know some people do keep developing their games for decades, look at Dwarf Fortress, I'm just talking in general.

throwaway14356 3y ago
what you do you get good at. if you don't have to maintain there is no point in getting good at it or any reason to think you will gradually get better at it.
glouwbug 3y ago
Minecraft is reaching that 15+ year mark
- hathchip 3y ago
  That's the most successful game of all time, hardly a typical case.

wpietri 3y ago

Nah. I think a prototype is something you definitionally should throw away. There's a huge freedom to knowing that instead of taking on tech debt, you're committed to declaring tech bankruptcy and throwing away the code. It lets you try things, cut corners, and generally experiment. It's great for thinking through what everybody really wants. I do agree that it's generally a bad idea to just throw out a long-lived code base. But for me that's not an estimation issue. It's because the urge to throw it out is usually a response to upstream problems that haven't gotten fixed. For example, a lot of code bases are a mess due to time pressure. But if you don't fix the process problems that turn time pressure into mess, then you're just doing to end up with another mess. Possibly a bigger one, in that stopping all productive output in favor of a rewrite usually makes business stakeholders crazy, causing increased time pressure.

duxup 3y ago

Required link to Joel on Software: https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-... Granted Joel is taking about a wholesale rewrite of proven / established code. Code and has had had the advantage of time. Personally, I end up rewriting parts of my code often. It usually takes a mile for me to find exactly the right way it should be based on how are people use it. You absolutely should rewrite prototypes, and re-factor important chunks of code. I rewrote something 3 times today, it was better each time. At the same time you should be wary…

ideamotor 3y ago
Of the reasons he says engineers want to rewrite the code, he says: badly organized code, slow processing time, and ugly code. Maybe I’m not an engineer, because I bet perfectly pretty fast code is an indicator you should reorganize it to make it easier to adapt, add more capabilities even if it runs slow, and put some ugly fixes in there so it’s useful for the end user. Agreed that wanting to over-engineer and perfect something that should be constantly evolving is not a good reason to rewrite it. That sounds like back office bubble pretend-work.

tuwtuwtuwtuw 3y ago

RTFA

Tozen 3y ago

A possible alternative is to use a different programming language for doing the prototyping than the one which will be used in production. The urge to hang on to prototype code can be removed, because you are going to do a rewrite in a different language, regardless. By using 2 different languages, there is more freedom to just make a demo, discuss, and then decide what to keep or what direction to go.