@Jeff R
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.
You have it backwards. If you study the Dreyfus model:
a href=http://pragmaticstudio.com/dreyfushttp://pragmaticstudio.com/dreyfus/a
that Jeff used to justify his post then you would know that beginners or those with little experience need a recipe and rules to follow so they can start their journey to becoming experts. In short, it actually makes perfect sense to introduce the SOLID principle design rules to beginners and this is also backed up by numerous studies. It’s important to also note that the rules are meaningless unless they are also accompanied by a goal.
Oops entered the comment without entering orange and the blog software clobbered the link when it tried to translate it to HTML.
http://pragmaticstudio.com/dreyfus
Let’s face it, it’s not like learning the individual principles of SOLID is difficult, they’re easy simple guidelines. Let’s take your real world example for a second, if a manager spent a grand total of 5 minutes with his/her team of limited experience programmers he/she could easily teach them one of the principles, say Dependency Injection, how is that a hard?
I completely disagree there. They are NOT easy, they are VERY abstract. You and I understand them because of lots of experience. Most of them won’t make a dime’s worth of sense to novices. And yes, they are hard to teach. 5 minutes? More like 5 years!
Why do I say this? Been there, done that. I started programming in the early 70’s. Still do it frequently. Still learning new stuff every day. But have spent as much time in the last 20 years or so managing others, starting businesses that require developers, and occasionally teaching. The issue of how to get real work done with inexperienced hires is not a theoretical exercise to me – it’s a continuing challenge that affects me personally, including how many dollars are in my pocket!
But the qualifying word in this argument is inexperienced. Those who understand the principles on first reading already understood them BEFORE reading them, at least intuitively – and that’s due to experience.
So, it’s ironic: the rules, formulated by the experienced to help the inexperienced, are really only understandable by those who don’t explicitly need them!
I’m disagreeing with the idea that these rule lists, sets of principles, methodologies, etc. are appropriate to feed to novices, not with the rules themselves.
Later you wrote:
An IT manager’s job is very similar. If a programmer has limited experience, you teach them how to code the right way. It might not help you on a current project that is already a big ball of mud, but it will help on future projects. That is what teaching (or coaching) is all about.
I completely agree with that. The important thing is to have that manager, coach – somebody who know the ropes – there to do the guiding and teaching, rather than expecting newbies to figure it out on their own by mandating a bunch of generalized, abstract rules.
Right, software is not like manufacturing. It has more in common with building architecture, which has a set of principles that architects use in most cases.
I think this is the mistake that Jeff is making, confusing Principles and Rules. If as a discipline we can’t say we have Principles that guide how we do our craft then how do we even talk about what it means to be a good developer. How do you judge a good developer? Just because some geek can hack a linked list doesn’t mean anything. But Principles aren’t rules. Principles are guding lights. Rules are rigid do’s and don’ts. If you go against a Principle, there is a high liklihood you are wrong, but there are cases… If you go against a rule, if it really is a rule, you are always wrong.
The SOLID principles have been discovered over many years of collective developer experience. It makes no difference to me that the best programmers of the 50’s and 60’s didn’t have these principles. I don’t use punch cards. I use C# or java, or python. Would a building architect ever speak of architectural design principles as bureaucratic? Would you hire one that did? He might be able to satisfy you once, but how reliable will that architect be ignoring all the principles of his craft?
But, they are principles, and when I have good reason to, I go against them. I don’t need good reason to go with them, but I do need good reason to violate them.
They are NOT easy, they are VERY abstract. You and I understand them because of lots of experience. Most of them won’t make a dime’s worth of sense to novices.
Exactly. Beginners should focus on things like which data structures to use when, basic algorithmic ideas, and how to use revision control and development tools effectively.
How many applications are going to require a pure interface anyway? Seriously, it seems like every Java developer goes through a stage where everything is an interface. Until they realize that’s not necessary 99% of the time.
These are good best practices to know and understand. But I don’t think they are beginner concepts in the slightest.
Coaching on a play-by-play basis is just micormanagement to the nth degree, and in any sort of long run will fail. If a ball is hit to deep right field, my right fielder needs to know where the cut off man is going to be standing and the cut off man needs to know that with a man on second, he’s going to have to get that ball to home ASAP to have a chance to get that runner at the plate. Coaching this on the fly will result in failure 99% of the time, having your players know what to do at least gives you a chance for success.
By the way, I agree with you there and understand the point. I think what you’ve done there is flesh out my skeletal analogy with more nuance. In other words, you overturned my generalized rule with a specific, real-world counterexample! Which is another reason to not slavishly follow rules – they’re too brittle and lacking in nuance to apply all the time, but others here have made that point well already.
My opinion on this topic is:
Rules are good only if they tell people what NOT to do and also explain WHY NOT. They are bad if they try to tell people WHAT to do or HOW to do it.
If rules tell me what I must do (or how I must do it), they take away my freedom more than anything else. They pretend I’m a stupid moron, incapable of making my own decisions. They force me to do something or do it in a certain way, even though every fiber of my body may tell me it’s wrong, just plain wrong.
On the other hand, rules that tell me not to do something may sometimes be necessary. Laws work like that most of the time. Or at least they should work like that. Most laws don’t tell you what to do (though these exist as well), but they make up a very long list of things you must not do. Of course this limits your freedom as well, but if a rule says Don’t do it that way …, it still leaves me the freedom to go for any other way I want, as long as its not that way. This is much more freedom than saying Do it exactly that way …, which leaves me no freedom at all.
And finally, a rule without a justification is just harassment. If I ask somebody Why shouldn’t I do that? and the reply is Don’t ask stupid questions, just don’t do it, okay?. Then this is no reply and the rule is bullshit in my eyes. I can understand why there is speed limit on streets that are in the middle of a residential subdivision or pass a school or kindergarten. It makes sense to put a speed limit there for all kind of reasons. A road that goes somewhere through the middle of nowhere, is absolutely straight, you can see 2 miles in every direction, it has hardly any traffic, no woods, no animals, but it has a very restrictive speed limit - bullshit. There is no justification for it. Leave it up to the driver to judge the situation: Taking into account his driver skills, the condition of his car, the weather, etc. he should be able to make a reasonable decision on how fast one can go and if goes to fast and dies in an accident that could have been avoided at lower speed, well, things like this happen. You can’t put the whole world into cotton to prevent that anybody will ever die again because he made a mistake. People make mistakes and some are fatal.
Mistakes in software development are rarely fatal, so it is okay to allow people to make mistakes. Just set up rules if you can justify them, if you can explain why somebody should not do something when getting asked. If this justification is sound, the person will understand it and won’t have an issue following that rule.
I completely disagree there. They are NOT easy, they are VERY abstract. You and I understand them because of lots of experience. Most of them won’t make a dime’s worth of sense to novices. And yes, they are hard to teach. 5 minutes? More like 5 years!
Come on now, you’re just being silly at this point. 5 years to understand one principle of SOLID?
There are some horrible developers out there, and since the IT industry pays so well, I’m sure that will never stop. So I will freely admit that there are people out there who are practically unteachable. But how often do you give important new development to those people? Almost never.
A lot of development these days is maitaning and enchancing existing applications. If an application was designed right in the first place, it’s actually very easy for any developer to follow the existing structure. They don’t even need to know why they are passing in IDataStore in the constructor of a class, just that it’s the way it’s done. Doing it differently would actually be more difficult, so they could churn out good code all day long and not even know it, throw in a code review here and there, and they might even learn something.
@jeff
I think this is the mistake that Jeff is making, confusing Principles and Rules.
I don’t think that Jeff is the one making this mistake. An awful lot people, especially novice coders and clueless managers, latch onto the rules of some Methodology and treat them as holy writ, even if the Methodology calls them guidelines or principles. This is the problem with Methodologies. People with little experience tend treat them as hard and fast rules, while people with enough experience to treat them as guidelines are usually experienced enough to do the right thing without having to consult the Methodology.
The irony being… rule questions make up a huge portion of the stackoverflow site.
My beef with rules or best practices is, is that some people may read about a best practice, (a square), and then fit that best practice into their task at hand (a circle).
Young Mr Atwood,
You say:
When Ron says there is an absolute minimum of practice that must be in for an agile project to succeed, I want to reply that I believe there is an absolute minimum of practice needed to have a competent opinion about things that are needed – and that in his post he does not achieve that minimum.
Ron Jeffries is hugely more experienced than you at this stuff:
http://en.wikipedia.org/wiki/Ron_Jeffries
I’ve conversed (on a mailing list) with the man, and he really does know his onions.
On the other hand, there are a few people who come out of the woodwork every time some sort of software engineering topic is mentioned. In particular, things like the SOLID principles and design patterns and so on get them all hot and bothered.
If anybody doesn’t think those things are worthwhile, then what they’re really saying is that it is possible to write good code without understanding what good code is. Be a bit of a fluke if they did, IMO.
I used to wonder how people could possibly object to this stuff (although I’ve seen enough poor code to know that not many people take any notice of it).
Then I read about the Dreyfuss model, and that seemed to be a possible explanation. Have a read of chapter 2 of Pragmatic Thinking and Learning, then read Jeff’s blog and the comments, and see what you think. I reckon the second-hand incompetence stamp could be used fairly freely 
It’s kind of worrying thinking about your self image, too, after that chapter.
To those who have a problem, I would say that these things really do only seem prescriptive up to a certain level of skill. Beyond that point, they become more internalised and intuitive. Eventually you may move beyond them and become a thought leader yourself (although don’t expect many of us - myself included - will ever be that).
Personally, for some years I’ve used questions about these topics to sort out who to employ. I don’t care if someone can write a regex off the top of their head. I do care whether they can write, or have the potential to write, good code*. To me, that means they have to have thought about how to do that.
*Actually, now that I think about it, being able to write a regex off the top of your head might be a strong contraindication
Odd to hear Bob Martin’s SOLID railed against as if it were a Methodology (big-M). I have been around for a while, and there were originally over 11 important principles (and no methodology, by the way). Here is a promotion of the five most design-oriented principles, and explanations of how they work… and so this is a Big-M Methodology with a lot of subrules and strictures and creativity-killing, brain-numbing requirements?
Mind you, there is an agile methodology, but it basically boils down to test your stuff as you write it, have short iterations, work together, and keep track. It even includes ‘retrospectives’, whose entire purpose is to let the team choose how it is going to work together. I lived through SDLCs and RUPs and Structured and you-name-it. Agile is the anti-methodology.
This whole series of strawman-bashing posts here is too silly to swallow.
I feel the exact opposite to be honest. Knowing what structure to use, how to connect to a database, the difference between an Abstract Class and an Interface, etc. (you know, the basic interview questions people as developers) are all available on google.
Give me an inexperienced young developer right out of college who understands how to build an application over an experienced developer who is responsible for developing horrible, unmaintainable applications any time.
Your mother is a Ferengi!
I regard OO rules as a dictionary of terms for explaining what I’m doing.
@Jim Cooper
The text you quoted isn’t by Jeff Atwood, it’s from a blog entry by James Bach (http://www.satisfice.com/blog/archives/174) that Jeff is quoting.
Better design is better design.
If in your real life your real boss tells you to make it fast and ugly, or you have any other reason to sell better design for something else - do it. That does not make better design worse.
If you do not understand how to make better design, it does not make it worse. If you can not get benefit from better design - it does not make it worse.
For me those principles are just to know them and do what I think is appropriate. Very often I think following them is a good idea. Following them blindly is like following any rule blindly.
Actually SOLID is not that hard. It does not take much time to extract interface for client. It does not take much effort to depend on abstraction, etc. And it gives you fine grained control over your code, which I think is very agile.
If you know someone who reads the book and immediately follows everything in it without any doubt - I hope that’s a girl I know few good principles for her.
I’ve never thought about any book as something that limits my freedom to develop software how I think it should be developed. And for junior who thinks that everything in his program needs to be in one static method of one class - those principles are a good start to try thinking in different way. That’s what books are for, to let you think in different way.