Re: Question about <The Deadline: A Novel About Project Management >
- From: "H. S. Lahman" <h.lahman@xxxxxxxxxxx>
- Date: Mon, 26 Sep 2005 16:05:12 GMT
Responding to Femto...
hey guys, I'm reading <The Deadline: A Novel About Project Management > from Tom Demarco these days, while at chapter 14, the morovia's first programmer suggest 'the last minute implementation',let the team defer coding,using 40% time or more to elaborate low-level design which should map precisely,perfectly to final code.And not arrange time for debugging.
I haven't read the book so I can't speak to the specific context. However, I can attest that thinking about what one is going to do before doing it is generally helpful in any sort of intellectual activity.
In addition, as a translationist, I can attest that a properly formed design model can be unambiguously converted directly to optimized 3GL code by a fully automated code generator. However, that doesn't guarantee the code will be correct because the design model may not have been correct (i.e., GIGO). So human frailty being what it is, one should still budget debug & rework time. B-)
I can also attest from personal experience that extending the fraction of project time spent on A&D will reduce the fraction of project time spent on debug & rework. At the same time it will improve overall productivity so that total project time is reduced.
However, I would also point out that such up-front thinking must be supported by a good process for managing requirements changes. That's because the thinking takes significant time and most problem spaces have volatile requirements over time. However, change management carries its own overhead, so one tries to minimize it. That's why most shops today employ some form of IID to shorten the think/implement cycle enough so that requirements don't often change within a cycle. (They then use a simplified change management to just insert changes into subsequent cycles.)
BTW, I suspect Demarco's programmer may be actually motivated by a somewhat different issue. By thinking about what one is doing up front one can usually avoid certain classes of design mistakes quite efficiently so that they are never implemented in code. However, if one spends less time thinking up front the chances increase that they will be implemented in the code. As a fairly general rule, design errors tend to be the most difficult to diagnose and rework once the code is written so it is a very good idea to avoid inserting them in the first place. That is, fixing design errors in code often involves massive shotgun refactoring.
************* There is nothing wrong with me that could not be cured by a capful of Drano.
H. S. Lahman hsl@xxxxxxxxxxxxxxxxx Pathfinder Solutions -- Put MDA to Work http://www.pathfindermda.com blog: http://pathfinderpeople.blogs.com/hslahman (888)OOA-PATH
.
- References:
- Prev by Date: Re: Interface complexity problem in game
- Next by Date: Re: How to create an ERD with Rational Rose?
- Previous by thread: Question about <The Deadline: A Novel About Project Management >
- Next by thread: A question about Tony Johansson and a paper
- Index(es):
Relevant Pages
|
