Hacker News Reader

Hacker News

Comment by TameAntelope | Hacker News Reader

Parent Full thread

TameAntelope

Projects tend to need substantially less planning than people think.

View on HN

The joke at my previous job was "Months of development can save days of planning."

The management in the company didn't plan anything and the meandering development process showed it.

Please don't underplan. It's awful for morale to throw away work because of bad planning.

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.

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.

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

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.

True, but usually in this kind of situations it's either zero planning or way too much planning and often the planning is also "wrong kind of" planning.

“Shit, the Oracle costs 10x more than the bullshit number we budgeted. Next sprint, refactor to SQLite.”

Reply on news.ycombinator.com