If architects had to work like software developers
blog.monochrome.co.uk
blog.monochrome.co.uk
But since it may be new to some... Here are some of the observations on this post I have found interesting:
1. What makes you think Architects don't have to deal with fickle customers who have no concept of time, space, or budget?
2. Every project of any description needs a change control process. If yours consists of exchanging emails, it is going to go this way whether you're a web developer or a tailor.
3. The more expertise a customer thinks they have in the subject matter relative to you, the more comfortable they are micro-managing it. What have you done to educate the customer about how much expertise you bring to their project?
They have loads of self-contradicting stakeholders too (particularly for larger buildings). And they change their mind about the costs. And they get architects to design something to get bids in and then change their mind about half the building. And they want everything, done quickly, cheap, and the highest quality. And they change their requirements. And they expect the architect to adapt to this. And if the architect makes a mis-step in this complex client management process, they will typically get sued and lose money.
I think one way in which architecture is actually much more difficult than software development is that architects often have to pour their heart and soul into a project to design the most amazing building, only to have it cancelled at the last minute. It's a common practice for developers to get architects to design a cool building and get planning permission for it, only to raise the value of the land (by showing that cool stuff can be built on it) so that they can sell it on to someone else (who will of course want something completely different).
To me, that would be very disheartening, because those buildings are often quasi-artistic creations that take a lot of creative energy, and giving it my all time and time again only to have my projects regularly canned and forgotten would just depress me.
Yes it's funny, yes it's clever, yes it's too close to the truth, but he's quoted it without even mentioning that it's been around for years. Author unknown, but a brief Google search shows references at least 16 years old, but it's been around longer than that.
At least he could have the decency to admit he didn't write it.
</rant>
Edited as I find still older references.
http://209.85.229.132/search?q=cache:xnQVWK8a5AsJ:blog.monoc...
Clearly he's noticed that people are dissing him for plagarism and changed it without acknowledging it.
People's wants are easily defined once cash money is involved in most industries...
99.999% of software is never in a position to kill someone if it fails catastrophically. 99.999% of buildings are.
It would also kill most in-house development, for that matter.
The code is the design. What other deliverable of the software development process contains the precision and specificity of a blueprint, which can then be followed to actually build (the double entendre is no coincidence) the thing?
A contractor equates to a compiler, albeit an expensive, time-consuming, and buggy one.
I don't think clients are so much to blame... it's just that software is so abstract and a house so, shall we say, concrete. We need to do a better job of helping clients understand and visualize what we are doing.
I heard about Christopher Alexander from his renown in programming circles. I wonder how he is viewed in the architectural mainstream?
I now split time between the two domains (programming and architecture) and find that my work continues to overlap, but that's what makes it enjoyable.
The cost of change for IT can be similarly daunting. The better we do at understanding what people are looking for up front, the better we're able to deliver what they want. And if they're unsure what they want, perhaps we can help them figure out what they need.
Just like in designing a home.