[augusteo]

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.

[jstanley]

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

[olliepro]

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.

[dakiol]

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.

[dwd]

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

[tshaddox]

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.

[josephg]

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.

[KolibriFly]

Once something exists, decisions collapse around reality instead of possibility

[sghiassy]

That’s not a zero-sum game.

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