> A lot of software people like to jump in and I see them portray the planning people as trying to figure everything out first.

My approach, especially for a project with a lot of unknowns, is usually to jump in right away and try to build a prototype. Then iterate a few times. If it's a small enough thing, a few iterations is enough to have a good result.

If it's something bigger, this is the point where it's worth doing some planning, as many of the problems have already been surfaced, and the problem is much better understood.

▲

renox 3 hours ago | parent [-]

I've seen some issue with this approach is that management will want to sell the prototype, bypassing the "rewrite from the lesson learned" step, and then every shortcut took into the prototype will bite you, a lot..

And things like "race conditions"/lack of scalability due to improper threading architecture aren't especially easy to fix(!)..

▲

dasil003 7 minutes ago | parent | next [-]

The Anna Karenina principle looms large in software engineer projects. Basically there are an infinite failure modes that can occur due to small actions or wrong thinking by one or more influential people, but there is only one way to make large projects successful. Basically the team has to have sufficient expertise to cover the surface area, and those individuals need enough trust from leadership to navigate the million known and unknown pitfalls that await.

▲

wtetzner 3 hours ago | parent | prev [-]

You don't ever make the prototype public.

Also, there's a certain point where you can't avoid management sabotaging things.

	▲	dpflan an hour ago \| parent [-]
		Sometimes you don't know what needs to be built until you build it. These end-to-end prototypes are how to enhance your understanding and develop deeper intuition about possibilities, where risks lie, etc.