wbralick@afit-ab.arpa (William A. Bralick) (03/28/89)
It seems to me that architecture (as in buildings, not computer systems :-)
should provide a useful set of lessons for software engineers. The parallels
between software engineering and architecture (especially for a large, unique
building) are striking -- both are labor intensive, lengthy, expensive,
prone to schedule slippages and cost overruns, require not only a sound
design but also good management practices, both can benefit from standardized
parts, etc. Has any formal attempt been made to draw on (this pun
is intentionally left blank) architecture as a model for solving some
of the problems in software engineering?
Regards,
--
Will Bralick : wbralick@afit-ab.arpa | If we desire to defeat the enemy,
Air Force Institute of Technology, | we must proportion our efforts to
| his powers of resistance.
with disclaimer; use disclaimer; | - Carl von Clauswitzjerbil@cit-vax.Caltech.Edu (Stainless Steel Gerbil [Joe Beckenbach]) (03/29/89)
In article <1014@afit-ab.arpa> wbralick@blackbird.afit.af.mil (William A. Bralick) writes: >It seems to me that architecture (as in buildings, not computer systems :-) >should provide a useful set of lessons for software engineers. The parallels >between software engineering and architecture (especially for a large, unique >building) are striking -- both are labor intensive, lengthy, expensive, >prone to schedule slippages and cost overruns, require not only a sound >design but also good management practices, both can benefit from standardized >parts, etc. Has any formal attempt been made to draw on (this pun >is intentionally left blank) architecture as a model for solving some >of the problems in software engineering? I've written a few things to this effect, including drawing the seemingly unpopular view that software engineering is too young a profession to really be considered engineering yet. However, should I decide to do grad school, I guess I'd end up wanting to explore this analogy. And of course I'm glad my father isn't on the network, otherwise he'd be very cheerfully and playfully encouraging me to do so-- especially since he's working in one of Jacksonville's (FL) bigger architectural firms. I'm not sure a formal effort has been made. Give me a year or two to do some academia-programming, and I may end up seriously considering such. As long as I have colleagues and lots of chance to really work this stuff out.... -- Vegetarian Movie of the Week: (farce) | Joe Beckenbach Attack of the | jerbil@csvax.caltech.edu Killer Tomatoes | Caltech 256-80, Pasadena CA 91125
garison@mirror.UUCP (Gary Piatt) (03/29/89)
In article <1014@afit-ab.arpa> William A. Bralick writes:
=>It seems to me that architecture (as in buildings, not computer systems :-)
=>should provide a useful set of lessons for software engineers. The parallels
=>[...] are striking [...] Has any formal attempt been made to draw [up]on
=>[...] architecture as a model for solving some of the problems in software
=>engineering?
The problem with this is that (for the most part) the job of the architect
is done when construction of the building begins. There's still some org-
anizational things to do -- make sure the builders keep to schedule, make
sure the proper materials are used, etc -- but the bulk of the work an
architect does is in the design. Software engineers, on the other hand,
spend significantly less time in design, and more time in programming and
redesign. The optimal experience is that the SE (or SEs) will design the
software and then carry out that design. What actually happens is that
the design will be completed and the SE will begin to carry it out, but
Marketing will change the schedule. The SE will try to conform to the new
schedule, and the customer will ask to add some feature or another. The
SE will begin to add the new feature, and QA will discover a design flaw
that requires the SE to throw out a month's worth of work. And it cont-
inues in this manner until several weeks after the product is released.
These same things happen to the architect, but the design is entirely on
paper, and can be changed (more or less) easily. The implementation does
not start until the design is done. The major problems of software eng-
ineering stem from the fact that the design is not frozen until *after*
the product is released.
-Garison-
Bear in mind that this explanation is based solely on my own experience.Sandeep Mehta@bebop (Sandeep Mehta) (03/29/89)
In article <1014@afit-ab.arpa>, wbralick@afit-ab (William A. Bralick) writes: >It seems to me that architecture (as in buildings, not computer systems :-) >should provide a useful set of lessons for software engineers. In a lighter vein, surely you have seen the following fortune cookie on most BSD UNIX systems: If builders built buildings like programmers write programs, then the first woodpecker that came along would destroy civilization ! To a large extent this may still be true :-). _sandeep p.s. flames >& /dev/null -- Sandeep Mehta ...to be or not to bop ? uunet!philabs!bebop!sxm sxm@philabs.philips.com
hollombe@ttidca.TTI.COM (The Polymath) (03/30/89)
I've heard the creation of a software product likened to the building of a
house. Depending on what changes you want and when you decide you want
them, it gets progressively more expensive.
In the planning stage, equivalent to architect's renderings, changes are
cheap and easy.
In the specification stage, equivalent to blueprints, changes are only
slightly more expensive.
Once construction starts, changes can get very expensive. Even moving a
window is non-trivial. Changing the design of the roof can mean throwing
out much completed work and starting over. You don't even want to think
about changing the wiring after the walls are sealed.
Then there's the kind of change that amounts to: "We love the house you've
built, but could you move it another ten feet back from the curb?"
--
The Polymath (aka: Jerry Hollombe, hollombe@ttidca.tti.com) Illegitimati Nil
Citicorp(+)TTI Carborundum
3100 Ocean Park Blvd. (213) 452-9191, x2483
Santa Monica, CA 90405 {csun|philabs|psivax}!ttidca!hollomberockmore@zodiac.ADS.COM (A. Joseph Rockmore) (04/06/89)
In article <24727@mirror.UUCP> garison@mirror.UUCP (Gary Piatt) writes: Path: zodiac!ames!oliveb!pyramid!pyrnj!mirror!garison From: garison@mirror.UUCP (Gary Piatt) Newsgroups: comp.software-eng Date: 28 Mar 89 18:28:53 GMT References: <1014@afit-ab.arpa> Reply-To: garison@prism.TMC.COM (Gary Piatt) Organization: (Dis-) Lines: 31 In article <1014@afit-ab.arpa> William A. Bralick writes: =>It seems to me that architecture (as in buildings, not computer systems :-) =>should provide a useful set of lessons for software engineers. The parallels =>[...] are striking [...] Has any formal attempt been made to draw [up]on =>[...] architecture as a model for solving some of the problems in software =>engineering? The problem with this is that (for the most part) the job of the architect is done when construction of the building begins. There's still some org- anizational things to do -- make sure the builders keep to schedule, make sure the proper materials are used, etc -- but the bulk of the work an architect does is in the design. this is not true, in general. as the son-in-law of a practicing architect and the son of a general contractor, any complex building (again there is the distinction between a relatively stable design for a small project versus the evolving design for a large, complex one) undergoes many design changes as it is being built. my father-in-law has spend many a month as architect assigned to the construction of a building, doing the appropriate re-design and detailing design as things come up in the construction. why does this happen? in my opinion it is due to two factors: a lack of complete design and lack of analysis of that design. the first means that, given all the drawings and specifications that an architect normally does, there is still a lot left unsaid, and thus up to the builder. the second means that there are parts of the design that are incompatible in some way with the rest, but this is not obvious to the architect because he can't formally analyze the design. both of these analogize to software. (and, of course, the owner keeps changing his mind during construction...) [stuff deleted] These same things happen to the architect, but the design is entirely on paper, and can be changed (more or less) easily. it is much easier to change the design, but much harder to change the implementation in building than in software. The implementation does not start until the design is done. not true, as stated above. The major problems of software eng- ineering stem from the fact that the design is not frozen until *after* the product is released. if then. -Garison- ...joe