I want to try it, but I don't fully buy it. It doesn't seem to fit the reality of most projects I've worked where you have the luxury of so much analysis, trial and well defined requirements.

My approach in development is in general to give a working prototype as soon as possible to the relevant users and stakeholders and keep refining those.

The con of my approach is that then user think the project is in a much advanced state than it is.

I have found that the "ship something then iterate" approach to software development can get stuck in local optima without a clear path to get out when it gets flooded by unforeseen problems. Then it becomes a maintenance nightmare. But by then the original developers will have moved on with their careers or they are just happy chugging along with the mess they've created because they're not competent enough to know better.

i usually value component diagrams more than normalized databases plans etc — not every system uses a database!

chuck some blocks into diagrams.net, sketch out the information flow at a high level, then go implement it.

i find it often helps factoring the code a bit earlier, meaning the prototype looks … less like a prototype in the code =p

also can be faster to move around blocks in a diagrams.net diagram than it is to refactor large swathes of the underlying code related to those blocks.

Me too. I worked with some people who thought the database was an implementation detail. This created quite a lot of friction. I hope it was a learning experience for all of us.