@Mike G
SOLID is a set of OO design principles, not rules, and while I agree with your points of philosophy and science and induction, they really don’t apply here. Yes, it is a problem, if people think these principles are some kind of universal truth, but that is hardly something to blame on a set of principles, is it?
The SOLID principles, while collected in the written work of Robert C. Martin, are not the experience of him alone. Robert C. Martin is just one of the guys who captured and described it. You can pick any textbook on OO design, and be able to see the same experiences and principles laid out there, just described in a different way. SOLID has become popular exactly because they boil down to the essential principles with which you can judge the quality of a design. These principles are gathered from many people over many years. Dismissing experience with an argument about missing empirical evidence is just far off, e.g. you don’t argue about missing evidence when a craftsman criticises another craftsman based on good craftmanship which is the experience of the trade as a whole gathered together over the years.
I also suspect alot of people missed the point that these principles really are just OO elaborations on the good old (familiar?) design principles coupling and cohesion. Is it really that difficult not to recognise this?
SOLID principles are not patterns either, so there is no discussion of advantages and disadvantages of course. You don’t need much experience to judge the quality of the principles yourself. They are about what makes a good OO design, not so much about how to mitigate bad design, although you can certainly use them that way.
Principles don’t prohibit innovation, how could they? Principles don’t prohibit thinking. People can innovate and think for selves and use principles just fine without any problems, given they have been encouraged to read and think of course, but if that’s not given, you have bigger problems than using/not using some set of principles.
Jeff Atwood wants us to think about our work without getting too locked up in principles and rules. Sure, fine, I agree wholeheartedly, but he sure picked a bad example and a bad way to show it, suggesting that he’s actually thinking only very cursory about the issues, which seems so typical for blog articles, but I still think a minimum of professional courtesy is in order, rather than blatantly making a small point at the expense of solid advise and experience offered elsewhere.
As far as instructions on a paint can goes, they may have their value, probably to begin with, but I can only say that if people aren’t that prepared to read and study about what they are doing, I don’t think they should be doing it at all. This may seem harsh, but it’s not really. I don’t have a problem suggesting that a little professionalism, and a little pride in the business we’re in, is in place. Other businesses have this too, and to a much higher degree even, so I don’t think I am out of line suggesting this. That’s why it’s just so out of place to point a finger at SOLID which has nothing to do with these instructions on a paint can.
Imagine this was 1979, and Jeff had argued against structured programming and the design principles of cohesion and coupling, because the types of developers who could benefit from them aren’t a) thoughtful enough about their work to care and b) won’t read much of anything, and that instructions on a paint can to the 1979-programmer would be better in some sense, then maybe it’s more clear why it’s so out of place what Jeff is saying.
