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..
replyAnd 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.
replyYou don't ever make the prototype public.
replyAlso, 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.
replyI’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.
replyOf 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?
replyIt's sort of the old General Eisenhower quote: "In preparing for battle I have always found that plans are useless, but planning is indispensable."