> In software it's the opposite, in my experience.

That's been my experience as well: ten hours of doing will definitely save you an hour of planning.

If you aren't getting requirements from elsewhere, at least document the set of requirements you think you're working towards, and post them for review. You sometimes get new useful requirements very fast if you post "wrong" ones.

▲

seer 4 hours ago | parent [-]

I think what they meant is you “can save 10 hours of planning with one hour of doing”

And I think this has become even more so with the age of ai, because there is even more unknown unknowns, which is harder to discover while planning, but easy wile “doing” and that “doing” itself is so much more streamlined.

In my experience no amount of planning will de-risk software engineering effort, what works is making sure coming back and refactoring, switching tech is less expensive, which allows you to rapidly change the approach when you inevitably discover some roadblock.

You can read all the docs during planning phases, but you will stumble with some undocumented behaviour / bug / limitation every single time and then you are back to the drawing board. The faster you can turn that around the faster you can adjust and go forward.

I really like the famous quote from Churchill- “Plans are useless, planning is essential”

	▲	JoshTriplett 3 hours ago \| parent \| next [-]
		> I think what they meant is you “can save 10 hours of planning with one hour of doing” I know what they meant, and I also meant the thing I said instead. I have seen many, many people forge ahead on work that could have been saved by a bit more planning. Not overplanning, but doing a reasonable amount of planning. Figuring out where the line is between planning and "just start trying some experiments" is a matter of experience.
	▲	kmijyiyxfbklao 2 hours ago \| parent \| prev [-]
		Planning includes the prototype you build with AI.