The Reverse Guatanamo Principle
Aslak Hellesøy created the …. interesting tool Guatanamo. From the documentation: “Do you have problems maintaining high test coverage? All code is guilty until tested innocent. Send the untested code to Guantanamo!” (that is, delete it)
I think this is a very interesting policy, and even though it is too extreme to ever be practical, it reveals an underlying principle: If code doesn’t have tests, it doesn’t have value. Chances are that it is rigid, poorly designed, and wrong. I call this the Guatanamo Principle: If code doesn’t have tests, it does not have protection from other team members desires to delete it. Go ahead, delete the code!
However, I have noticed a conflict between TDD and the YAGNI principle. Much of our code is only used directly by tests. This often happens when I (or someone else) design a subsystem to be generic before I use it. This code is almost always no good. It is complex and often does not even solve the specific problem it was made to solve. The lesson is that you never need to impement a “generic component”. You need to write a specific component to solve a specific problem (“what is your code doing?”, “oh, you know, something generic. A little of this, a little of that”). This doesn’t mean you shouldn’t generalize, but you should always keep the specific problem in mind. (Thanks to Kevlin Henney for this point)
So, I propose an addendum to the Guatanamo Principle: The Reverse Guatanamo Principle: If a class or public method is only directly used from tests could (and possibly should) be deleted, along with its test.
(When applying the Reverse Guatanamo Principle, please make sure that the class is not included in XML-configuration files, too….)