I saw that one topic of the book is in which ways software projects are comparable to other types of projects (and in which ways they aren't).
We often are compared to car manufacturing or house building, and I always felt that the analogy lacks in many respects. I currently tend to think that software development is more like developing the blueprints in other engineering disciplines.
I would be interested in hearing your (or anybody else's, of course) take on this issue...
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
In some ways i feel Software process has few things common with other engineering process for example(just my thoughts). In home building - we have plan, right view, front view and left view. usually 2 or 3 views can give you an isometric projection of the building.
same way in Software design using UML we have different view (use case view, Design view, Process view, Deployment view and ) not all of these views are required, a combination or 2 or 3 views will give you enough details to understand the system.
also Peer-reivews for artifacts are something picked up from Auto industry where each part produced goes thru an inspection(quality assurance).
I'm actually in the process of writing my August column which covers this very issue. I'm a firm believer that the analogies with home building and civil engineering are actually tenuous at best, at least when it comes to agile development.
For traditional development, perhaps the analogy holds. Or perhaps the analogy is one of the reasons why traditional development seems to work very poorly.
Having said all this, I'm going to share the results of an experiment I've been involved with applying agile techniques to construction efforts. It'll be interesting.
Actually, I just came back from an excursion (for those not in the know, excursions are events where students go to a company, ask tough questions, and drink free booze) where I did a presentation about the things the software development industry could take away from manufacturing methods such as the Toyota Production System, Kaizen, Total Quality Management, and Lean Manufacturing. I'd say there's a lot of stuff in there that screams "AGILE" with big letters.
This is what we might call a "target-rich environment".
Analogy is a way of trying to explain things without resorting to technical jargon. Sometimes it can be very useful in explaining things to people who are not skilled in the art, as the patent people say.
The problem is that sometime the analogy is just plain wrong, or misleading. In particular, construction analogies that have been used in software are only half-truths. The problem is deciding which half is true and which half is not.
There is an entire chapter in the book entitled "Bad Analogies".
I think that really good analogies can be extremely helpful. On the other hand, it is very easy to draw a bad analogy. Therein lies the problem: the non-expert reader cannot tell the difference. And that is exactly the reader for whom the analogy is intended.
I don't think any of the "is it art?" or science or engineering debates have helped me produce better software. It is what it is and I just want to get better at it.
Our CIO likes the city planning analogy at a very high level. You can't put up a building without roads or power or water, you need a permit and maybe an engineering proof to build something unusual. He stretches the metaphore further and better than most.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Joined: Dec 12, 2003
Lasse, you might like "Lean Construction" by Mary and Tom Poppendieck.
Joined: Jan 23, 2002
Originally posted by Scott Ambler: Lasse, you might like "Lean Construction" by Mary and Tom Poppendieck.
I did. Thanks. I've been meaning to read all of Mary's (and Tom's) articles but I hadn't read that one, for example.