Jeff … for the principles involved (Bob Martin, You/Joel), how about this … have the programming community come up with a project (nothing too involved, but enough to exhibit one’s programming methodology) and you guys code it (Jeff and Joel can work together since they see eye-to-eye on this). Display the finished projects on the web so that everyone can look at the code and make their own judgements about which one is better (more readable/maintainable/extensible/etc.) - even let us vote on it and show the results publicly. I think this would be better (and more educational for all involved) than these endless theoretical tiffs.
Jeff,
This is not about rules. It’s about principles. Quoting doesn’t imply understanding.
Software design principles are like having a really good sports instructor when learning and perfecting a sport. They are there to help you be the best you can and give guidance on how to improve. Can you go ice skate or wrestle without a sports trainer. Sure, but will you be as good at your craft without one, probably not. Just like you anyone can create software. But, that doesn’t make them good software developers. To be good you have practice and seek the advice of leaders of the craft (design and principles). To scoff the advice because you think it is a pain in the rear is similar to not listening to your sports instructor because the work is too hard. But, once you master those teachings they become second nature and you don’t have to keep all these rules in your head all the time and you step up your ability at your craft.
Good principles in software are like the basic rules in most religions (basically, Be nice to others, don’t steal and don’t kill). It seems to be in human nature to take such a rule and end up with the spanish inquisition. Or in our case, take things like DRY and end up with SCRUM.
@Jeff - well said.
I have seen many implementations of Agile development, or other various SDLC implementations that work wonderfully for one or two people for one or two projects. Unfortunatly it is the case that most people who develop and pick the methodologies don’t have to practice them. This decision, like most technical decisions, should be, upto, or at least made in collaboration with the developers.
Otherwise it would be like telling a construction engineer what materials he/she is allowed to build a building out of. Okay - not exactly… but anyway…
Personally I’d be had up for murder if I were put into a paired programming environment, yet other people here work better in pairs.
While I agree with the general idea these rules are good, but don’t be fundamentalist about them, I don’t see how the Single Responsibility Principle can ever be useful. It seems to be another name for the Functional Decomposition Anti-pattern ( http://sourcemaking.com/antipatterns/functional-decomposition ).
IMO, there are two reasons why you might not read the instructions on a paint can:
One, you are a child who doesn’t know any better, and you go and make a mess.
Two, you are an artist who could have written the instructions youself, and you know exactly what you are doing making up your own rules.
There are a very tiny talented minory who are born into the second category, but the rest of us need to humbly do our time following the instructions until we really understand what they mean. Anything else just holds our profession back. I think it’s a shame you can’t seem to see that, Jeff.
I never follow the rules on the paint can. I just dump the toxic contents down the drain and to hell with the consequences… let the people downstream deal with it.
Is that what we’re saying?
there’s a limit to what you can fit on a paint can
If developing SW were as easy as painting there would be no problem to find good developers, nes pa ? I think you oversimplify things here, Jeff.
As brief as the instructions on a paint can are, they do represent the upper limit of what most people will realistically read, comprehend, and derive immediate benefit from.
And you think that SW devs fall in most people, that are not concerned with details and have difficulties with comprehending hard stuff ? C’mon.
Expanding from a few guidelines on a paint can into a detailed painting manual is far riskier
You think that those painters that must paint interiors of tankers that carries special chemicals (just example) just read what’s on paint can ? There are home pet projects, demos and enterprise apps worth millions of $. You think that dev skills levels for all these are the same - just instructions on a paint can ?
Pretty soon you’ll find yourself believing that every possible situation in software development can be prescribed, if only you could come up with a sufficiently detailed set of rules
Why you give SW dev so little credit ? The majority of us IMO know how to be (self)critical, we tried a lot of different approaches and have failed enough times that we know that sometimes the answer is it depends. There is no silver bullet. And in design you always have to make decisions on sometimes contradictory parameters.
SW is too complicated that every possible situation in software development can be prescribed. But that doesn’t mean that engineering principles are worthless.
Worse yet is the idea that software engineering is monolithic. That the same set of practices should be used for developing every type of software. This is patently absurd. Software is enormously diverse, perhaps more diverse than any other engineering discipline. The most reasonable practices for engineering a cowbell app. for the iPhone are dramatically different from those for engineering youtube which are in turn dramatically different from those for engineering the software that runs the Mars rovers.
With so many rules soon we will have programmers and programming paradigm lawyers.
Principles aren’t rules nor methodology nor practices nor laws cast in stone nor bureaucracy. SOLID is anything but Ferengi Programming.
Rarely have I seen foundational teachings been twisted and misinterpreted that much as in this conversation. Bureaucracy, (bloated) rulesets, and (too many) guidelines can be made out of any sound and sensible practice. They aren’t build in from the beginning.
For crying out loud, look the word up in a wordbook: Principle comes from latin principium meaning beginning, origin, basis, fundamentals. In this context they are obvious generalizations of years of observations, distilled experience as somebody else named it. They provide a basis (not THE basis) for reasoning or a guide for conduct or procedure. A principle is not an absolute rule. A principle is a proposition stating a fact or a generalization, accepted as true and basic.
One of the basic reasons to use principles is exactly about that less is more, to avoid drowning in rules, bureaucracy, and the Ferengi mindset, because you can let yourself be guided by one principle rather than 10 rules and 117 exceptions.
Whether you like or not, everything you do is guided by some principle (good or not), otherwise your actions would be chaotic, frantic, or just plain messy. Focusing on principles rather than paradigms, features, bloated guides, is economy of rules. Once you expand your understanding of the principles, you can get around all those rules and their numerous exceptions.
Each of the SOLID principles is a proposition based on experience. You cannot dismiss experience thus easily, especially not experience from 40 years of work, including work with other experienced people. The Liskov Substitution Principle is even based on science. Do you have to accept them as truth? Of course not, but to do so without any critical thinking would be ignorant and mindless.
No matter you previous experience, you can learn from them, derive from them, and build on them. It is a matter of thinking.
The OO principles as laid out by Robert C. Martin in his online articles were my entry to thinking about design, not just design, and I’ve learnt ever since, while thinking critically about these principles, so they sure bear a lot more weight now than when I first recognised them. No bending of truth here, just expansion of context, and more experience, and better intuition for why, what, when, and how to derive from them - or not, exactly because they are principles, and nothing else.
Jeff Atwood, you are way off here, and this is mounting to distastefulness, the very least. This is less than a cheap shot.
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.
I would want to educate my engineers on the principles that are effective and applicable to their work. They are more likely to achieve quality, maintainable software if they are exposed to what that might look like!
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.
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.
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.
SOLID and unmaintainable are not mutually exclusive.
Kent Beck has also responded to some of Joel’s comments regarding unit testing and TDD:
I couldn’t agree more! Thanks for the great post.
It is so nice to see people to start coming and saying it is okay not to use the xxx best practice! I am so sick and tired of being told that I am not a professional simply because I don’t write tests! I verify the system myself and I don’t see the ROI on automating them very high at all. I do think that some of the design patterns are useful, but most of them seem to be geared towards make believe contrived examples. In the real world classes are usually 1000+ lines of code and so this myth of small objects is really quite funny to me.
Anyways, thanks for representing, what I think is the majority of programmers. These OO and TDD zealots are the loud minority IMO and are too full of themselves.
I don’t see how the Single Responsibility Principle can ever be useful. It seems to be another name for the Functional Decomposition Anti-pattern ( http://sourcemaking.com/antipatterns/functional-decomposition ).
Having only one reason to change (SRP), is not the same as having only one reason to exist (Functional Decomposition Anti-Pattern).
Another way to approach understanding SRP, is to explore Cohesion ( http://en.wikipedia.org/wiki/Cohesion_(computer_science) )
I think some of us are looking at this backwards. To paraphrase: I don’t design and code while mindlessly following the rules, but if the final product doesn’t conform to several of the rules, I know it is a bad solution.
@Dennis Decker Jensen
Jeff Atwood, you are way off here, …
And I agree.
A good post.
Unfortunately rules are something that PHB’s and organisations thrive on. From their point of view when you leave it up to discretion, you leave yourself open to uncertainty and risk. Rules are a way of mitigating uncertainty and risk. Rules keep the Morts in line.
I totally agree with what you say though. It’s better to view all advice as guidelines, and not strict rules. Sometimes you will favour some over the other, but programming has such a diverse area of application (ie pretty much anything) that it’s impossible to create the one ruleset to cover everything. Back when programming only cared about matrix multiplications in Fortran life was easier.
It’s why we all ask ‘What is the best way to do x?’. There are a few lazy people out there, but for the most part we just want to make sure we’re doing things the right way. We all want to maximize output while minimizing effort.