If architects had to work like software developers(blog.monochrome.co.uk)
blog.monochrome.co.uk
If architects had to work like software developers
http://blog.monochrome.co.uk/2009/02/if-architects-had-to-work-like-software-developers/
27 comments
Funnily enough, my cofounder is an architect. And from the tales he (and his architect friends) tell me, yes, architecture clients are just as fickle.
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.
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.
<rant>
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.
1993: http://www.cse.buffalo.edu/~mikeb/Architects.pdf
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.
1993: http://www.cse.buffalo.edu/~mikeb/Architects.pdf
Uh, it does say the author is unknown
That's been added. Google's cache of the page doesn't have it. I don't know how long this reference will last, I don't know how Google's caching system works, and the wayback machine doesn't seem to have it. However, here's a link:
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.
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.
OTOH if software developers had to work like architects, you would need to have a degree and several years of experience making coffee for more senior engineers before you were even allowed near a text editor. After that, you could write your own programs, but to actually run them through a compiler you would still need someone who has passed the bar exam, and you'd have to give them a cut of whatever you make off your software.
Well, that certainly would make for better software, albeit more expensive...
I have to disagree. It would make for less buggy software, but I suspect not for software that people want. The best way we know how to make products people want is to get a basic version released and iterate rapidly.
Because it would drive up the cost of software, it would spur the requirements of better requirements definition at the outset.
It would also kill most in-house development, for that matter.
It would also kill most in-house development, for that matter.
As the architecture model fails to construct buildings people want?
People's wants are easily defined once cash money is involved in most industries...
People's wants are easily defined once cash money is involved in most industries...
Applying these hurdles to software would be senseless, because the cost of bad software is infinitely smaller than the cost of bad architecture.
99.999% of software is never in a position to kill someone if it fails catastrophically. 99.999% of buildings are.
99.999% of software is never in a position to kill someone if it fails catastrophically. 99.999% of buildings are.
I believe the problem stems from a misconception on both sides of the table. What passes for design in the software world is little more than what an architect might sketch on a napkin over dinner.
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.
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.
Some architects do. There is an old BBC (I think) broadcast showing Christopher Alexander building a house. He goes to the site with the people who will live in the house, asks them what they have in mind. He has a scaffolding built, then asks the people to sit on the scaffolding in different places and talk about how it feels. Based on that, the rooms are decided, and so on. The house is built incrementally using feedback; there is no up-front plan. Admittedly, Alexander is far beyond the pale of mainstream architecture, but this is way cool.
That was in the BBC adaptation of "How Buildings Learn" by Stewart Brand. Both the book and the miniseries (which is on Youtube in segments) are excellent.
I heard about Christopher Alexander from his renown in programming circles. I wonder how he is viewed in the architectural mainstream?
I heard about Christopher Alexander from his renown in programming circles. I wonder how he is viewed in the architectural mainstream?
I believe he's largely held in contempt, either ignored or dismissed as a loon. Unfortunately, Alexander has done a few things to paint himself into this corner. He seems to have a need to be regarded as a world-historical genius, which isolated him and turned his work into something a bit cultish. That's a great pity because his core ideas are so vital.
That's correct, in the USA, at least -- although they seem to think better of him in Germany (at least, they did a decade ago). He did pioneering work on using computers for design at MIT in the sixties -- but it never really took off, or even worked terribly well. "Pattern Language" is seen as naive and ridiculous in the "top" schools -- but I agree with gruseom that there's a lot of wisdom there. We'll come back to it, as the cycles make their slow turn away from mannerism.
I am formally trained as an architect and I believe there are plenty of overlaps between architecture and programming. In fact, it was a series of computer science programming classes in college that reinforced my desire to study architecture. I found the problem solving and methodology very similar in both disciplines.
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.
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.
Architects do contract work with those types of situations. A lot of IT best practices come from decades of learning from the world of construction. If it costs 80% of your budget to fix a mistake after you're pouring concrete, you're going to make sure you know just where every joint and truss is going to be.
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.
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.
The missing stipulation is that the owner would like the move from his old home to his new home to be seamless, without disrupting his family life in any way.
Roof falls in - oh well, tenant didn't move in yet. Hit undo, problem solved. The design part may well be more difficult, but the build cycle's pretty damn easy by comparison. You can get away with a lot more as a programmer than you can as an architect, I think :-)
I don't find these so funny, because it's obvious to me that there is no single paradigm that fits all disciplines. Architects are not like software developers, operating systems are not like airlines, etc'...
This also applies to any form of web design.
In Soviet Russia, architects do work like software developers.
Perfect! I am sending this to every one of my customers now.
This sounds like a passage from The Fountainhead by Ayn Rand.
why not - just $75/h.
Incidentally, that 3D tag cloud makes me want to punch myself in the face.
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?