If Architects Had To Work Like Software Developers…
This article is symptomatic of how much people expect from computer programmers. This is normally fine for us (unless incredible requirements like in the following email) since we generally love the challenge.
Dear Mr. Architect:
Please design and build me a house. I am not quite sure of what I need, so you should use your discretion. My house should have somewhere between two and forty-five bedrooms. Just make sure the plans are such that the bedrooms can be easily added or deleted. When you bring the blueprints to me, I will make the final decision of what I want. Also, bring me the cost breakdown for each configuration so that I can arbitrarily pick one.
Keep in mind that the house I ultimately choose must cost less than the one I am currently living in. Make sure, however, that you correct all the deficiencies that exist in my current house (the floor of my kitchen vibrates when I walk across it, and the walls don’t have nearly enough insulation in them).
As you design, also keep in mind that I want to keep yearly maintenance costs as low as possible. This should mean the incorporation of extra-cost features like aluminum, vinyl, or composite siding. (If you choose not to specify aluminum, be prepared to explain your decision in detail.)
Please take care that modern design practices and the latest materials are used in construction of the house, as I want it to be a showplace for the most up-to-date ideas and methods. Be alerted, however, that kitchen should be designed to accommodate, among other things, my 1952 Gibson refrigerator.
To insure that you are building the correct house for our entire family, make certain that you contact each of our children, and also our in-laws. My mother-in-law will have very strong feelings about how the house should be designed, since she visits us at least once a year. Make sure that you weigh all of these options carefully and come to the right decision. I, however, retain the right to overrule any choices that you make.
Please don’t bother me with small details right now. Your job is to develop the overall plans for the house: get the big picture. At this time, for example, it is not appropriate to be choosing the color of the carpet.
However, keep in mind that my wife likes blue.
Also, do not worry at this time about acquiring the resources to build the house itself. Your first priority is to develop detailed plans and specifications. Once I approve these plans, however, I would expect the house to be under roof within 48 hours.
While you are designing this house specifically for me, keep in mind that sooner or later I will have to sell it to someone else. It
therefore should have appeal to a wide variety of potential buyers. Please make sure before you finalize the plans that there is a consensus of the population in my area that they like the features this house has. I advise you to run up and look at my neighbor’s house he constructed last year. We like it a great deal. It has many features that we would also like in our new home, particularly the 75-foot swimming pool. With careful engineering, I believe that you can design this into our new house without impacting the final cost.
Please prepare a complete set of blueprints. It is not necessary at this time to do the real design, since they will be used only for construction bids. Be advised, however, that you will be held accountable for any increase of construction costs as a result of later design changes.
You must be thrilled to be working on as an interesting project as this! To be able to use the latest techniques and materials and to be given such freedom in your designs is something that can’t happen very often. Contact me as soon as possible with your complete ideas and plans.
PS: My wife has just told me that she disagrees with many of the instructions I’ve given you in this letter. As architect, it is your responsibility to resolve these differences. I have tried in the past and have been unable to accomplish this. If you can’t handle this responsibility, I will have to find another architect.
PPS: Perhaps what I need is not a house at all, but a travel trailer. Please advise me as soon as possible if this is the case..
This letter is credited to be written by: Kevin Coheen, Associate Professor. Department of Mechanical & Aerospace Engineering Carleton University, Ontario, Canada
Similar Posts:
- Packaging Jars and Libraries?
- Java 6 update 10 Delivered, what’s new?
- Preview of the WikiJava Projects
- A language that is NOT object oriented
- Real programmers
Category: General 36 comments »
February 6th, 2009 at 6:25 pm
That is so true!
February 6th, 2009 at 8:57 pm
you can’t license this under creative commons.. or any license, for that matter; well, unless you wrote it. this is one of those that gets forwarded on and on – a Google search shows links as old as five years.
http://www.google.com/search?q=if+architects+had+to+work+like+software+developers
February 6th, 2009 at 10:51 pm
Hi,
the problems with your metaphor is that you can not compare software development to house development in the way you did because of the difference in their nature. Why? because house development or any other construction with physical material usage can not be as iterative as software. I know something about that because i am programmer and also i’m building a new house:) Many design decisions when building house are incremental and the cost of rollback is really high, which isn’t true when developing software.
February 6th, 2009 at 11:16 pm
Hi Alider, obviously you don’t actually know too much about software development, as the cost of rollback when developing software IS high. The further down the road a project is, the more expensive and time consuming it is to change something.
It is exactly like building a house. People give you plans, then when your putting on the roof decide to change the foundation… Thus, scrapping all your code built upon that and drastic changes to everything else.
Basically, it all comes down to wasting time and money.
February 7th, 2009 at 12:32 am
You’re absolutely right GMNightmare!
There are projects in which the development process could be described as follows:
Someone says: We have to build ‘a piramid’. After a few days (after development has already started and some decisions were made considering the scale of the project) he says ‘piramid’ is not what we actually need, sth similar to the ‘castle’ will be better.
The time goes by and the same person says: after the talk with my client we decided that a ‘bungalow’ is what we realy need.
After the work has finished the client says ‘Yes, this is exactly what I need, a beatiful shed, thanks!’
In some cases there are clients that don’t know what they actually need! They say that they need sth which will do this and this and that. But in fact they are not certain what their needs are.
The truth is that if you don’t know what to build, it doesn’t make sense to build it. Stop for a while (might be a little longer one) and think about how your project should realy look like. Ofcourse it is imposible to predict all the things which can happen in the mean time but the amount of changes should be kept as low as possible and for sure they cannot be the core ones.
In my guess the usual way is to create the plan first than build a house. Never the other way round. Why this order of work cannot be applied to software development, or in other words why is it applied so seldom?
And whatismore it not only comes down to wasting time and money as you said, but it also results in a lot of frustration among developers in a team.
February 7th, 2009 at 5:38 am
Oldie, but a goodie. So true.
February 7th, 2009 at 8:05 am
[...] Si les architectes recevaient le même genre de “brief” que les développeurs. [...]
February 7th, 2009 at 12:08 pm
[...] “If Architects Had To Work Like Software Developers…” : Un article ironique et assez drôle que je vous recommande… Je pense que pas mal de personnes dans le milieu IT se reconnaîtrons [...]
February 7th, 2009 at 11:05 pm
Anyone who tries to claim “software is easy to change because it’s not physical” has obviously never done math, writing, or programming — so anyone who has exercised none of the higher scholastic abilities; philistines.
February 8th, 2009 at 6:49 pm
Hi, i’m not going to proof my experience in soft dev. You said that:
“the cost of rollback when developing software IS high” and it’s true if you take too big steps. It’s true in Waterfall model. But soft dev has changed a lot in last few years. There are such things like Agile/XP and (my favorite) TDD. When working in really iterative (there is a difference to incremental) way you can minimize that cost and this is what customers expect these days and we developers should provide it. House building metaphor is really good to visualize some points but not all and we should not use it blindly.
- Adam Lider
February 8th, 2009 at 11:23 pm
Iterative development must be incremental, otherwise you will stay always at the same point. It doesn’t make sense to create sth in one iteration and in the other destroy it, even if you take as small step as possible (as it is in TDD). I know that this could happen and usually it happens but the point is to do such ‘back-and-forth’ iterations as rarely as possible. Probably in relatively small projects this could be acceptable but in a large scale application development this is just wasting time and money. TDD and other agile technics are good since they help developers i.e. to write better-quality code.
Nevertheless, software development is not just about pressing keys -> creating tests -> writing classes and so on. There must be some analysis too. If requirements change on a weekly basis there must be sth wrong.
February 9th, 2009 at 7:15 am
Of course, if a consumer wants code written that way, it is almost worth it to give them a polymorphic virus. Just explain to them that it changes a little more frequently than they want it to.
If the consumer wants a house that changes its requirements regularly, just sit them in front of the television and have them watch the Sci Fi show Doctor Who… his TARDIS is supposed to morph shape but it’s broken
February 9th, 2009 at 10:34 am
Developer said: “Iterative development must be incremental, otherwise you will stay always at the same point”
That’s true but opposite usually isn’t and this is the problem. In iterative way you are trying to shape big picture at first without going to details to soon and that way you can minimize possible waste.
http://gojko.net/2007/12/04/waterfall-trap/
Developer said: “TDD and other agile technics are good since they help developers i.e. to write better-quality code.”
That’s also true but TDD is for something more. When applied in the right way (it’s not easy and requires a bit of craftsmanship) helps also in shaping that “big picture”, eliminating wast and designing.
I’m really practicing programmer with experience with on-side and outsourced projects as well and i know that to be really successful in Agile approach you need to change a lot of things, and it’s not possible in many cases/environments. An outsourcing or any kind of remote communication can work better when performed in more “up-front” way.
- Adam Lider, just a programmer
February 9th, 2009 at 10:52 am
S said:
“Anyone who tries to claim “software is easy to change because it’s not physical” has obviously never done math, writing, or programming — so anyone who has exercised none of the higher scholastic abilities; philistines.”
I’ve never said that “software is easy to change”. It’s not, but if built in the “right way” (it’s really important assumption) which requires much more from us these days than a few years before then it can be refactorable. A code can be refatorable and it’s should be but many times isn’t because of our mistakes. A house isn’t refactorable and we should not use that metaphor in this area.
In soft dev nothing is easy, changing requirements in particular but we shouldn’t complain or deny – requirements change, that’s the fact and we won’t change it. We have to find the way to deal with it, to minimize waste. We have to be craftsmen.
- Adam Lider, just a programmer
February 9th, 2009 at 9:47 pm
Hi Adam,
there is nothing wrong with using a house metaphor, a house is also built by humans just like software and many other things. Both building a house and developing software requires thinking of what you’re doing. It’s not so dificult to destroy one wall and build it half a meter further. But people usually don’t do it since they know that this will require some effort and will cost them money.
Quotation from the post you mentioned:
“Iterative development offers a chance to see the picture from the start, and guide the development towards the full picture in steps.”
Ok, but in order to see the WHOLE picture from the strat there should be some analysis made. And this usually takes some time. And this is the architect’s plan in terms of building a house. You do not start building your house unless the plan is ready and accepted. You can even buy only just a plan (some kind of specification) in contrast to a fully-furnished appartment (finished application). Whatismore, the plan is not evaluating after the works have been started.
Building a house could be seen as iterative process in a way that you start from foundation/basement then you build walls and so on. It’s obvious that you do not start from painting the walls on your favourite colours.
“Iterations were aimed to deliver blocks of functionality.” – it could be compared to an order in which you first build walls, then ceiling and after that you choose what kind of floor would you like to have inside. The floor, even if it’s not the first or second thing you did, has its place in a house.
After a few years, if you’d like to have some diferent floor it won’t be a problem, it won’t collapse the entire house. And this is because someone has decided that you cannot build walls on the center of the floor
It’s like with the Mona Lisa iterative picture. When you start you know that you’re going to paint Mona Lisa. You know that she will have her hands, eyes, hair … At first they are not very beatiful but they are!
In the middle (or worse in the end) of the painting process a painter will not have a call in which somebody says, ‘I am so sorry, I’ve forgotten to tell you that (let’s say) Mona Lisa should have a right hand and a face’. Even an ordinary craftsman i.e. a jewellery maker has some kind of a plan, even if in most cases, it’s just a sketch. And this plan should not change while his doing the work, since otherwise he will create sth diferent.
The problem with a computer programme is that it’s not something you can touch or feel. If someone build or design a house (or create i.e. some electric device) in a wrong way and when this house collapsed (or this electric device will hurt or kill someone) then he/she could be accused. However, when someone write completely crap code or write totaly screwed-up analysis the chances he will by punished for this are rather minimal or at least won’t have a huge impact on his in terms of law.
It will take a few years or more unless clients/customers realize that software developemnt is not sth which allows them to change their mind as frequently as they want to. Developers are not a slaves who have to do whatever the client tells them. And in my opinion this is how agility looks like nowadays. The sooner client will have a product the better. I hope that this will change since software develoment is relatively young discipline comparing to i.e architecture.
I’m not against introducing aglie practices into software developement but agility does not mean that customers or developers are free from using theirs brains and not taking responsibility of what they’re doing beacause the cost of a rollback or sth else is low. My conclusion is that software is developed – not created in one go. If you would like to develop a piece of performing software you have to understand your domain (and the target use cases) and you have to understand your tools. You have to position and utilize your tools (technology) to achieve your goal. People have to realize what they doing. Developing software is definitely not a no-brainer where you can through around buzz and jump from technology to technology.
P.S.
Alistair Cockburn put an excellent comment on the post you’ve mentioned earlier.
“Incremental development provides information on the /process/;
Iterative development provides information on the /product/.
Both are needed.”
I’d like to emphasise and highlight expecially the last sentence. Agile is not only about a final product.
February 10th, 2009 at 12:20 am
This is why we are “Software Developers”. We work in “software development ” departments, not “software finishing” departments. We have zero materials costs, only tools. With that kind of mutability, there is not reason to ever finish anything. Nothing, other than time (and labor cost) is wasted. But provided you’re salaried, you will work on the items of highest value. Anyway, with zero materials cost, there is no real incentive to spec anything to completion because it is to mutable. Agile (a recent development) is even worse from a planning perspective. The Mythical Man month laid out what I think is the best development scenario – one commander who is given the vision, then organizes people to deliver that vision. He then can take enhancement requests and schedule them as appropriate, as defined by him. While that may seem whimsical, he has a requirement that he deliverers on the necessary vision. No one should understand more than him on timing and execution, and as a result no one has more say. I often think that over-reporting creates an idea that non-software types can be a part of development. But our art is voodoo to them. Software development has no analog in the physical world. Letting them in is futile. While transparency is needed, it shouldn’t be so much that the strings of the puppet can be controlled by the non-technical management.
Anyway, the development commander should deliver on what was first promised and described, then factor in changes which won’t affect design (zero change cost) and defer items if non-zero change cost to a later milestone. having engineering/design churn will give the impression that completion is not approaching. Remember software development is iterative, but not so iterative to your daily change list (ahem, agile, cough). The cost to change something that exists is far greater and needs to be isolated from a financial and engineering standpoint. Then, when the time comes to change what has already been done, a test case needs to exist (and pass) the existing scenario, then the change happens, and the tests are run again to assure no breakage beyond the intended change.
Unit Tests start at zero value, but become immensely important. 3 years on, if you need to change a core function by even just one line, you’ll be able to rest easy[ier?] knowing that it passed the automated tests and no other parts of the software collapsed as a result.
February 10th, 2009 at 4:46 pm
I don’t know why people describe Agile like something without any rules, like a mess. In fact it’s really disciplined approach. XP in particular. Being successful in XP or Srum requires a lot of effort and expertise. I experienced that sometimes developers criticize Agile just because they are afraid of that level of transparency, responsibility and effort. That’s our nature to negate anything what requires more from us without direct profits. I think that we won’t stop that Agile movement. Even *the problem with Scrum* won’t change it. Just because it really rocks when driven well.
P.S. There is nothing like XP to help in “finishing” software (with maximized business value).
Adam Lider
February 10th, 2009 at 6:36 pm
Strange arguments going on. This isn’t about building a house.
It’s an analogy about getting requirements at a level way above what is going on in the comments here. This is at the architect level, not the contractor level, which is where this discussion is centered. All of this happens before pen hits paper or fingers touch tools.
HOW you implement your creation is not the architect’s problem or concern.
FWIW
February 16th, 2009 at 6:29 pm
Most people can only see the bright side of architecture as a profession and do not realize that it is fraught with responsibilities. Any architectural firm may incur heavy liabilities due to the slightest error, oversight, or omission.
Such conditions require the protection of architect liability insurance. It protects professional architects in case of any legal claims that allege negligence on the part of the architect in the execution of services. At times, even when the case proves to have no validity, the legal cost involved in fighting the case can be substantial and can even leave an architect or firm reeling from the financial pressure.
Hence, architect liability insurance is a must for all architects and firms. A standard $1 million policy for a single architect costs about $6,000 – $10,000 per year.
This is just one simple example illustrating how the author of this post has no idea what architects do. As a developer, you have virtual responsibility. Architects are responsible for things that are PHYSICALLY connected to the earth, sometimes for hundreds of years.
March 28th, 2009 at 9:42 pm
Thanks a lot!
March 30th, 2009 at 12:51 pm
oh dear god… it burns my eyes! THE GOGGLES, THEY DO NOTHING!
March 30th, 2009 at 12:53 pm
mack doesnt get it…
April 3rd, 2009 at 1:47 pm
like someone once said
working to a spec is like walking on water, both are easy if they are
frozen
April 3rd, 2009 at 4:07 pm
These responses suck! But the article was funny.
If you have too long a response it sort of ruins the flow. Keep it short, your opinion isn’t THAT important…
April 6th, 2009 at 8:25 pm
If architects did work like software developers the front door to your newly built house would be on the roof, there would be no stairs between the ground floor and the first floor, and the possibility of entering the house via the functional back door would not be permitted as it would involve passing through a room reserved for the architect.
April 7th, 2009 at 4:53 pm
No, it actually goes like this: Build me a house. Do not bother me with blueprints. If you bring me blueprints I will accept them anyway, because I do not bother to read them, or cannot understand them. After house is finished I start complaining about design, and you must correct mistakes I point out. Free of charge of course.
April 12th, 2009 at 6:10 am
ROTFL !!
great writing, thanks
.
April 14th, 2009 at 1:29 pm
I reposted this back in 2004:
http://www.syngin.com/syngin/2004/10/if-architects-had-to-work-like.html
The source that I had listed for it was:
Kevin Coheen, Associate Professor. Department of Mechanical & Aerospace Engineering Carleton University, Ontario, Canada
April 14th, 2009 at 2:01 pm
Thanks Craig,
I updated the article mentioning the original author.
April 24th, 2009 at 12:11 pm
This is very up-to-date information. I’ll share it on Delicious.
April 27th, 2009 at 12:41 am
What makes you think architects don’t work that way? Your description covers almost exactly about 90% of my work, except it’s not all houses, more often being commercial or industrial.
I’ve had clients who wanted to build their dream house but expected it to be built with 1970s budget for such. I’ve had clients up and change the bloody site when I was nearly done.
I’ve worked on a project for over two years during which is morphed from a 1 bedroom 1600 sf executive aerie (overlooking downtown Honolulu) with a possible 600 sf mother-in-law unit below to a three story 5000 sf 3 bedroom, 5 bath with exercise room and two mother-in-law units at which point the client decided living in Phuket would be a lot cheaper.
I’ve worked for other architects who grossly underestimated the cost of their dreams and made changes by the hour. I’ve done restaurants where they’ve changed the name and menu drastically, forcing complete redesigns. I’ve had projects where the foundations were poured and they wanted to change the entire concept. I’ve had clients buy existing projects with approved plans under construction who then changed it all, all the while expecting the work to continue and with no change in finish date or cost.
But then there’s an additional layer of complexity, that of design review boards, where often people who are completely ignorant of design engineering and recently retired professional pains in the rearget to pore over your work and require changes or it doesn’t get approved. Which doesn’t include the official professional design review boards or historical preservation boards or zoning commissions or coastal commissions or City Councils or even just the local building department, which may or may not incorporated personnel who have the least idea of what they are doing. And then there’s the neighbors who all have a stake, of course.
Next one gets to deal with the actual builders who all absolutely know you are just some emo-artist who knows nothing.
Lastly, when was the last time you got sued for over a $1M for a design you did 5 years ago, for an entirely different group of people with an entirely different set of goals?
May 23rd, 2009 at 2:01 pm
ehh.. attractive )
May 23rd, 2009 at 5:54 pm
Great articles, I like your site. I have added it to my bookmarks.
August 4th, 2009 at 6:48 am
now I’ll be tuned..
August 8th, 2009 at 11:01 am
So, so true…
March 14th, 2010 at 8:02 pm
[...] If Architects Had To Work Like Software Developers… | WikiJava Blog (tags: humor programming funny software development fun requirements architecture) [...]