Modeling Trap

The following are some excerpts on the subject of modeling from the article CRED: Seven Pillars for Java Development published in EdYourdon's American Programmer magazine in January 1997, written by RichardDrake and NickSimons.

See EvolutionaryDelivery, SevenPillarsOfCred and SuccessStatement for a little more about CRED on Wiki.

Wiki comments welcome, interleaved or at the end. -- RichardDrake

[Rather than writing for Yourdon we should have been on Wiki of course. See SoftwareCannotBeModeled for a profound discussion of the whole notion of modeling software, with many useful links. We were trying to learn from MichaelJackson at the time, who uses the broader, more neutral word "description" instead of "model", which he prefers to restrict to uses analogous to architecture or economics. In Michael's terms where we use model below we really mean "any non-executable or executable description" of the software and its goals.]

CRED has a lot to say about modeling, planning and delivering [the three continuous, concurrent activities of any system development project as defined by CRED]. Quite rightly, this includes a lot about about the four types of modeling mentioned above [BusinessModeling - ImpactModelling - Framework Modeling - Delivery Modeling].

...

All statements about modeling and planning are based on the fact that the system is going to be delivered in an evolutionary manner. This makes a tremendous difference in what one has to discuss and cater to, compared to methods with a more static view.

...

CRED has strong views on modeling, not least because we believe that "object modeling" has gotten way out of hand in many projects. In the most foolish cases, it has caused delays of many months to an obvious, first low-cost delivery of great value to customers. In the end the whole of object technology gets a bad name from this kind of self-indulgence.

...

The trap that many methods have fallen into is to dive at once and in great depth into the finer points of a favored set of modeling notations and techniques. All too often, the naive reader comes away with the conviction that correct use of these modeling notations is a sure guarantee of success. In fact, many years' experience suggests that EvolutionaryDelivery, and attention to the many issues that spring from it, is a far more crucial factor in all cases. [Note the much wider scope claim here for ED than XP claims for itself]

Method books and seminars often create unrealistic and unhelpful expectations for new software managers as to the amount of modeling one should aim to carry out in the early stages of a project - and how easy it is. Meanwhile, new project managers and designers, often with minimal training or implementation experience, are being added faster to the software engineering community than probably any other field.

...

How much modeling [including ImpactModelling] needs to be committed to paper before coding of a new delivery starts is a matter for judgment and experience; we have not found that current methods have helped much here. With our evolutionary and framework hats on, we are quite happy to model much of a system directly with code...

[Note the much wider scope claim here for ED than XP claims for itself]

I think one of the reasons for this is it is just that, a claim. I would love to see some evidence from larger projects, even if just empirical. Most of the comments shared throughout Wiki relating to XP are based off of actual project experiences. To date those experiences have dealt with projects with smallish team sizes (less than 15?).

I'm not trying to undermine the credibility of the claim, because I firmly believe that both ED and/or XP approaches are precisely on the right track, even for large projects. To me, it just makes sense. However, I am not qualified (I will let other XP practitioners speak for themselves here) to say XP will work for large projects. Although my gut tells me it can, I really don't know. I only know it did work on my project with a 6-8 person team, which is similar to the other people who have reported success with XP. And it's not as if XPers don't have some thoughts on this subject? see also LargeExtremeProgramming and ExtremeProgrammingMayScaleUp. -- TomKubit

Agreed, our main experience with larger projects comes from a couple of well known financial information providers. And in all honesty, although TomGilb is known to both organizations (in one case for a good 13-14 years) we do not feel that they have totally "bitten the bullet" in practising EvolutionaryDelivery from our experience (some recent Java projects have been closest).

It takes senior project managers with considerable guts to do this kind of thing - and those two things don't go together as much we radicals might like. See OneLargeEvolutionaryAttempt for one brave man who at least tried. Mostly though, once we had made a firm commitment to ED from 1986 that led to Objective only being considered for small team projects. It was circular, but most of the time it was fine by me!

I'd also suggest looking at project case studies in some of the large UK companies that are part of the DynamicSystemDevelopmentMethod? (DSDM) consortium. DSDM has become a popular lightweight method in the last five years over here. From my experience most DSDM teams are 10 people or under but it is worth asking. Anyone on Wiki have first hand knowledge of large projects using DSDM or at least DSDM-influenced?

-- RichardDrake