Sometimes it feels this is so because we have a lot less number of ruins when it comes to IT related projects. Stop construction of a building you have a gigantic half constructed bloat of concrete and bricks. Nothing can be reused (except for the land). Stop construction of a program and you will have some files which can be deleted, all the machines are general purpose and all this can be reused.
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?"
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.
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.
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.
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.
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.
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.
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.
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.
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).
I agree. There is no field of human endeavor (except war) where you can spend so much and have so little to show for it, as the enterprise software business.
