> 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.
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(!)..
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.
You don't ever make the prototype public.
Also, there's a certain point where you can't avoid management sabotaging things.
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.
I’m the same. Often the first step is a time-boxed exploration, just trying to make the key pieces work in any way to encounter major blockers as early as possible. No planning, no design, not following any best practices, often all in a single file. Then from there, either refactor/rewrite or just use it as input for planning.
Of course, it requires some discipline to not just yolo the prototype into production when that’s not appropriate.
Exactly. On a yuuge project, I first identify the Risks. Then, evaluate the risks -- can <ZZ> actually be done? In XX time? For YY dollars? with acceptable bugs on 1st version?
It's sort of the old General Eisenhower quote: "In preparing for battle I have always found that plans are useless, but planning is indispensable."