Interesting time for a post like this, because it comes at a relevant time as I am learning the adapter design pattern, which constitutes my first real foray into these things. Anyways, my thoughts on the matter are that for rules and principles, it’s my opinion that you should follow them strictly at first, and then modify them as need be. They serve as a good starting point, but inevitably, in trying to apply them, you will modify or discard some or all. Eventually, you’ll gain enough experience to know when a rule is applicable.
Good programmers know the rules, and when to break them, and, therefore, say I need no damn rules!.
Crappy programmers see the good programmers saying that and just repeat them, skipping the first 2 steps.
While you don’t explicitly say that what you’re saying is meant to be in opposition to what Bob Martin is saying, it’s implied. If you intended that, then you’ve probably never seen Bob speak or read his writing aside from those principles. Yes, he advocates remembering these principles and taking them into account, but that’s a small part of what he advocates. The primary thing he advocates, by far, is taking responsibility for your choices and working in a professional manner. That’s exactly what he’s all about. The SOLID principles, etc., are just a way to help remember how to do that (in the context of object-oriented design), but I think Bob would have nothing but contempt for the idea that they could replace independent thought.
(Help! The two developers who’ve inspired me more than anyone – Bob Martin and Joel Spolsky – are fighting! What am I to do?)
While I agree with Jeff’s overall points in regards to methodology, I don’t think OO design principles constitute a methodology. Like the instructions on the paint can, the OO principles are applicable and correct most of the time. The trick is having the experience to know when they do not apply, and that is often just a question of granularity (don’t sweat the small stuff) and cost (don’t build a Ferrari where a Chevy will do).
I don’t think it’s helpful to set everything up as a false dichotomy – You either follow these principles to the letter, or ignore them! That’s just not the way the world works, but I guess it makes for more exciting blogs and podcasts. 
I have to get a chuckle when I hear we follow the foo principle of software design.
IMHO, software engineering isn’t wash, rinse repeat.
It’s funny to me that until I finished I pictured the Ferengi Programmer as the good thing to be. I was thinking that he would be an example of having rules and concepts that are generally helpful ideas but feeling free to ignore or tweak them if your experience and knowledge says it’s for the best.
This post perfectly illustrates the danger (yes Jeff, you are the most dangerous blogger on the Internets ;)) of blogging. That is, the SOLID principles are constructed in such a way to minimize many common pitfalls of software development. They help to form a guideline for building robust, easily extensible, and maintainable code that are all but proven to work toward these ends. However, as is usually the case, a blogger can come along, dispense some anecdotal perspective, and effectively nullify everything that makes SOLID, well, solid.
-m
aargh.
I find lists of programming rules very helpful, but I don’t actually use them.
So what does that mean? Reading and trying to understand them is helpful because it helps me distill lessons from my actual experience. It helps to crystallize and consolidate concepts I already know, but may know only vaguely and can’t articulate.
I also enjoy revisiting some of my favorite rule sources – Code Complete being a prime example – from time to time, because the experience acquired since the last reading will always make a few previously overlooked principles jump out and shout.
But actively using them … that’s foolish, I think. No set of rules can capture the infinite landscape of constraints and trade-offs in every real project. Navigating that landscape takes experience, flexibility, and some ability, not mindless adherence to some mantra. And those mantras are absolutely useless to novices; rules and methodologies are incomprehensibly abstract without actual experience to ground them.
Jeff, I generally like and agree with what you say. On this, unit tests, and TDD you and Joel are completely off base.
SOLID is not laws. SOLID is a set of guidelines that you should be mostly following anyways, even if you don’t subscribe to the latest fads in the agile community.
TDD is not about quality, that is just a pleasant side effect. TDD is about creating loosely coupled architectures, and prooving your assumptions before going off and writing massive amounts of code.
It is really easy to build straw men with this stuff, and I am not going to do that (although Joel did when he went off on TDD not that long ago). However I think you genuinely don’t understand what you are talking about
Oh boy did I agree with the comments you and Joel made. One of you used the word bureaucracy, and I thought that perfectly expressed the misguidedness of SOLID. Bureaucracy is not inherently bad. I actually like a certain amount of administrative fussiness. Bureaucracy becomes bad when its starts inflating itself for its own sake and becomes an exercise in micromanagement, the illusion of control, and (if you’ll pardon the expression) a bunch of mental masturbation.
I keep thinking of things to write about this, and coming back to one thing. Aargh.
Hmmmm, perhaps the comments themselves are more interesting than their content?
That so many people can make reasonable arguments on either side, implies that the target of those arguments is subjective.
Engineering, if it is nothing else, is a quantitative, objective approach to consistently building something. Art is subjective, science is not.
That leaves these comments as a testament to knowing how ‘little’ we know about actually consistently building software. Any group of professionals that is this highly polarized over basic issues barely belongs to anything that could (or should) be called a profession.
Paul.
Could someone who actually agrees with this forum post, please give a non-trivial example of how not adhering to any of the SOLID principles leads to a better design?
A VERY good article!!, thank you for your insight. I really feel a sense of relief.
regards
When ENIAC was designed John von Numan used serial architecture for the bus.
Before the machine’s bus was constructed he came up with the parallel architecture.
He realized that the machine would be far faster and cost less to construct if they switched the design from serial to parallel.
So, Johnny boy went to the Army with the proposal (ENIAC was built during war time under Army control).
The two star sitting there picked up the original (serial) spec book and showed it to von Numan stating that ‘we are building this thing to spec’.
Bottom line: ENIAC was finished in time to make a significant impact on the war (atom bomb calculations among others) but if they had listened to von Numan it would have been finished sooner, at lower cost and ran faster.
So much for the rules…
In all fairness to the Army it was war time and they were greatly worried about Nazi Germany’s progress on atomic weapons. Even though (unkown to them) the German scientist were so afraid of Hitler that they would not dare propose building an atomic device because the lead time was multi-year and Hitler had a very nasty habit of having people shot for being late on a project…
So what does this have to do with rules?
Too strict an eforcement of rules results in:
a. Low or no creativity
b. In extreme cases (such as the German scientists) no attempt at creativity what so ever (can you blame them?).
Good thing for us…
In that instance strict rule enforcement saved the world!
@Just wow:
Could someone who actually agrees with this forum post, please give a non-trivial example of how not adhering to any of the SOLID principles leads to a better design?
Yes: when a challenging project with specific requirements needs to be completed on deadline by a team of limited experience. In other words, the real world.
There’s nothing wrong with the SOLID principles; they make sense to me. But I’ve been programming since the days of card readers and teletypes. They WON’T make sense to those with little experience. They don’t know when or how to apply them appropriately. They get bogged down in the attempt.
So trying to follow them changes the focus from result to process. And that’s deadly.
It’s the job of the lead programmer or manager to see that good principles are followed, perhaps by guiding others invisibly, without explicitly mandating or even mentioning those principles.
Programming is bringing fluctuations to the discret all-or-nothing world of computation.
That is, the SOLID principles are constructed in such a way to minimize many common pitfalls of software development.
This reminds me of something Paul Graham wrote:
One of the differences between big companies and startups is that big companies tend to have developed procedures to protect themselves against mistakes. A startup walks like a toddler, bashing into things and falling over all the time. A big company is more deliberate.
The gradual accumulation of checks in an organization is a kind of learning, based on disasters that have happened to it or others like it. . . . It’s natural for organizations to learn from mistakes. The problem is, people who propose new checks almost never consider that the check itself has a cost.
http://paulgraham.com/artistsship.html
The principles of SOLID or any big M Methodology are intended to prevent people from making mistakes. The problem arises because the cost of preventing these mistakes often exceeds the cost of the mistakes themselves. Unfortunately, corporations seem to love this sort of penny wise, pound foolish thinking.
Reminds me a lot of Eric S. Raymond’s excellent rules for Unix programming (except Eric’s aren’t teh suck). I’m not a Unix guy at all, but I keep them posted on the wall of my cube. I like how there are 17 of them, too. He didn’t feel the need to make up 3 more just to have an even twenty. Anyway, here they are:
-
Rule of Modularity: Write simple parts connected by clean interfaces.
-
Rule of Clarity: Clarity is better than cleverness.
-
Rule of Composition: Design programs to be connected to other programs.
-
Rule of Separation: Separate policy from mechanism; separate interfaces from engines.
-
Rule of Simplicity: Design for simplicity; add complexity only where you must.
-
Rule of Parsimony: Write a big program only when it is clear by demonstration that nothing else will do.
-
Rule of Transparency: Design for visibility to make inspection and debugging easier.
-
Rule of Robustness: Robustness is the child of transparency and simplicity.
-
Rule of Representation: Fold knowledge into data so program logic can be stupid and robust.
-
Rule of Least Surprise: In interface design, always do the least surprising thing.
-
Rule of Silence: When a program has nothing surprising to say, it should say nothing.
-
Rule of Repair: When you must fail, fail noisily and as soon as possible.
-
Rule of Economy: Programmer time is expensive; conserve it in preference to machine time.
-
Rule of Generation: Avoid hand-hacking; write programs to write programs when you can.
-
Rule of Optimization: Prototype before polishing. Get it working before you optimize it.
-
Rule of Diversity: Distrust all claims for “one true way”.
-
Rule of Extensibility: Design for the future, because it will be here sooner than you think.