The Deadlinea Novel About Project Management

Ell wrote:

It is unquestionable and can't be denied that the overall thrust and orientation of what TomDeMarco said is 180 degrees the opposite of the oma and XP policies, stances and approaches that have been espoused for years on otug, comp.object, CppReport, the XP wiki server, etc.

They should give intelligent people enough credit to not try to call the night the day, or a chicken a duck. They should have the backbone to accept that TomDeMarco is 180 degrees opposite of their positions and move out of the way of the those who for years have said the same thing De Marco does. The jig is up, that's all she wrote, they have been exposed for the truly negative force that they are.

So... if TomDeMarco has changed his mind about anything in the last 20 years, would that mean he is no longer 180 degrees away from these "negative forces"?

Would it be reasonable to expect the arrival of GraphicalUserInterfaces (and UserCenteredDesign), OO, and VeryHighLevelLanguage?s to have some impact on the proper organisation and process for software development?

In "The Deadline: A Novel about Project Management" (1997) de Marco argues (via one of his characters) that in most projects the "high level design" is just for show, and the real design gets done when people start coding. He goes on from that to outline a process in which design is carried down to such detail that the code more or less *can't* be wrong, in order to make massive savings in debugging.

To quote:

"The scheme involved deferring coding as long as possible, spending the middle forty percent or more of the project doing an elaborate, exaggeratedly detailed low-level design, one that would have perfect one-to-one mappings to the eventual code."

Now unless one is obsessed with a CleanRoom approach ("No one's allowed to compile any code until all the defects have been inspected out of it"), this seems dangerously close to saying (given a suitably expressive programming language) that the code *is* the detailed design.

Add an iterative approach, and the desire to validate the design in a form that the users can relate to, and viewing the code, rather than a paper design, as the dominant element starts to make more sense.

ExtremeProgramming seems to be a methodical development of practices that make this way of working manageable and safe. It also removes the distinction between developing from scratch and maintenance (I've felt for years that maintenance is a harder problem than development from scratch, and one that is not well addressed by most published software development methods).

Like RobertCecilMartin and MartinFowler, I like to be able to work with graphical (UniversalModelingLanguage?) representations of design as well as the executable notations. If we had tools that kept UML and executable code perfectly in sync (Together/J seems to be going in the right direction) would we really need to have this debate?

-- JustinForder?

CategoryExtremeProgramming CategoryProjectManagement