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

101–110 of 230 posts

Re: Throw away your first draft of your code

#101

Post by almostnormal »

cratermoon wrote: post #79
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…

> You design it properly And how, if I may ask, does one design it properly?

That's easy. Create one, try to implement a bit of it, throw the design away, and then create the real one.

Re: Throw away your first draft of your code

#102

Post by ninepoints »

nemetroid wrote: post #38
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…

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.

This is such a HN phenomenon it infuriates me. Read article. Then read comment that misconstrues article to be something completely different, accompanied with loud critique. Read replies all in violent agreement to obviously self-evident strawman.

Re: Throw away your first draft of your code

#103

Post by nraf »

We do this occasionally as a tech spike - if there’s a lot of uncertainty or if we need to evaluate between a couple different approaches, we’ll dedicate 2-3 days to hacking away with the aim of lifting the “fog of war”.

Re: Throw away your first draft of your code

#104

Post by tracker1 »

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…

I'm largely with you on this... do the simplest thing that gets a job done, that you assume will be replaced, and don't be surprised when it's still un use a decade or more later.

Re: Throw away your first draft of your code

#105

Post by wpietri »

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…

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.

Re: Throw away your first draft of your code

#106

Post by tracker1 »

lxe wrote: post #17

Throw away 1st, second, third, etc... Write your code in small replaceable/disposable POCs until at some point the architecture and coherence starts to take shape. That's the advantage of software over other work. You have 0 material sunk costs. Unlike building a bridge, which you can't just tear down and iterate, with software you can develop a workflow where you break things and iterate quickly.

There are of course software systems with a very large bit of complexity and entrenchment... least of which the complexity added in order to avoid said entrenchment in the first place.

Re: Throw away your first draft of your code

#107

Post by sideproject »

Well, maybe not throw away everything, but I understand the principle. There are also other areas where this could help - and one of them is "naming". Sometimes when you start a project, you don't really know what the best names are for things. Project name, repo name, service name etc. So you choose something that you think it's ok and you go ahead. As the project progresses, you realise you've named things wrong, but renaming is so annoying and tedious. Often we ignore the bad names because it doesn't seem significant. But names are how people burden their cognitive load (an example, we named our repo after planets rather than describing what the repo does - "acme-customer-module-frontend" but we named it "pluto" - now everyone has to remember what pluto is and make sure pluto is not neptune).

Re: Throw away your first draft of your code

#108

Post by ipaddr »

eternityforest wrote: post #45
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 optim…

Smart people can ignore ugly code. It's the people who get easily confused that need to see clean and easy to understand code.

Re: Throw away your first draft of your code

#109

Post by almostnormal »

okamiueru wrote: post #61
hot_gril wrote: post #49

Earlier quoted context omitted.

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

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.

Re: Throw away your first draft of your code

#110

Post by wpietri »

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…

I definitely disagree with you on the first point.

Setting aside the part that's just fussbudgetry, I think "proper" coding is about doing things that pay off in the long term even if they feel burdensome now. As an example, I'm a huge fan of good automated tests for long-lived code bases. But if I'm just writing a quick, throwaway script, then building a bunch of automated tests are going to slow me down.

Throwaway prototypes are another area where you can save a lot of effort if you have really committed to throwing the code away once you've learned what you set out to learn. As a physical analogy, before the Long Now built out their bar/cafe space in San Francisco [1], we spent a day in the raw space building furniture and walls out of cardboard and tape [2]. It let us get a real sense of how the designs would work in practice for actual use of the space.

In the past for a number of projects I've done throwaway prototypes and then started fresh with "proper" engineering, which for me usually includes pairing, test-driven development, and continuous deployment. I've also done ones where we think we understand it enough and just start building. And either way, we usually end up evolving ways to prototype on top of the existing platform via feature flags, etc, so we can learn something from the real world and then decide whether or not we want to refactor to accommodate a major change.

[1] https://theinterval.org/

[2] https://vimeo.com/73959127

Post reply on HN