Like for everybody else here apparently, this page was useless to me. It didn't make clear what it is about, and after I wasted 20 minutes reading through it, I

Like for everybody else here apparently, this page was useless to me. It didn't make clear what it is about, and after I wasted 20 minutes reading through it, I was no closer to the message than before. Basically it's a lot of name dropping of concepts and keeps promising to get to something later which it then doesn't (within my time frame). I loathe web pages like this, where the whole design is guided by flashy optics but they then don't deliver anything. That said, people here appear to fundamentally agree that the riskiest part should be done first. So I would like to present the opposite view so we can start a discussion. You will probably not be able to do the riskiest part first because you are missing infrastructure. So, if you strictly adhere to the dogma of doing the risky stuff first, you may make rash decisions about the structure of the final product, when you really don't know anything about it yet. You might pull in frameworks and tooling which later turn out to be a bad choice, creating additional stress to replace later. Personally, I have been grappling with this for decades. Watching myself I usually tend to do easy infrastructure first. This has two major reasons. First it gives me time to think about how to actually approach the risky parts. Second, if I then fail in the risky part, the work was not for nothing but I at least got the reusable infrastructure code out of it. Third, it buys me time to gain understanding of the problem space. Fourth, and this is particularly important for open source projects, it gives me a steady stream of successes after each puzzle piece gets finished. Without this stream of successes motivation fizzles and projects die. There are risks with doing it this way, but I think you shouldn't unfairly just discard the whole idea. After all people are doing it like this all over the world. That probably means there is some kind of evolutionary background to it and it was actually better than the other approach. I think a good rule of thumb is that you limit the risk about WHAT you are doing, not HOW you are doing it. By the time you tell your engineers what you are doing, it should be basically risk free. To me it appears obvious that failure is too often blamed on engineers when it was really management failure.