Reading The Ferengi Programmer by Jeff Atwood really made me quite concerned. Here’s clearly an opinion which to me seems not grounded in sustained experience in applying the principles and is likely poor message going out to junior programmers.
In the post the author treats SOLID principles by Bob Martin as a ruleset that programmers apply from time to time. Once you get yourself into that frame of mind it is difficult to then contest the rest of the post. I would want to re-present the same topic with a different frame of mind.
SOLID principles are principles that you learn in your early days as a designer. These are formative stages when you are honing your skills and attempting to review your designs in terms of specific checklists of items to go through as a mechanism of validating your design. But each time you apply them, you internalise a part of them, and soon in 3 or more years of regular application, their application becomes internalised and ingrained. At this stage you might even well forget that they exist, since you apply them subconsciously, day after day, time after time, and sometimes referring back to them only when debating or reviewing your designs with other designers.
The analogy to the painter is in the post referred to : Are You Following the Instructions on the Paint Can? is also quite instructive. The instructions on the paint can are for one time painters, hobbyists, amateurs etc. No experienced painter is likely to be reading them since he’s probably internalised them. But each seasoned painter would want every junior painter to learn the instructions and the costs of not following them before stepping up to deciding whether and when not to follow them. He is unlikely to teach a new painter in the making – follow the instructions that make sense.
Sure you do make tradeoffs at times in design. Most people tradeoff guidelines in all spheres. However the keyword is to understand that you are breaking a guideline and then do so explicitly knowing its costs fully well.
My big difficulty with the post is that it is an advice which may do more harm to junior programmers than good. It might encourage them to make tradeoffs before they learn the cost and implications of making the tradeoffs. And it might set themselves away from a path that requires careful and judicious application (which requires a lot of effort in the early days) and helps them internalise the principles.
I would not recommend the post I refer to to any junior and upcoming programmer. My advice is as follows. If you have grown to a stage where you are applying these rules implcitly – don’t worry, you have the experience on your side to generally make the right judgement calls and you are likely to anyway apply them under most of the cases. In such a situation, this post and the one it refers to are probably inconsequential to you. If you are at a stage where you still need to review your design with respect to the SOLID principles (or other appropriate design principles) – please take your time to apply the principles, learn if you are breaking them, understand the costs of doing so (I would recommend that involve a senior programmer / designer in the process) and then by all means make the best judgement. Principles distilled over time and experience should be adjusted preferably by those who understand the cost and implications of doing so, the rest should strive to reach that state first.
To clarify, the reason why I upfront made the statement “seems not grounded in sustained experience in applying the principles”, is that those who have internalised them hardly every feel the burden (if at all) of applying them, and are unlikely to ever ever treat it as an explicit checklist, and they seem like checklists to those who haven’t internalised them. Precisely the audience to whom you want to craft a more careful and nuanced message.
Related posts: (Automatically Generated)
Tags: bob martin, design, design principles, ood, quality, solid
A common theme that I see in the comment section of that post is as follows:
“I created tons of software w/o SOLID and the customer was happy, so that’s all that matters in the real world.”
The statement above would be laughable if it wasn’t so darn true. That is, software development is an interesting field in that there is a very large spectrum of competence. It’s almost like a pyramidal structure where for every all-star developer at the top there are two below them in skill, and two below them, etc… Sadly, at any stage software can be developed that “gets the job done and makes the customer happy”. The problem really comes in for the developers downstream who are tasked with maintenance; you know, the majority. I think Mr. Atwood is completely dismissive of these developers by preaching such a laissez-faire approach. But honestly, there is often very little that is sexy about the maintenance cycle, and he certainly wouldn’t have such a following if he chose it as the focus of his blog.
-m
While SOLID principles should be internalized, they should also be checked off. People make mistakes, and checklists help people self-evaluate and catch mistakes before they become problems.
Of course, there’s always a tradeoff. Checking against a checklist takes time. In the case of a painter, the time isn’t worth it; time spent finding and correcting the 1 in 100 paint-misuse mistake that turns a $500 painting into a $50 painting would be better spent producing another $500 painting. A mistake in one painting won’t damage your other paintings.
However, in the case of software development, catching mistakes IS worth it, even if you only make 1 mistake in 100. That could be the mistake that crashes millions of Zunes, hits your own bunker with a SCUD, takes down a space shuttle, or makes your Mars rover run in circles. Even if your code doesn’t cause such catastrophic failures as these, the cost of maintenance will certainly rise, which over a long or large project can be just as costly.
@Fogus you raise an interesting point – the customer feedback is often measured at the end of the first release, the maintenance cycle continues for a long long time thereafter.
@Imagist I am not too sure if using a checklist to evaluate ones own designs especially if one has reached a high experience level will be particularly useful. Checklists help when doing peer reviews, and alternate methods such as pair programming often bring in an ability to achieve similar intents without the same rigour. Having said that, I think the amount of rigour is a function of context of the software, and I am sure there are many contexts where explicit checklist review might be quite helpful.
@Dhananjay I agree that pair programming provides a suitable and probably less painful alternative to checklisting, but in my opinion it’s even better to have both. Even very experienced programmers are humans, and make mistakes.
Some other things to consider:
How does a programmer know if he/she is senior enough to elide checklisting? If you aren’t experienced enough to not checklist, there’s a reasonable chance that you’re also not experienced enough to know you need to checklist.
How do you form a team policy on this? Most programmers need checklisting, but many won’t do it unless they are told to, and there’s no good metric to determine who should be exempt.
How do you measure individual compliance with SOLID principles? One bad apple can spoil the bunch, and checklisting helps to expose these bad apples.
@Dhananjay Very well put. I kind of stumbled into a certain way of programming through painful lessons of difficult maintainability and hard to test code. It wasn’t until about 6 months ago that I even heard of SOLID, but as i went through it, it was almost a checklist of all the little things i’ve learned to make my life of writing and maintaining code easier. It’s not a ruleset, it’s just some really useful advice that if applied judiciously makes your life a lot simpler, imho.
I’m not familiar with SOLID, and I’m frankly skeptical of all OO consultant-speak, but I’d be very wary of adopting a stance of “I’m too smart and experienced to use a checklist”. This reminds me way too much of this study, showing how rigorous use of a “trivial” checklist by surgeons cuts surgery mortality by half:
http://www.time.com/time/health/article/0,8599,1871759,00.html
SOLID? Pffftt. I invented BFD – Brute Force Development:
http://softwareindustrialization.com/BruteForceDevelopmentBFD.aspx