In Defense of Uncle Bob and the SOLID Principles

Since blogs and podcasts are so searchable these days, I have no doubt that many novice programmers will find the material discounting the SOLID  principles and the work of one of the founders of the Agile movement.

Context:  Original published audio programFirst response by Robert MartinAttempt at clarification by Jeff AtwoodFurther backing of SOLID principles by Robert Martin.

By the blog comments on each of these, there are people with strong opinions on both sides.  I don't think it is as black and white as taking sides.

For what it is worth, I, and my company, have found the SOLID principles very beneficial for the quality of the software systems we build.  By applying them weighted against experience, systems are easy to maintain and extend. 

Lack of experience might cause someone to attempt to apply them in a dogmatic, bureacratic manner.  This would fail just as surely as any attempt made by an inexperienced programmer; however, the appropriate application of these principles is a boon to a codebase.  I have found that my more senior programmers are able to apply the principles through experience, and those who are still learning the principles can see the concrete applications of them and duplicate them. 

The results are very clear and very positive.  For instance, on our current, largest project, the codebase continues to be easy to maintain and extend weekly.  Even complex business logic is easy to break down, test and verify.  New logic can be layered on (extended) without causing lots of churn with existing code (OCP).  The application of the SRP causes our code files to be small enough to understand quickly, and interface and method names are very specific, describing the responsibility.

I am not on a crusade to change the entire industry.  That takes time, and customers still don't value success enough to ask the tough questions before hiring programmers.  Until the marketplace demands higher quality work, programmers around the world will continue getting paid for shoddy software.


Trackbacks

igorbrejc.net » Fresh Catch For February 13th Posted on 2.13.2009 at 7:01 AM

Pingback from igorbrejc.net » Fresh Catch For February 13th

Software Quality Digest - 2009-02-18 | No bug left behind Posted on 2.18.2009 at 11:04 AM

Pingback from Software Quality Digest - 2009-02-18 | No bug left behind

Comments

Steve Bohlen said on 2.13.2009 at 6:35 AM

Nothing makes me crazier than when someone (like Jeff) points to the most absurd or dogmatic implementation of a technique or pattern by someone who doesn't understand the foundational concepts behind it and says "see? it doesn't work!".

This whole thing reminds me of the consulting gig I did where the team reported to me "sure, we do CI" but when I asked to see the build server it showed failing builds going back weeks. When I asked why they said (with a straight face!) "we only worry about the build passing when its time to do a release" :D

Clearly one could look at that from the outside (as this team had done) and say "this CI thing is a waste of time" but if they properly understood the GOAL of CI rather than the mechanics of setting up a CI server then they would have realized the error caused by their ignorance. To me this whole SOLID = good or SOLID = bad is really another manifestation of this same problem: people who lack a deep understanding the REASONS for much of SOLID are routinely misinterpreting it without bothering to understand it.

Keith Bloom said on 2.13.2009 at 3:25 PM

I would like to pick up on your last comment about a lack of quality in the software industry and ask why you think this is?

I have been contemplating this for years, sometimes I think it is because the industry is still young and is forming standards but software development has had enough time now. Rob Conery spins a nice analogy with the enforcement of building codes in the building industry, enough houses fall down and legislation steps in. This doesn't make me feel good at all but in the UK the phrase "Government software project" brings either mirth of cynicism from most people.

Andy Miller said on 2.13.2009 at 6:39 PM

Jeff and Joel both said the same thing, albeit less eloquently. They both said there are appropriate applications of the SOLID principles and that many programmers apply them inappropriately.

But I guess people hear what they want to hear.

Derick Bailey said on 2.15.2009 at 2:04 PM

"customers still don't value success enough to ask the tough questions before hiring programmers. Until the marketplace demands higher quality work, programmers around the world will continue getting paid for shoddy software."

It's because of how true that statement is, I have decided to take on the problem, industry-wide. Only, I'm approaching it from the more correct perspective of changing what the customer expects. If we can educate our customers on what they can and should expect from developers, then we can fix our industry. We must provide what the customer demands. If the customer demands quality, quickly, then we will be forced to deliver it. :)

Richard said on 8.11.2009 at 1:03 AM

Joel doesn't sound like he really gets it. He's always been on the pragmatic side of pragmatic vs. idealistic but that causes him to discount a lot of great stuff because he's too busy shooting from the hip. Sometimes that causes him to change his mind.

I've used SOLID on tiny programs, but in a way that made them fantastic to extend. I don't think Joel gets it.

There are differences between principles and rules. Even the SOLID principles themselves have to be chosen between. There's a difference between not getting them, and not using them for a given problem. See 3.2: www.canonical.org/.../tao-of-programm