Architect / software developer here. MVPs/sketches/prototypes are valuable in software, in that they 'prove' something, or set a general outline for how the pr

Architect / software developer here. MVPs/sketches/prototypes are valuable in software, in that they 'prove' something, or set a general outline for how the program will grow. In architecture, vague plans are unhelpful, even misleading. What if you design, say, an indoor plan with inaccurate measurements and later find out that the bed is not going to fit in the bedroom? All your work is for naught, and your changes are going to affect everything else, as your bedroom displaces the kitchen, the moved kitchen shifts the bathroom, etc. In some ways, it's better to start with accurate plans and design while you're 'in deep', than to get a general vague sense. DFS than BFS, to use an analogy. Or to use another example -- it's very important in software to know what platform your software will run on before you develop it. You wouldn't just make a vague program before knowing whether the software is a native iOS app, a web app, a unix background process, a distributed database, etc, etc, right? Of course, there are sketchy versions that architects do all the time - program sketches, massing diagrams, et cetera. But anything that isn't completely abstract or pretty accurate will invariably be completely misunderstood by the client. I've even been burned on a web design project this way - I thought color-coding the wireframes to indicate different functionality would be a helpful idea. Never again - I had to explain over and over that, no, their website would not be a sea of nested red, blue, and green lines.