Testing smackdown, part 4

Not to keep cross-posting Jeff Atwood (a sign of respect, anyway), but he responds to Robert Martin's criticisms directly.

At what point do you stop having a set of basic, reasonable programming
guidelines -- and start being a Ferengi programmer, an imperfect manifestation
of the ruleset?

This has expanded beyond testing and into development principles, but TDD is still a good straw man for the conflict.

Note that Jeff's argument here is not the same one I was making before about why TDD or another development principles might be pushed aside sometimes (basically: real-world constraints get in the way).

In fact, even though Jeff and I seem to reach the same conclusion, I disagree with Jeff here. This might not be his only reason for discounting the importance of TDD, but at least this particular argument seems weak.

I'm not sure you could follow Robert's principles "mindlessly", so I don't see any problem with putting them out as design goals.

Several years ago, when I started coded heavily in Java, I read that you should only code to interfaces. It also said that behavior used by multiple implementations should be kept in abstract classes; in anticipation of that, it recommended extending abstract classes as a rule, so that specific behavior could be easily moved up if you wanted to generalize. And, actually, those rules make a lot of sense to me.

So, on my next assignment, I did exactly that. Every single class extended an abstract class. Every instantiation was to an interface. To some degree, mindlessly.

But, to some degree, thinking was always required. Do I need this method in the interface? Which part of the behavior goes in the abstract class and which in the implementation?

The real downside was the massive number of files. More files had to be maintained. Creating a class took more time, because I had to create 3 files every time I wanted one. Once that was done, however, the burden wasn't too great, and I did see some benefits later when I went back for modifications and extensions.

On subsequent projects, I created interfaces and abstract classes more selectively. This is closer to the agile idea of limiting complexity to what you know you will need.

With this practice, or pick a principle, say the Single Responsibility Principle, it's much easier to ignore it and just plow forward with the code.

I haven't yet run into a case where someone was absurdly over-applying solid development principles or practices; the incentives run the other way.