I like to build my first version in one file with as few abstractions as possible. No helper functions, unless absolutely necessary, just straight-forward code. Building good abstractions later on is a lot easier than starting with wrong ones in the first place.
Throw away your first draft of your code
21–30 of 230 posts
Re: Throw away your first draft of your code
#22I’m in the middle of this with my new database startup. The alpha was written to gather requirements, so I intentionally skimped on code quality as it could be a waste of time. Now that I know the domain inside and out, the beta rewrite is worth turning up the quality. And it’s so fast and easy to write, as the old code serves as api documentation for all the low level stuff it depends on.
I recommend you do this too.
Re: Throw away your first draft of your code
#23I've never respected this advice, even though I hear it often enough. The reasoning appears to come down to this:
> If you know that you're possibly keeping the code, you do things in a "proper" way, which means moving slower
combined with the idea that it's faster to redo work than it is to refactor.
I don't buy either of these propositions as a universal rule. For the first, it seems that a mindset of avoiding premature optimization, which you should be cultivating anyway, is enough to ward it off.
For the second, I see it as very context dependent, with my bias going towards refactoring instead of rewriting. I most often get things right enough the first time that it really only needs to be refactored going forward. Only when I end up with serious flaws do I decide to start over, often before I finish my implementation because the flaws are already apparent enough. Add to this that even very large changes can be refactored effectively and timely in my experience, and I feel like the bar for rewriting is really high to be cost-effective.
Unfortunately this essay and many others seem to take objections like mine for granted, and I should just believe the author that rewriting is faster with zero supporting evidence.
Re: Throw away your first draft of your code
#24I don't throw it away, I keep it as a reference. But for anything interesting, I might rewrite from "scratch" three times easily.
Re: Throw away your first draft of your code
#25I can't load the page.
https://web.archive.org/web/20230804183217/https://ntietz.co...
Re: Throw away your first draft of your code
#26I've never respected this advice, even though I hear it often enough. The reasoning appears to come down to this: > If you know that you're possibly keeping the code, you do things in a "proper" way, which means moving slower combined with the idea that it's faster to redo work than it is to refactor. I don't buy either of these propositions as a universal rule. For the first, it seems that a mindset of avoiding prem…
looking for gaping security holes is premature optimization. if you run into security problems down the line, use a security profiler and find the hot spots i.e. radioactive code
Re: Throw away your first draft of your code
#27I've never had luck with this approach. For me, iteratively building and changing the codebase as new requirements come up lends itself to having to think of good ways to modularize and future proof. The idea of throwing out the code and starting over is definitely appealing, but often the iterative approach gives me something I'm super happy with. I think I do use the throwaway approach with simple prototyping of sm…
If you're discovering requirements along with developing code you often end up with Frankenstein's monster because things that were intended to do one thing got retrofitted to do 4 more things. It works but if you had all 4 things in mind when designing the first approach it would have been much cleaner. And going forward it keeps getting worse.
Re: Throw away your first draft of your code
#28Earlier quoted context omitted.
Just never let management see the prototype or they'll consider it done and tell you to move on to something else.
In my experience, this is what actually happens. A developer makes a low-quality, low-effort prototype under the assumption it won’t ship. Someone sees it. It gets shipped. Everyone loses.
Sabotage your prototypes then. Have it reset its state every 5 minutes or deliberately leak memory.
Re: Throw away your first draft of your code
#29I've seen the theory that this is why changing to a new framework/language seems like magic so much of the time. That it's not so much the differences in the technologies as it is your knowledge of the problem.
It's probably a little of both in reality but it's an interesting idea.
Re: Throw away your first draft of your code
#30I have found that this kind of advice does not play well with managers (but it's actually not a bad thing to do).
I'm fairly grateful that I've retired from the rodent rally, and am working at pretty much my own pace and structure.
About six months ago, I tossed out the code for the frontend of a project that I'd been developing for over a year and a half (at that point). I distilled the business logic into an SDK, brought in a designer, and started over from scratch.
The result is ten thousand times better than what we had (and were considering shipping), a few months ago.