Throw away your first draft of your code
ntietz.com
Throw away your first draft of your code
1–10 of 230 posts
Re: Throw away your first draft of your code
#2Re: Throw away your first draft of your code
#3Re: Throw away your first draft of your code
#4Re: Throw away your first draft of your code
#5The idea of prototyping to uncover 'unknown unknowns' resonates with me, it's like a reconnaissance mission before the actual project. This could indeed save a lot of time and effort in the long run...
Re: Throw away your first draft of your code
#6Re: Throw away your first draft of your code
#7The problem with rewriting is that sometimes you face second-system syndrome[1] where you overengineer everything.
Believe me--it happened to me at Groove Networks after Lotus Notes (ask your grandparents about that).
Re: Throw away your first draft of your code
#8The idea of prototyping to uncover 'unknown unknowns' resonates with me, it's like a reconnaissance mission before the actual project. This could indeed save a lot of time and effort in the long run...
Besides discovering unknown-unknowns it also helps in conveying design/idea to rest of the team.
Re: Throw away your first draft of your code
#9Less cheekily -- it's true that sometimes the best way to research a topic is by writing code that you might appropriately throw away later. And it is extremely important to be able to recognize when something is not worth keeping. But also, often, the most efficient strategy is to think about the problem off-screen enough that you don't subsequently waste time on-screen writing things you won't keep.
It seems strange to usually expect to throw away your first draft. Not every problem is that hard, and even for hard problems, not every first attempt is wrong.
Re: Throw away your first draft of your code
#10Often 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.