This evening Michael Feathers gave a talk at javaBin Sørlandet, the local Java user group. Michael Feathers is a “programmer celebrity” and is perhaps most known as the author of the book Working effectively with legacy code, the author of the C++ unit testing framework CPPUnit and for being one of the Object Mentor‘s.

I’m actually reading the book at the moment, and I find it very good and interesting. Put shortly, it will teach you how to add features to an existing code base (that is not in test harness) in a good way. It contains a lot of typical questions with good answers. Really a lot of useful tips and tricks that will make you a better programmer, and less painful to work with legacy code!

The talk Michael Feathers gave was not on legacy code, but on the synergy between testable code and good design, and it was indeed very interesting! Code that’s hard to test, is most likely hard to test because the design isn’t that good. For instance, a widely asked question is how to test private methods. There are lots of answers to this, but one of the solutions to his example was to extract the code into a new class. The reason for this was separation of concerns. By following the Single Responsibility Principle (SRP), we get classes that in most cases are easy to understand, and also easy to test. Also, as he quoted Robert Martin (Uncle Bob) on that when a class has a single responsibility, there is only one reason for it to change.

Feathers also drew a line from how software design got better when separating the concerns and making more, but simpler classes, with how our brain is working and how we find it easier to understand and remember things when they are less complex. Two dependencies are way better than five!

Another good point (based on a quote from some guy I don’t remember the name of) was that the people that find simplifying a system unnecessary is most often the system expert. The guys who live in the code base all day long, and now every corner of it. Though this may be OK for them, a developer that never has seen the code before will most likely have to spend hours, days, weeks or months in it before her/she gets a good overview and gets comfortable adding features or making changes. It’s clearly that a simpler design is a better design!

Disclaimer:
This is not meant to be a complete summary of the talk that was given on today’s meeting, but more like a teaser for you, and note to self for me I might as well also have expressed something in a different way, and not necessariliy 100% correct. But anyway, it was fun to attend, and I’ll continue on my path towards becoming better at TDD and good design.