3 ms·

Right - to be clear, I'm just suggesting applying software design principles to architectural plans / blueprints, not to buildings. As an example, coming up wi

Right - to be clear, I'm just suggesting applying software design principles to architectural plans / blueprints, not to buildings. As an example, coming up with a vague sketch, possibly even hand-drawn, or with inaccurate measurements, to present to a client quickly, and get feedback on, before progressing to a more details. At least with the architects I've worked with, they have a tendency to present plans A, B, and C, which are all incredibly detailed, with exact measurements 3-D renderings, etc, all beautiful to look at. However, it then turns out that I, as a client, really don't like some fundamental things about plan A and B, but can combine aspects of them, and that plan C involved some materials that cost 10x the alternatives, or aren't permitted for use in the building, and are basically a waste of time to discuss. I'm just suggesting that it's good to get client feedback on things at an earlier stage, before fleshing out the detail on things that turn out to have fundamental problems.

adrianratnapala 10y ago
Ok that makes sense. But even here, and even in software it is tricky area to navigate. I have found from experience that if I give a binary, they will, ever treat it as a mere sample, no matter what mickle warnings I send with it. They will treat it as the "official" version and ask questions about why various things work as they do, or why certain things are missing. This can be very distracting if you are not prepared for it. So now I make sure that anything a customer sees is a release in some formal sense, and belongs to a proper release process, which includes QA.
brenschluss 10y ago
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.

adrianratnapala 10y ago

Ok that makes sense. But even here, and even in software it is tricky area to navigate. I have found from experience that if I give a binary, they will, ever treat it as a mere sample, no matter what mickle warnings I send with it. They will treat it as the "official" version and ask questions about why various things work as they do, or why certain things are missing. This can be very distracting if you are not prepared for it. So now I make sure that anything a customer sees is a release in some formal sense, and belongs to a proper release process, which includes QA.

brenschluss 10y ago

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.