Design Smells

Recently I have come across a very interesting book called "Agile Software Development" by Robert C. Martin. This book is one of the most important descriptions about Agile methodologies. I've read edition from 2002 and although it is 10 years old, the knowledge is very general and can be (and should be!) applied today as well. It is about software design, doing it the right way.

One of its chapters describes something called "design smells". This is a list of seven hints that point to a wrong design and "rotting" code. Let us review that list:

Have you ever had a simple looking "change" to do in the code that after some investigation appeared to be a huge chain of other changes? You might say "that's easy, it will took me just several hours to do". After some work you realize that it took you not hours but days! We would like to cut those change chains as quick as possible! It is especially seen when the app is not divided into distinct layers or levels and every module talks with all the others.

After you make a simple change (even if it took you several days instead of hours) other unexpected things can happen. That small piece of modified code could influence in another part of the app and you are getting very strange errors that seem to be unrelated to the original problem. The code is so "fragile" that it falls into pieces after only a small modification.

We should write our code with the view of using this in some other software. Our code should be "mobile" and usable by others. Unfortunately it is usually only a theory and in reality things go in the opposite way. That great class that you've just written is so hard to use and difficult to move that it is easier to write this from scratch. Some code, of course, cannot be moved from app to app - for instance business logic for particular problem, in most cases is unique. But for sure you have some utilities, some general code, code that handles basic business rules, etc. that can be and should be used in your future project. If you are "scared" of using code from your previous projects.. that's not good.

This term relates to ability to preserve the original design of your software. In general you can ask yourself if you do mostly "hacks" or improve the app. For instance if you have some strange source control system and adding new files are complex and needs a lot of time you will probably make changes only in existing files. You will be "scared" of making new files, even though, you know that making small files (one class per file for instance) will improve the whole programming process. Another common rule is to make simple change and follow the bad design. You have small amount of time so instead of refactoring you add a "hack" in the code and that is all. When it happens often, you code will be a mess after some time. 

This sounds quite easy and speaks for itself. Sometimes we would like to predict the future and we make our soft so that even the most bizarre future feature can be easily implemented. We should focus only on existing needs. We have to create great design but not too great and not with so huge effort. Even when you are awesome software developer you will not predict everything. Why you want to implement super fast version of quick-sort (and spending several days on making that work), when you have only 10 items to sort? 

Another simple "smell". When you are tempted to "copy and paste" something, that should be a sign for you to stop and think your life over once again :) When we have redundant code it is not easy to fix a bug. Instead of making a change only in two lines (in one function for instance), we need to track all the 10k lines of code and search for similar occurrences.

When you want to stay in the company for a long period of time you can do this: every module that you create make "unreadable". That way your boss will not fire you, because your team cannot live without you! You can create a myth of being "irreplaceable". But maybe it is better to write a clean and easy to understand code? On the other side you can get a code that was written by someone else, and spend several hours of scratching your head and cursing all the time. After a while you make a decision that it will be much easier to write the code from scratch.

Those seven hints are very useful and can point to some places in you code where things went not as good as you previously designed. After introducing the list author of the book starts to explain what you can do to avoid that "smells". This is as simple as making your design and code S.O.L.I.D. :)

I highly suggest to read the book! 

Link to the book: Agile-Software-Development-Principles-Patterns-Practices - Amazon