Hacker News Reader

Comment by augusteo | Hacker News Reader

I used to think this. Then I noticed how often "preparation" became its own infinite loop.

At work we built something from a 2-page spec in 4 months. The competing team spent 8 months on architecture docs before writing code. We shipped. They pivoted three times and eventually disbanded.

Planning has diminishing returns. The first 20% of planning catches 80% of the problems. Everything after that is usually anxiety dressed up as rigor.

The article's right about one thing: doing it badly still counts. Most of what I know came from shipping something embarrassing, then fixing it.

View on HN

I think you may have slightly misunderstood the article.

"Preparation" isn't mentioned explicitly, but by my reading it would come firmly under "is not doing the thing".

Getting everyone to fall in love with the thing is not doing the thing... learned this as a data scientist brought in to work on a project which ended soon thereafter. A team of 20 people spent 1.5 years getting people to love an idea which never materialized. Time was wasted because the technical limitations and issues came too late... it died as a 40 page postmortem that will never see daylight.

I learned that lesson as a solo dev on a project that lasted a year, then learned it again as a team of 4 on a 2-year project. I've not had to learn the lesson again but I've certainly trod the same path... 20 people (including some VERY expensive contractors), 3.5 years, AU$80m to deliver what amounts to a timesheeting system that needs a team of 10 people manually massaging the data every month to make it work.

How do you not be "toxic" after that? How do you retain a chipper attitude when you know for a rock-solid certainty that even if the project is successful it's likely by accident?

Is it always like that? I worked in teams where we had some planning beforehand (months, like in your example). We shipped just fine and the product started to bring money. I guess it depends, as usual.

Rimmer planning for his astro-navigation exam sums up the "infinite loop" of preparation.

From the Red Dwarf book and quoted previously:

https://news.ycombinator.com/item?id=28033747

I agree that planning has diminishing returns, yet simultaneously nearly every software project I’ve been part of has been under-planned and ended up worse off for it.

I think the original agile people had the right idea. Do some planning, not too much. Then write some code - but not too much. Then take what you've learned from implementing and replan.

Or if you want another way of thinking about it, code isn't only useful for deployment. Its also a tool you can use during the planning process to learn more about the problem you're trying to solve. When planning, the #1 killer is unknown unknowns. You can often discover a lot of them by building a super simple prototype.

Once something exists, decisions collapse around reality instead of possibility

That’s not a zero-sum game.

Pivoting to zero-planning, would also have a basket of flaws.

Reply on news.ycombinator.com