I think it’s been said a number of ways in the responses, but I suspect that folks aren’t recognizing that the ‘rules’ in question, are not rules, but are instead ‘principles’.
In plain techno-speak: rules != principles
The Ferengi Rules of Acquisition are not functionally equivalent to Object Oriented Design Principles.
Principles help guide and inform and are imprecise, rules are proscriptive and precise,
asdf,
Until it breaks. Or the data store being implemented works differently from how IDataStore thinks a data store should work. Then you are dooooomed to spend days figuring out the class hierarchy.
What?
First off, interfaces don’t think, they just outline a contract. So if my IDataStore interface has a void InsertCustomer(Customer customer) the XXXDataStore that implements it just needs the method. IDataStore doesn’t tell it how to do it’s job. So that point is invalid.
Secondly, how is passing in an object (IDataStore) into a class’ constructor more difficult to comprehend (by a massive magnitude apparently) than instanciating an object (XXXDataStore) in the class itself? You can’t possibly think that.
At the risk of repeating myself (agile joke), under what circumstances can a developer create a better design by not following SOLID principles?
Desmond,
I don’t do TDD (never liked it) or like Agile Development (personally, I think it’s overrated and more buzzword than substance), so I’m not a zealot.
That being said, if you can’t see the ROI on unit testing, then you are not acting like a professional. The one instance I will conceed is if you own your own company and design your code for interal uses, but if you are working for a company in a development capacity, you should be developing good code that is maintainable, that is one of the reasons they pay us the big bucks.
No matter what changes you make to existing software, you can’t be 100% confident that your changes won’t break something. But adding unit testing to your work helps you approach that 100% mark a lot better than I verify the system myself, which as an aside, is a close second to It works on my machine! in the developer lame excuse hall of fame.
A great example of this is at my previous position where we had literally dozens of applications that all remoted to a Window Service that contained the companies business logic. A change was made to an existing method (ignoring the Open/Closed Principle) that the developer though was only being used by a company website. He changed the website as well, it went passed through QA with no problems and was pushed to production. Two days later we noticed problems with something completely unrelated, it turns out that a long forgotten applications (built in Fox Pro) which used Web Service which in turn remoted to our Business Logic was no longer working.
It took days to resolve the problem and we almost received a fine from the FCC. Now, should an overworked QA department have caught this problem? Maybe, I mean, if they have to check 30 applications every time anything is changed the company couldn’t function. But proper unit tests would have caught this problem within minutes of making the change.
The moral to the store is being proactive as opposed to reactive is generally the most cost effective.
You wrote:
Expanding from a few guidelines on a paint can into a detailed painting manual is far riskier. The bigger and more grandiose the set of rules you come up with, the more severe the danger.
It puzzles me that eleven articles on how complexity can be reduced (mainly by controlling dependencies) is bad, while you choose to use a programming language that needs a 408 pages book to describe something basic as “generics”: http://tinyurl.com/dzmh4a
It is generally accepted that dividing a project into modules eases the development process. The SOLID principles simply explain how to do this in practice. If you work on a reasonable sized projec, you simply need to take care of dependencies between modules. Or you can ignore the issue and hope for the best… If you choose not to ignore the problem, the SOLID principles is a good starting point.
I wrote a comment on the podcast here: http://tinyurl.com/atvjtu
You and Joel misunderstood the intent behind The Single Responsibility Principle. The principles are not so rigid as you understand them to be.
Gewwwwgle.
@Andrew
A change was made to an existing method (ignoring the Open/Closed Principle) that the developer though was only being used by a company website. He changed the website as well, it went passed through QA with no problems and was pushed to production. Two days later we noticed problems with something completely unrelated, it turns out that a long forgotten applications (built in Fox Pro) which used Web Service which in turn remoted to our Business Logic was no longer working.
Now I think this is just the sort of situation where Jeff and Joel said that people should use unit testing. Their examples in the podcast were the .net framework and an encryption library, but a business component that many different programs depend on fits in the same category.
So many words with so little said.
Chris,
I was just commenting on Desmond’s post in particular. He took Jeff’s don’t always follow the rules to mean unit testing isn’t necessary which nobody else was saying.
If anything, we should be encouraging developers to think more about their code and abide by some sort of best practices.
The types of developers who could benefit from SOLID a) aren’t thoughtful enough about their work to care and b) won’t read much of anything.
http://www.codinghorror.com/blog/archives/001004.html
http://www.codinghorror.com/blog/archives/000635.html
This is why I’m a fan of the simpler instructions on the paint can method.
Man, you are misleading a lot of young software developers who read your blogs for advice.
If we treat young developers like they can’t think for themselves, then they won’t!
But slavishly following the no rules mantra is also a path to failure.
Is it even possible to write software with no rules? There’s always rules : Will my code compile? Will customers pay for this? Does working on this make me want to gouge my eyes out? Does what we’re building even make sense?
This decision, like most technical decisions, should be up to, or at least made in collaboration with, the developers.
Absolutely.
Well I’am very much thoughtful about my work to and I try to read as much as I can about SW development.
I’m developing SW for almost a decade and a half.
And I think that I still can benefit from SOLID principles.
Bureaucratic programming. Please. The majority of developers do not suffer from too much design patterns, or too much SOLID, or agile, or waterfall for that matter. They suffer from whipping out cowboy code in a pure chaos environment, using simplistic drag drop, data driven, vb-like techniques.
Some large organizations – I would venture to say the kind Kent Beck et al. typically consult to – are knee-deep in waterfall. Others – a dot-com startup rushing to market, for example – may suffer from the cowboy syndrome. Whether these are bad things in their respective contexts and whether they are widespread has nothing to do with whether SOLID is a good thing, as much as you’d like to make that implication.
Wow dude…!
This is serious! The stuff you’re bashing here is roughly the foundation of programming as an art form…!
Sure you might be right that one should care more about creating then to read up on rules and philosophy about creation and such, and I also think that by actually creating you will learn more about the act of creation then by reading about it and all that stuff. But when you have done your fair amount of creation and you read stuff like for instance LSP and such you will realize that if you’re breaking LSP you’re not really building SW but rather in fact MUD…!
Though when you’ve done your fair amount of creation you will realize that for instance LSP is right…! There is NO WAY to make a square inherit form a rectangle, but if you’ve done enough creation you don’t need to read it, you will know it and it’ll become a part of your autonomous nervous system. These guys though were actually smart enough to understand WHY it was right to do thinks this way instead of this way and also smart enough to put NAMES on their principles and they recognized the need to write down these findings so that those that follows their generation didn’t have to spend 20 years to acquire that knowledge…
To me here it sounds as if you’re had some serious debates with a better programmer then you who have been referring to these principles to prove you wrong and you feel an urge to prove him wrong to make yourself appear right…
SAD…!
That’s the only word I’ve got for you; SAD…!
What’s next, Alan Turing was a dork…?
You’re not a great enough developer to write about these things in the way you’re doing here, sorry… 
Jeff, how do you think we as developers improve ?
It seems that what are you saying is read few instructions and go code, and learn on your mistakes.
I agree that we all learn by doing and learn on our mistakes and get more experienced.
But, how this negates that we use what others have discovered before us ?
Please, if you do not agree on SOLID give us concrete arguments. Saying just it’s bureaucratic and sw is not developed this way is just not enough.
I find it odd that the SOLID list contains both the Liskov Substitution Principle and the Dependency Inversion Principle. The former is a hard and fast rule about how inheritance works in C++ (and most similar languages, as far as I know), and should not be violated without much thought and care. The latter is a nice way of solving a certain type of problem, but absolutely should NOT be used as a default solution – making your code more complex to add flexibility you may never need is just daft. Premature abstraction is as big a problem as premature optimization.
I think software engineering/development, whatever you want to call it is a lot like martial arts.
Jeet Kune Do was massively misunderstood… Its a fighting method - not a system that has belts/levels etc. It is about training, understanding your body studying different arts and taking what works for you and applying it. Sure, there are the basics (how to throw a punch without smashing your hand, basic blocks etc) but once you have that, you should go with the flow… Some people may be better at Western boxing, Muay Thai, Tae Kwon Do etc… Take from those arts what works for you and train in that.
Software should be the same… We should all learn the basics (syntax, Hello World etc.) and then go from there and see what works for us.
SOLID not for you? Fine. Agile not for you? Fine. Should you publicly bash something without ever REALLY working with it? Never.
I’ve seen many flash Tae Kwon Do guys talk like that and get knocked out in 10 seconds by a Muay Thai practitioner… Equally I have seen cocky Muay Thai guys taken to the floor and literally broken by Jui Jitsu guys…
What should they have done? Studied the other art for a bit, found its weaknesses and exploit them, find its strengths and harness them.
Take from things what you will, apply them and do what you do well. But don’t knock something you do not truly understand or have not walked it’s path.
I think wrapping the principles into a single acronym may just be an excellent way of getting people to go what is that? - giving them the interest to study something else and what they can take from it.
This type of discussion, or more appropriately disagreement, says a huge amount about our industry. While everyone is focused on who is right and who is wrong, I think the underlying truth is far more relevant:
http://theprogrammersparadox.blogspot.com/2009/02/maneuverability-and-sales.html
Paul.
Uncle Bob Jeff Atwood
Not saying that Bob Martin is infallible or I’m his psychophant, but
Bob’s experience is far greater than Jeff’s, so I’m more inclined to listen a bit harder to what Bob has to say.
Beyond that, I also have 20 years of experience myself and my own experience tells me taht SOLID principles aren’t as disposable as Jeff is suggesting.
Software engineering isn’t wash, rinse repeat. Actually, you need to get a few people in the room to argue the semantics of the repeat operator!
Please, take a look at:
http://www.infoq.com/presentations/principles-agile-oo-design
I think you will find his arguments persuasive… Remember that these principles are a tool. Sometimes the tool doesn’t fit the job at hand. Fine. Don’t use it.
Remember that not all of us are building a web page in the latest greatest web-framework, and we need good practices to keep our code clean. 