Notation Centric

Some corporations equate Object Oriented Design with a specific design notation (i.e. BoochMethod, Object Model Notation, Coad Method, etc). Any failure of these methodologies and their associated notations indicate (falsely) a failure of Object Oriented Design.

With the unification of BoochMethod and Rumbaugh's Object Model Notation we may see one emergent standard notation for major object oriented projects. The ramifications of this possibility is scary. Remember TopDownDesign and all of its restrictions?

Of course, none of these notations and techniques are inherently bad. Each represent years of research and case studies of huge software development efforts. But, they (and the CaseTools that implement them) are taken as rigid guidelines for successful software development by many project managers.

Perhaps we need some AntiPatterns to remind us not to place too much faith in any particular notation or methodology.

-- ToddCoram

So, true, and so sad. I wonder if CargoCult should be adapted to reflect this phenomenon: the representation of something is mistaken for the thing itself. As with organizational charts, so with elaborate design documents which, however detailed, elegantly wrought, and gorgeously bound, do not necessarily lead to functioning software systems. Of course, CASE tool manufacturers have been making a ton o' money selling just such a notion, but the fact remains: if you can't run it, it ain't done yet. And in my experience, CASE tools are great for only one thing: recording a design that is as easily captured on a few cocktail napkins and a pocketful of patterns. -- DonOlson

I have introduced into my speaking and writing the ScannerChallenge?. A CASE tool is slower on entry, but should eventually pay for itself on changes. The question is, how many times can you (a) redraw, (b) scan in, (c) paste into a Lotus note, the design, before the CASE tool catches up. I currently estimate it at 8 changes per sheet. -- AlistairCockburn