[patio11]

I think it is partially because nobody has figured out how to reliably estimate project costs and timetables for software. If houses routinely came with estimates like "We think this house will cost between $200k and $2.6 million to build, and it could be done in between 6 months and 10 years, and at the end it may or may not have a bathroom", every general contractor in the country would be in the unemployment line.

"Oh, the wizards burned through another $300,000 last month. Well, who knows what those wizards do. Tell them to get the payroll system ready by next month, OK?"

[robryan]

The analogy fails though because most houses are build in a standardized way, software would have to be pretty much wholly the result of picking and matching preexisting components.

[jonhendry]

Houses probably aren't the best comparison. Commercial real estate is probably better, being a larger investment and with more interests pulling in different directions.

http://i2.photobucket.com/albums/y17/jamesinclair/IMG_6378.j...

A huge hole in the middle of Boston's Downtown Crossing shopping district.

The historic Filene's department store building was torn out, to be replaced with a 38 story tower. Funding evaporated. The project stalled in November of 2008.

[jacoblyles]

I think you've just described government contracting.

[weavejester]

I think the problem is more fundamental than that. The requirements for a house are pretty much static. The requirements for an application are often in constant flux.

[rikthevik]

I think the requirements for the house change a lot more than you think. There's definitely a push/pull with the client in civil engineering as well. And for contractors, oh boy, do they deal with clients changing things on them constantly.

I don't have much faith in most Enterprisey teams to ship good software even if they have a thorough concrete spec. We love to blame changing / incomplete specs, but I'd imagine that most dysfunctional teams would manage to bone up a perfect spec anyway.

[weaksauce]

The largest problem is that the people telling you what they want are not good enough to through every possible path the user may want to go down. This leads to specs that are ambiguous at best, contradictory at worst. It takes a good developer to see the hidden things in the spec and raise the questions that need to be asked before the development goes too far down a bad path.

[rmc]

Programmers have it worse: http://ifaq.wap.org/computers/architects.html

[napierzaza]

What makes up a house is generally understood. A application or game is often a custom job with all sorts of different features and functions. Any decent company should be measuring these things as best they can. It appears that is often isn't done. It's remarkable that EA hasn't been able to do this since they have a bevy of projects that they should be able to use as a rough yard stick.

[gaius]

Ahem:

http://en.wikipedia.org/wiki/Scottish_Parliament_Building#Ti...

[Aetius]

  The software entity is constantly subject to pressures for  
  change. Of course, so are buildings, cars, computers. But 
  manufactured things are infrequently changed after 
  manufacture; they are superseded by later models, or 
  essential changes are incorporated into
  copies of the same basic design. Callbacks 
  of automobiles are ready quite infrequent; field changes of 
  computers somewhat less so. Both are much less frequent than 
  modifications to fielded software.

  In part, this is so because the software of a system 
  embodies its function, and the function is the part that 
  most feels the pressures of change. In part it is because 
  software can be changed more easily--it is pure thought- 
  stuff, infinitely malleable.

- Fred Brooks, No Silver Bullet

[billswift]

Good essay but I don't think he adequately addressed the problem of transaction costs for changing software, either in process or later updating, of course that wasn't his primary point (it has been a while since I read it and I could be misremembering).