The process of Software Development is a lot like the process of Building Construction, and although they also have important differences, these differences are mainly differences of degree rather than kind.
Software folks occasionally make a big deal of the differences between software development and building construction, and building trades/architecture folks often think you cannot do iterative design on buildings.
The fact is, software development and building construction have many important similarities, and many processes that are effective in both.
Both software development and building construction involves the marshaling of numerous interdependent systems designed, built, and assembled by a variety of highly specialized people.
Dependencies
In the software world we have architecture issues (client/server, message-passing, batch processing, micro-kernel, etc.) data structures (databases), business logic, graphic and other user-interface design, etc.
In the world of buildings we have architecture, foundation, frame or shell, electrical, plumbing, wall coverings, HVAC, etc.
Both software development and building construction have numerous layers of dependencies. There are many variations on the actual stack of what depends upon what, but there are always dependencies.
Typical examples of the stack of dependencies in software are hardware, then the operating system, then the programming language, then some kind of data structure, then something to manipulate the data, etc. Buildings too have their stack of dependencies: connection to the Earth (foundation), the load-bearing frame or envelope, utilities, skin/weather-proofing, etc.
Some might say that software may be "built" in many different ways, but that buildings must be built from the ground up. Well, if you think buildings must be built ground-up, do a search for "Linn Cove Viaduct" and see http://www.dot.state.oh.us/se/SI9/19Freeby.pdf, and consider how a space station can be built in orbit.
Incremental Design
These days (early 21st Century) the concept of incremental design is reasonably well known in the software world, and is arguably becoming more popular. There is a long history of incremental design in building - think of the Wright brothers many iterations on their aircraft design and their invention of and use of wind tunnels to test and refine (shall we say "refactor"?) their designs.
Both mathematical and physical models have been in the repertoire of the making process for thousands of years.
These days (2006) we in the software world try to use intensive tests (such as unit tests) and clever modeling in our design/development processes.
Almost 20 years ago I was building full-scale mockups, tests, and experiments of buildings as part of the design process and it works. I was working with Chris Alexander's Center for Environmental Structure and among many other examples of iterative design, complete with unit tests was the work we did on the exterior walls of the Julian Street Homeless Shelter in San Jose ( see this exterior photo of the main building, and this interior of the dining hall - those are sprayed-concrete trusses, also the results of a test-driven design process.)
The exterior wall system went through many iterations, and there were many kinds of tests, of both the visual and physical composition. In each test we would establish a certain standard or required result - sort of making an assertion about the design or structure, and then make a change or build something to implement the assertion.
Some of the tests were physical such as "Is the cover glaze sufficiently free of cracks?" Probably the most frequent kind of tests were tests to verify that a particular feature or system maintained or improved the life in the overall structure. For example, such a test might be "Check that the way the tiles are embedded creates a tangible border that increases the life of the whole wall." And then we would embed tiles using one or another method and check, if the test passed.
Conclusion
The design and development of software and the design and development of the built environment, like all building processes are iterative processes that involve the repeated assembly of existing materials in new combinations and structures, informed by human creativity and driven by human needs and desires. Humans have been building physical structures for many thousands of years, and some techniques have remained essential unchanged in all that time, while other techniques and materials have come into existence more, or less, recently. Those who build - builders of any kind - would do well to learn from each other as builders, and learn to search for the commonalities in our processes, successes, and failures, and to recognize objectively the differences, which are fewer than is commonly believed.
Thanks to Jeff Thalhammer for 'code review' on this document.
See Also
Software folks occasionally make a big deal of the differences between software development and building construction, and building trades/architecture folks often think you cannot do iterative design on buildings.
The fact is, software development and building construction have many important similarities, and many processes that are effective in both.
Both software development and building construction involves the marshaling of numerous interdependent systems designed, built, and assembled by a variety of highly specialized people.
Dependencies
In the software world we have architecture issues (client/server, message-passing, batch processing, micro-kernel, etc.) data structures (databases), business logic, graphic and other user-interface design, etc.
In the world of buildings we have architecture, foundation, frame or shell, electrical, plumbing, wall coverings, HVAC, etc.
Both software development and building construction have numerous layers of dependencies. There are many variations on the actual stack of what depends upon what, but there are always dependencies.
Typical examples of the stack of dependencies in software are hardware, then the operating system, then the programming language, then some kind of data structure, then something to manipulate the data, etc. Buildings too have their stack of dependencies: connection to the Earth (foundation), the load-bearing frame or envelope, utilities, skin/weather-proofing, etc.
Some might say that software may be "built" in many different ways, but that buildings must be built from the ground up. Well, if you think buildings must be built ground-up, do a search for "Linn Cove Viaduct" and see http://www.dot.state.oh.us/se/SI9/19Freeby.pdf, and consider how a space station can be built in orbit.
Incremental Design
These days (early 21st Century) the concept of incremental design is reasonably well known in the software world, and is arguably becoming more popular. There is a long history of incremental design in building - think of the Wright brothers many iterations on their aircraft design and their invention of and use of wind tunnels to test and refine (shall we say "refactor"?) their designs.
Both mathematical and physical models have been in the repertoire of the making process for thousands of years.
These days (2006) we in the software world try to use intensive tests (such as unit tests) and clever modeling in our design/development processes.
Almost 20 years ago I was building full-scale mockups, tests, and experiments of buildings as part of the design process and it works. I was working with Chris Alexander's Center for Environmental Structure and among many other examples of iterative design, complete with unit tests was the work we did on the exterior walls of the Julian Street Homeless Shelter in San Jose ( see this exterior photo of the main building, and this interior of the dining hall - those are sprayed-concrete trusses, also the results of a test-driven design process.)
The exterior wall system went through many iterations, and there were many kinds of tests, of both the visual and physical composition. In each test we would establish a certain standard or required result - sort of making an assertion about the design or structure, and then make a change or build something to implement the assertion.
Some of the tests were physical such as "Is the cover glaze sufficiently free of cracks?" Probably the most frequent kind of tests were tests to verify that a particular feature or system maintained or improved the life in the overall structure. For example, such a test might be "Check that the way the tiles are embedded creates a tangible border that increases the life of the whole wall." And then we would embed tiles using one or another method and check, if the test passed.
Conclusion
The design and development of software and the design and development of the built environment, like all building processes are iterative processes that involve the repeated assembly of existing materials in new combinations and structures, informed by human creativity and driven by human needs and desires. Humans have been building physical structures for many thousands of years, and some techniques have remained essential unchanged in all that time, while other techniques and materials have come into existence more, or less, recently. Those who build - builders of any kind - would do well to learn from each other as builders, and learn to search for the commonalities in our processes, successes, and failures, and to recognize objectively the differences, which are fewer than is commonly believed.
Thanks to Jeff Thalhammer for 'code review' on this document.
See Also
- Review of Christopher Alexander's "The Nature of Order", in Katarxis Nº 3
- A contrary opinion: http://www.agilemanagement.net/Articles/Weblog/ConstructionAnalogyAgain.html
- Another contrary opinion: http://www.jamesshore.com/Blog/That-Damned-Construction-Analogy.html in which James Shore argues that "Ultimately, construction is about dealing with physical objects.", which I disagree with: In my view, ultimately construction is about making things. I suspect that Mr. Shore has never built a building.
- How Buildings Learn: What Happens After They're Built (Viking-Penguin, 1994; in the UK, Orion Books). The author, Stewart Brand says "It was written (and designed and laid out in detail) to change the practice of building and the use of buildings the way Chris Alexander's A Pattern Language and Jane Jacobs's The Death and Life of Great American Cities have done."
- Martin Fowler's Refactoring Home Page
- Here's another disagreeing post - this one from Johanna Rothman.
- George Dinwiddie ponders this issue.
Technorati Tags: buildings, construction, programming, software, software development
4 comments:
I very much agree with what you say. And, this might sound a bit escapist, but the more experience you have as a software developer, the more you can "see" the building you are constructing. Probably that's true for any other work, too, especially when dealing with more or less abstract things (like math). But it's hard to describe it to others. Maybe they tried to visualize this phenomenon in the movie "Matrix" (seeing the world by looking at the code).
I thought the information above has given me great topics to think about. Thanks!
Best wishes,
Software
http://www.vinove.com/
I have held this view on and off over the years and now have resovled not to use the analogy.
See my posting as to:
http://kingtaipan.blogspot.com/2007/05/software-development-analogy.html
I am also agree with you.1 More vote from my side.
Post a Comment