I am slowly reading blog of J.B. Rainsberger. I found it years ago thanks to book JUnit Recipes, but somehow I lost it.

I have found very interesting article there - The Four Elements of Simple Design. I find it fitting very well into my experience with design.

I claim that developing strong skills of detecting duplication, removing duplication, identifying naming problems, and fixing naming problems equates to learning everything ever written about object-oriented design.

Yes, developing skills and wanting to fix a problem every time it is spotted.

My colleague wanted to add comment to recent post, asking how it is possible to achieve good quality of code. Somehow it did not work as he did not see captcha code. Anyway, I owe him an answer (I hope it was not rhetorical question).

What to do?

In my opinion it is not very hard task. To achieve good internal quality of code (easy to modify and extend, no bugs, no environment for breeding new bugs) a few "simple" things must be in use:

Continuous learning

Without learning we cannot grow, but because our code base grows, new situations happen all the time and some of them cannot be handled by applying of old tricks (like for example "comments and Javadoc everywhere" that was useful in old days). If you look at your code written 5 years ago and you are satisfied with it, you are probably doing something wrong.

Writing readable and expressive code

If code is not readable it takes long time to understand what is going on. If we do not understand code we need to modify problems will occur sooner or later.

Continuous and merciless refactoring

Everybody should try to enhance any code they believe can be enhanced. Piece of code could be written nicely, delivering all expected behaviours in the beginning, but it will inevitably rot with time as new features are added, requirements are changed an so on. So it is important to counter attack it with refactoring.

Nobody should be blamed if piece of code looks strange and contains code smells after some time. But I believe that all developers should be blamed if they allowed it to happen without trying to fix it.

Continuous enhancement of existing code might look like daunting task, but it does not need to be. Any small enhancement every day will do (like renaming local variable or extraction of method). If all team members are doing it continuously they will be rewarded with great code base after some time.

Good tests - unit, integration, acceptance

With "good" I do not mean covering everything, but written in way they do not stand in way of future enhancements. They need to be simple, readable and modifiable. Otherwise they will become part of legacy code we wanted to avoid by introducing them.

Coverage is important too, but if you are afraid to look at test code because there is no way you could understand it quickly, you have bigger problem, that gets even bigger with time until tests stop serving their purpose and only prevent changes (enhancements) of production code.

It works for me

There are more approaches, like pair programming, code reviews, working reasonable hours and so on, but I wanted to mention those that are in grasp of everybody. I said they are simple. What I mean is that there is no magic or something unachievable in them. They only need dedication, persistence and enthusiasm.

There might be another virtue needed - courage. Courage to go against main stream of developers (and managers) that are afraid of changes ("If it ain't broken don't fix it" is their mantra). They are just paralysed by their fear. For example I have heard excuses like "But you don't know what class in other module could depend on this so you should not change public API." Well, it seems reasonable, but unfortunately it is good as excuse only. Many potential problems caused by refactoring will be caught by tests for module and all others by integration build. So if it really happened, that some unforeseen dependence failed to compile I will know soon enough. Compare that risk with its alternative - having that terrible code staying as is for next 2-3 years, causing unforeseen problems as other people will hack new features into it in the future. Does refactoring of code still look like bigger risk to you?

About 2 years ago I was handing my project over to my successor. He was younger, less experienced so apart of showing him details of project I was also giving him good advice.

I was talking about unit testing, TDD, something about design and that led me to refactoring. At the end of the session I gave him Refactoring book thinking how much I helped him.

To my big surprise he came to me next day handing book back with words "I can click in Eclipse". I was shocked, not able to react. My first thought was probably something that I misjudged him. I realized whole point only later, but then I felt it is too late to return to that for him already closed matter.

The real meaning of those words was "I don't know and I don't know I don't know.". Really - he thought that book talks only about things Eclipse can do easily. But that was huge mistake - it talks about more important things like what are code smells, how to detect them, how to achieve better design with small steps, what to do if simple refactorings fail or they don't lead to nicer result and so on.

I believe this book taught me how to work a bit differently - be less concerned about immediate appeal of code I am currently writing, because I can change it easily when bigger picture is available. That I can Extract Method later when I know what it does and how to name it correctly. I do not worry about every aspect, because I know I can change it easily. And I know what my possibilities are, so I am able to spot opportunity when it occurs. I would say that spotting opportunity when it occurs is the most important part. If all code looks satisfying/passable to me, there is no possibility for improvement. I believe it was the first book that taught me something about aesthetics in code.

Looking back to this "incident" I think I missed good opportunity to help him, but it is quite possible his ego did not allowed me to, so maybe my reaction was OK. Since then I try to be more persuative in similar situations. So if you stumble on me, trying to help you, be tolerant and patient, please :-)