Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Throw away your first draft of your code

ntietz.com

Post reply on HN
Print view View original

41–50 of 230 posts

Re: Throw away your first draft of your code

#41

Post by okamiueru »

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?

Re: Throw away your first draft of your code

#42

Post by fritzo »

darkmarmot wrote: post #24

I don't throw it away, I keep it as a reference. But for anything interesting, I might rewrite from "scratch" three times easily.

I've been following this flow where I write a few successive versions and perform refactoring steps to move one version "towards" another version, as if there is a conceptual force of attraction. It's often unclear which version will prevail, as if I'm acting out a genetic algorithm with a small population.

Re: Throw away your first draft of your code

#43

Post by programzeta »

iraqmtpizza wrote: post #26
neverthe_less wrote: post #23

I'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

I think this depends greatly on the product area and ease of updating. Removing problems categorically from designs early has been valuable to me in the past to reduce surface area, avoid impossible refactoring, and eliminate systemic bug classes.

Re: Throw away your first draft of your code

#44

Post by withinboredom »

kleiba wrote: post #10

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. Sur…

> 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.

Re: Throw away your first draft of your code

#45

Post by eternityforest »

kleiba wrote: post #10

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. Sur…

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.

Re: Throw away your first draft of your code

#46

Post by josephg »

kleiba wrote: post #10

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. Sur…

> 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.

Re: Throw away your first draft of your code

#49

Post by hot_gril »

okamiueru wrote: post #41

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 yo…

> 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.

Post reply on HN