This advice depends a lot on how your "first draft" was coded to begin with. The concept of "first draft" shouldn't exist as code. You design it properly, then you implement it properly.
Now, if for some reason, and there are plenty of good ones, you cannot do the former, then sure, you pay that price by redoing some work. But, at that point, you do the same thing you should have done: you design it properly, then you implement your design.
One could argue that implementing a first draft is a way of designing it. Which, I cannot imagine making sense unless you don't know what it is you want to end up with. Maybe if you're making computer games or other creative endeavors?
> You design it properly, then you implement it properly.
I’m extremely defensive and try to think through everything. Aside from analysis paralysis which is a real obstacle, it’s still not enough. Or rather, it’s not the best way to use a human brain. At some point for a complex project, no matter how smart and experienced you are, assumptions break down. The mental model changes based on “friction” with the gritty world. Prototyping is one way to confront wrong assumptions earlier rather than later.
All creative and intellectual endeavors have analogous process. Writers don’t structure a book and write it perfectly in a methodical fashion. Basically, turning chaos into order can – almost per definition – not be proceduralized.
> One could argue that implementing a first draft is a way of designing it. Which, I cannot imagine making sense unless you don't know what it is you want to end up with. Maybe if you're making computer games or other creative endeavors?
It's when the problem itself has some ambiguity. Like, I design systems that other people and systems use within a large company. I try to figure out how they'll use them, but even they can't tell me exactly. New business requirements come in mid-design, etc. They might even cancel the whole project if something more important comes along. In that situation, it's best to get some MVP as quickly as possible then iterate on it. Later iterations might totally scrap and rewrite the internals, which is fine if the API sticks.
That makes sense. Like a prototype you hand out so that you can figure out what it is you/client actually want. I don't think of those as first drafts though. Maybe it's a language barrier thing for me.
"Design" has a spectrum of level of detail, anything from a whiteboard full of information to a description of code in a fancy tool that is more detailed than the code itself.
Text (source code) as a representation of ideas can be worked on extremely efficiently at arbitrary detail. At low level of detail only beaten by a whiteboard.
If any piece of information has been missed when creating anything (any form of design or code), updating mutiple implementations of the same thing takes more effort than updating only one (the code).
Too many details in design will require frequent changes, with low level of detail it won't help much to detect missing pieces of the puzzle. Either way it adds effort.
Design has its advantages, lower total cost/effort in the short term isn't one though.
First draft could mean a lot of things. If you mean something you write then rewrite before it's ever released, the same still kinda applies. You might be mid implementation when something changes and ruins whatever structure you had. Or maybe the abstractions aren't very obvious at first even if nothing is changing.
Now, if for some reason, and there are plenty of good ones, you cannot do the former, then sure, you pay that price by redoing some work. But, at that point, you do the same thing you should have done: you design it properly, then you implement your design.
One could argue that implementing a first draft is a way of designing it. Which, I cannot imagine making sense unless you don't know what it is you want to end up with. Maybe if you're making computer games or other creative endeavors?