Hacker News Reader

Comment by TameAntelope | Hacker News Reader

Being willing to throw away work is the single most effective way I've seen at running an engineering org, both in terms of promoting innovation and in being able to quickly adapt to evolving customer needs as they get revealed.

If your morale is harmed by throwing away work, that's something you should work on.

View on HN

It depends on why you throw the work away. If it's because of issues that should have been apparent with minimal planning, it's disheartening. Obviously, throwing away work is important in general. But consider a project to do taxes that gets thrown away because legal says it's a law taxes be done by hand, that an accountant said used the wrong tax code or that marketing comes back and says it has to be a desktop app.

If that doesn't kill your morale, I don't know what to say.

Meanwhile, by all means discover that no one likes typing numbers on a phone so you have to refocus on taking pictures of receipts and wage stubs and text recognizing them.

Creating the 'typing numbers on a phone' version of the app is relatively trivial, so probably worth doing first. You only want to do the AI version if you're really sure that you need it, or you can afford it and it doesn't delay more important things.

I think you are focusing too much on the example, which was chosen to try to explain my point. Obviously it has to be a simple problem with simple issues to be easily discussed in a public forum.

If you worked on a project for any amount of time that wasn’t put in front of users (who would catch obvious mistakes like what you describe), you aren’t taking your job seriously and have bigger problems than feeling bad about throwing away code.

The point here is that programmers are assigned tasks, do them, and the management (whose job is to put it in front of users) is failing at that leading to wasted efforts.

Although I should point out that 2/3 of the examples would not have been caught by a user, because they are compliance related.

If your team is organized in a way where programmers are assigned tasks to execute, you are not operating on a modern software team, and that is your problem first and foremost.

This is something I've come across in my own experience. If you don't actually have any experience in the problem space, the best thing you can do is make something that just barely works, then scrap it.

Then all the unknown unknowns become known unknowns and you can actually create good solutions to it.

All planning is a waste if you don't even know where the speed humps will lie.

It's basically a variation of Chesterton's fence[1]. There's a lot of hubris in thinking one could write a piece of code better than someone else if one has never attempted to write that piece of code, especially when never even having done anything like it at all.

[1] https://en.wikipedia.org/wiki/Chesterton%27s_fence#Chesterto...

Yeah, like to do the job properly you need someone who's done the same job before. Become that someone by exploratorily building the thing you want to build before you seriously build it.

>All planning is a waste if you don't even know where the speed humps will lie.

If that's the place where someone is, they should be conferring with someone else who knows something instead of trying to fly solo

Blindly going through problem spaces is how you waste your life taking wrong approaches

At google it was repeated that Sergey Brin used to say "all work is throwaway work, it's only the time horizon which is in question".

It's kind trite to say “much is explained”, but… that explains so much about google.

It doesn't really. There is plenty of old code at google, he was just saying it to people who were too scared of doing work they might need to throw away.

The promotion process explains way more of what I think you are getting at.

Throwing away code and throwing away products/features are completely different things, and only one of those is a real problem for end users.

It depends at which level you're at. If you're working at an infrastructure or firmware level, throwaway work can be expensive and time consuming. Re-architecture can also be time consuming. There are some parts you have to spend design cycles on, especially if you're doing a large project. It's not that you can't pivot, but the pivot takes a lot of time. At the very least have a set of System Features and System Guarantees that you will drive towards.

With embedded development it's entirely fine to iterate fast and throw away work, until the product is shipped. And in certain applications it is fine even after it is shipped.

Reply on news.ycombinator.com