Behavioral Smells

I was reading Martin Fowler's post on pairing misconceptions, where at the end he writes about how problematic code base encourages problematic developer behaviour: "It's only worth pairing on complex code, rote code yields no advantage". The problem here is that rote code is a mechanical solution, created without taking into account the bigger picture - precisely the problem that pairing helps to solve. This type of problem is similar to a code smell but is expressed through human interaction (or its absense in this case) - you could call it a behavioral smell.

I noticed that on the current project, in addition to somewhat reluctant pairing, the team has another problem - oftentimes when a business problem is discussed, the conversation revolves around low-level technical details. This prevent the customer team from contributing to the resolution of the problem.

In our case this behaviour is caused by a weak domain model that is insufficiently isolated from legacy db schema and esb messages. The model lacks useful abstractions representing business concepts and resulting business logic is very procedural - expressed using low-level operations on objects' fields that were extracted by breaking encapsulation. In the absence of higher-level abstractions the conversation is forced into technicalities of the problem.

I find it interesting how distinct code problems cause rather distinct behavioral smells. I am sure that there are more - perhaps this a topic to bring up during a retrospection meeting? By drawing attention to such behavioural smells we can identify issues before they grow into serious problems or highlight existing problems in our code bases.