As they say: an hour of planning saves ten hours of doing.

You don't need so much code or maintenance work if you get better requirements upfront. I'd much rather implement things at the last minute knowing what I'm doing than cave in to the usual incompetent middle manager demands of "starting now to show progress". There's your actual problem.

▲

hrmtst93837 an hour ago | parent | next [-]

If an hour of planning always saved ten hours of work, software schedules would be a whiteboard exercise.

Instead everyone wants perfect foresight, but systems are full of surprises you only find by building and the cost of pushing uncertainty into docs is that the docs rot because nobody updates them. Most "progress theater" starts as CYA for management but hardens into process once the org is too scared to change anything after the owners move on.

▲

lmm 6 hours ago | parent | prev | next [-]

> As they say: an hour of planning saves ten hours of doing.

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

> You don't need so much code or maintenance work if you get better requirements upfront.

Sure, and if you could wave a magic wand and get rid of all your bugs that would cut down on maintenance work too. But in the real world, with the requirements we get, what do we do?

▲

JoshTriplett 5 hours ago | parent [-]

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

▲

hrmtst93837 2 hours ago | parent | prev [-]

[dead]