Agile FAQs
  About   Slides   Home  

 
Managed Chaos
Naresh Jain's Random Thoughts on Software Development and Adventure Sports
     
`
 
RSS Feed
Recent Thoughts
Tags
Recent Comments

Biggest Stinkers

At the SDTConf 2009, Corey Haines & I hosted a session called Biggest Stinkers. During this session we were trying to answer the following two (different) questions:

  • As an experienced developer, looking back, what do you think is the stinkiest code smell that has hurt you the most? In other words, which is the single code smell if you go after eradicating, *most* of the design problems in your code would be solved?
  • There are so many different principles and guidelines to help you achieve a good design. For new developers where do they start? Which is the one code smell or principle that we can teach new developers that will help them the most as far as good design goes (other than years of experience)?

Even though the 2 questions look similar, I think the second question is more broader than the first and quite different.

Anyway, this was probably the most crowded session. We had some great contenders for Smelliest Code Smell (big stinker):

We all agreed that Don’t write code (write new code only when everything else fails) is the single most important lesson every developer needs to learn. The amount of duplicate, crappy code (across projects) that exists today is overwhelming. In a lot of cases developers don’t even bother to look around. They just want to write code. This is what measuring productivity & performance based on Lines of Code (LoC) has done to us. IMHO good developers are 20x faster than average developers coz they think of reuse at a whole different level. Some people confuse this guideline with “Not Invented Here Syndrome“. Personally I think NIHS is very important for advancement in our field. Its important to bring innovation. NIHS is at the design & approach level. Joel has an interesting blog post called In Defense of Not-Invented-Here Syndrome.

Anyway, if we agree that we really need to write code, then what is the one thing you will watch out for? SRP and Connascence are pretty much helping you achieve high Cohesion. If one does not have high cohesion, it might be easy to spot duplication (at least conceptual duplication) or you’ll find that pulling out a right abstraction can solve the problem. So it really leaves Duplicate Code and Primitive Obsession in the race.

Based on my experience, I would argue that I’ve seen code which does not have much duplication but its very difficult to understand what’s going on. Hence I claim, “only if the code had better abstractions it would be a lot easier to understand and evolve the code”. Also when you try to eliminate duplicate code, at one level, there is no literal code duplication, but there is conceptual duplication and creating a high order abstraction is an effective way to solve the problem. Hence I conclude that looking back, Primitive Obsession is at the crux of poor design. a.k.a Biggest Stinker.

  • davcamer

    Naresh, I agree strongly with your assertion that we need *better* abstractions. Eliminating duplication by introduction a mediocre abstraction leads to pain. Removing duplication and parceling it up in an awkward way can make it more difficult to see a more elegant abstraction later. The short-term benefit of eliminating duplication leads to a long-term pain of awkward design.

    A lot of duplication and awkwardness in the code bases I have worked on comes from primitive obsession, so I think you have hit on something with it as the biggest stinker.

  • jufo

    Not as smelly as the ones you already have, but another to look out for is EverythingIsConfigurable. I remember a project using Spring where trading messages were validated by dependency-injected Validators, each of which had dependency-injected ValidationRules, some of which needed to get reference data from the database using dependency-injected Finders. Add to this that the Validators, ValidationRules and Finders had separate Spring configuration files… enough said!
    None of these Spring-configured items needed to vary between environments, or were expected to require re-configuration without recompilation.

    – Justin Forder

  • http://blogs.agilefaqs.com Naresh Jain

    Thanks Justin. EverythingIsConfigurable is certainly a smell worth highlighting. I can relate to your situation. I the last few years, as Spring has become main stream, I see more and more of this happening.

    Some days ago I tweeted saying:

    Sometimes Dependency Injection feels like Decoupling via Obscurity. Would you like some Juice while bouncing off that Spring

  • http://blogs.agilefaqs.com Naresh Jain

    Thanks Justin. EverythingIsConfigurable is certainly a smell worth highlighting. I can relate to your situation. I the last few years, as Spring has become main stream, I see more and more of this happening.

    Some days ago I tweeted saying:

    Sometimes Dependency Injection feels like Decoupling via Obscurity. Would you like some Juice while bouncing off that Spring


    Licensed under
Creative Commons License