What make developers happy?

In my daily working, what makes me happy is solving problem through my code skills. That make me feel satisfied and productive, and this is pretty common between programmers.

However most of my working hours are spent reading code!


You need to understand the existing code to add new features.

I think that's true for many things. Extending a building, rearrange a song, rewrite an article, all these actions require a good understanding of how they are made and working.

When the code is hard to understand, it is hard to change, and adding new features become difficult and slow.

Therefore developers start seriously thinking how to improve their codebase, and often a big refactor is seen as the only way to improve it.

The word refactor often brings negative feelings to managers. It's not uncommon that an estimation of 2 weeks become months, and due to the pressure, the final code is not so much better than before.

Bad Smell in code

One thing that prevent developers to happily work on their applications are Bad smells in code.

When I first heard the term code smell I thought I know what it is - It is bad and stinky code that make you sick every time you have to change that code.

That gives just an idea, but bad, stinky and make you sick is not helpful in find out what a bad code smells is, it is more about feelings and opinions.

Code smell is instead a well defined term with a precise meaning.

Who they are?

The first who used the term code smell was Kent Beck, then Martin Fowler wrote the book refactoring, in which he lists 22 code smells and explains the methods to refactor your code and get rid of the bad code smells.

Each code smell has a name, some of them have a nice catchy name that makes them easy to remember.

To make things simpler, two Finnish researchers, Mäntylä and Lassenius, grouped them in these 5 groups:

Bad code smells taxonomy

In very short terms:

  • The Bloaters: when classes and methods are getting too fat
  • The Object-Orientation Abusers: when object-oriented are not used to make things clean
  • The Change Preventers: when you need to change something in one place and you have to make many changes in other places too
  • The Dispensables: when a part of the code is useless
  • The Couplers: when some classes present excessive coupling

This is a introductory post, visit the links down the page to know more about the groups and the various code smells.

Are all code smells bad?

In short NO.

It is important to note that

A code smell is a warning sign, it might indicate a problem in your code.

It is usually said bad if actually indicates a problem, and in that case you should refactor it. These are usually small/medium refactors, not big planned ones that scare managers.

Should all the bad smells be refactored?

Once again NO.

You'll want to refactor a code smell only if:

  • it is pretty bad
  • and there is a good chance that you, or your workmates, have to work often on that code.

It take a bit of experience to understand how bad is a code smell.

For example: a 10 lines long method start to be bad (Long Method smell), a 20+ lines is definitely stinky. Anyway even if the method is only 10 lines, but it contains nested conditionals, it is bad (Conditional Complexity smell) and should be refactored to make it simpler.

As a rule of thumb if it is tricky to understand for most of the developers in your team it is a bad code smell.

Finally, even if you are sure about the bad smells in your codebase, that does not mean you want to fix all of them. If there is not plan to evolve that code, and assuming that the code is working well, there is not reason to refactor it. It would be a waste of time. It's better to focus on parts of the codebase that most likely will need changes.


Here are some great links to train your developers nose to find out the bad smells: