> you're gonna wish you spent a bit more time at the starting line wondering what to build it out of.
Sure, but usually spending a bit more time at the starting line (or rather "much more time" or "all the time in the world, until there's no time left and you still have to use the duct tape version, now in an even bigger hurry") won't help you find the problem spots. Hindsight bias is very well and alive and usually all the "yeah, we should have thought about that before" remarks are just that. You wouldn't have thought about it before, because you need the scars to tell you "Bad idea, don't do it again."
As a general rule, decision made due to regret ... well tend to lead to more regret. That happens to me a lot. What a lot of people don't do after a project is to first evaluate how well the whole thing worked.
How many bug incidents were there ?
How many times did a design decision have to be refactored out ?
How many times did you really have a problem ?
Then, first things first, take out all problems that were obviously not project related. The team moved ? Someone went on holiday ? All of those don't matter.
After that, you'll have problems left. If it's 3 problems, none of which delayed more than 2 weeks/10%, your project went as well as you can reasonably expect. Don't change a thing. If after that you arrive at the conclusion that the project went ~80% as planned, then you've simply done it right. There are no lessons to be drawn from mistakes, because the fixes are likely to screw you up more than the "mistakes".
Even when this is not the case, you should limit fixes. Take the top-3 problems, at the very most, and implement a fix for one of them. Then try to mitigate the second and stay away from everything else.
If you don't you'll have seriously more regrets about your next project a whole than your current project.
Lots of people generally don't do this. They do a project, then switch programming languages. That's a decision you should make once in 5 years (unless you're switching back after a disappointment). People seriously overcompensate. From management to developers. Redesigning an entire organisation because one bad apple leaked something is very likely not justified, and similarly a rewrite is almost never justified.
Sure, but usually spending a bit more time at the starting line (or rather "much more time" or "all the time in the world, until there's no time left and you still have to use the duct tape version, now in an even bigger hurry") won't help you find the problem spots. Hindsight bias is very well and alive and usually all the "yeah, we should have thought about that before" remarks are just that. You wouldn't have thought about it before, because you need the scars to tell you "Bad idea, don't do it again."