Spanglish and other smells
Have you ever experienced developers misunderstanding business domain specialists because their jargons are different? When the business and the developers talk past each other the project can suffer serious problems. This is why having a Ubiquitous Language is a cornerstone in Domain Driven Design. Having an ubiquitous language means that everyone who is involved in the project uses the same words to describe different aspects of the solution. To ensure that the software represents the problem domain correctly, it is important that we use the same jargon in our source code. This helps close the gap between the domain experts who define what the solution should do and the developers who make it happen.
A good developer should admit that her expertise in the problem domain falls short of a business analyst with a life-time experience with the subject. With this personal insight, it is easier to follow the domain experts lead and adopt their words and phrases in the teams communications and in our code.
While you need good knowledge of both the problem domain and software design to determine whether a model conveys the domain concepts fully, you can perceive the design smells of a fractured or missing language quite easily.
Spanglish
Even if English is not their mother tongue, most developers write "English" code. The "Spanglish" design smell is something I've observed on such teams. Spanglish is a code-mixing phenomena common with bilingual Hispanics in America. I've often used the term "Norwenglish" to describe the design smell here in Norway. This smell commonly manifests itself when a developer mistakes a word in his mother tongue for a similar sounding English word. An example of this is the Norwegian word for municipality - "kommune" which often is translated to "community".
Another cause of this smell is naïve translation of terms to English. Common examples are national identification numbers. Different countries have different numbering schemes and different names for such identifiers. The United States call the social security numbers, Norway has a birth number and some countries only have special purpose tax file numbers, social insurance numbers and similar. You can translate the Norwegian fødselsnummer to birth number, but this term would not convey its meaning to anyone who is only familiar with medicare or tax file numbers.
The best way to combat the Spanglish code smell is to ask domain experts for the correct English word. If they are unsure about it, get a dictionary and sit down together with the domain expert and find an appropriate word. You'll usually find the correct word or phrase within minutes. This is time well spent, because using the right language in your model makes it easier understand the problem domain as a whole.
Pattern-happy naming
Patterns are fundamental to good software design, but you should not get patter-happy and overengineer your solution. In the introduction to Refactoring to Patterns
Joshua Kerievsky shows an example of "Hello World" written with a truckload of patterns. One reoccurring code smell in this example is that every single type is named after the pattern used. For some patterns, like Strategy, such naming is natural. For others, like Singleton, this naming scheme seldom brings clarity to the domain. A singleton is an object which has exactly one instance and should only be used when the problem domain only has one sole instance of a "thing". This "thing" is usually a well-known concept and names like SingletonThing or ThingSingleton makes the model unclear.
The figure above depicts the Core J2EE Patterns. Before the advent of light-weight J2EE frameworks, these patterns "solved" the complexities of EJB development. Even if we've moved on to using less intrusive technologies than EJB 1 and 2 to build solutions, these patterns are common within enterprise applications. A common theme is that you end up with a lot of odd-named types in the application. Examples of these are ConnectionHelper, ServiceManager and CustomerEntity. Types suffixed with helper, manager or similar often consists of lots of static methods with low-cohesion. You should be wary of these types, because they are often indications of misplaced Transaction Scripts or missing concepts within a domain model. CustomerEntity is just bad - its called a Customer. Jeff Atwood has a good post on SomethingManagers on his blog.
As a father of two I've had my share of lengthy discussions on naming. Choosing the right name is important. Each name has its own story and meaning. In a domain model the language is its backbone. Spend some time refactoring your model to make the language feel more natural - rename types and methods, break up classes and introduce new ones when you discover missing concepts. Be on the lookout for ambiguities in the domain which can be the source of misunderstandings. The best way to establish an Ubiquitous Language is to exercise regularly. Use the language in your models, source code, emails and documents, and especially when you speak with other developers, project managers, users and domain experts.