Sometimes, you come across smelly things in models... things which lead you to take another look. This page isn't here to duplicate CodeSmell''''''s, but rather to list the smells that are commonly side-effects of a model-driven process, or things that are just more detectable in models than in code.

	* '''Inverted method name'''
Sometimes you see a method name that makes no sense in the context of its receiver. For instance, I had to scratch my head over the name ''deliverPart'' on an interface the other day. When I looked at the code, I realized that it should have been named ''acceptPart.'' How does this happen? Well, the developer started with a sequence diagram and named the method as if it was an action from the caller.  

	* '''Prominent Attributes'''
This is just an alarm bell. Sometimes you see a model that has most of the attribute compartments open and most of the operation compartments closed. At that point, you know you are in trouble.

----
	* '''Overuse of buzzword design techniques'''
I wish I could find an online copy of Mahesh Dodani's 'Rules are for Fools, Patterns are for Cool Fools' (JournalOfObjectOrientedProgramming, Oct 1999) where he writes the comedy confession of Pat, the Pattern Guru. It would be great advice for entering an obfuscated design contest if we ever have one. Interestingly, Pat's technique seems to be to use flexibility as the excuse, exactly what XP is against.

(My others are more systems integration smells...)

	* '''New lamps for old'''
... a variation on the NotInventedHere syndrome. Rather than solve a small-ish problem with an old system in a new context, replace it (and all of its ''working'' interfaces) with the latest and greatest system. Heck, we can work the details out later, and we'll call the change 'strategic'.

	* '''Not in my back yard'''
I've been to far too many design meetings for integrating new stuff into big corporate systems, where the buck for constructing a difficult interface gets passed to the design team ''who aren't at the meeting''. Other systems (that could have built that interface) use the system the buck stops at as a proxy. Not only does that last sentence have a smell of its own, you pretty soon come to realize that the interface people pass the buck on is the one that carries the project risk with it, because no-one is nailing it down.

	* '''Strategic Designs'''
An excuse for not dealing with current problems in order to get wined and dined by suppliers. Strategy documents range from pure MotherhoodStatement''''''s, to pretty/cool/sensible designs ''with no hint of how we're supposed to get there from here'', to documents which are actually useful. The latter are rare, and will probably not get approved. Be careful when basing any subsequent design on strategy, since the strategist will  leave to join one of the suppliers tomorrow and someone else's prejudice will take over. I'm feeling fairly cynical today ;o) ...

	* '''ThenaMiracleOccurs'''
Watch out for very hairy spots in the model which the modeller explains by saying, "This bit looks complicated, but there's a clever way of handling it once you go to code it." That may be true, but what if the clever person isn't the one who implements it? There may also be some bald spots in the model which the modeller explains by saying, "There's a lot that goes on right here, but it will be obvious how it all happens once you go to code it." That too may be true, but it's a good candidate for a mini-SpikeSolution, to ensure that what looks like it will be obvious (and workable) actually is.

	 :	''I've often found that the modeling language is not of the same feather as my implementation language, so you have to spooge some details into it. It's just like converting a Java program to a C++ program; it's close, but no cigar. Indeed, when we make models, they only relate to the system in some kind of Candylandish way. In that case, you will be forced to say it's clearer in the code (which is yet another reason to make SelfDocumentingCode).''

Agreed. The warning sign is when you are relying on something "clever" or "obvious" in the programming language to make up for an inadequacy of the model. Now, models ''are'' inadequate (otherwise we'd call them "source code"), so it may not be a problem, but I find it bears investigation to be sure. (I've also found that my clever ideas are often bad ideas; the advice to KillYourDarlings is often sound.)
------
''Examples would really be helpful.''