Comments on: An experienced programmer doesn’t use SOLID as a checklist – he internalises it.

By: Mitch

Mitch — Fri, 13 Feb 2009 00:24:16 +0000

SOLID? Pffftt. I invented BFD – Brute Force Development:

http://softwareindustrialization.com/BruteForceDevelopmentBFD.aspx

By: Mike

Mike — Thu, 12 Feb 2009 19:01:44 +0000

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

By: Arne Claassen

Arne Claassen — Thu, 12 Feb 2009 17:08:35 +0000

@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.

By: Imagist

Imagist — Thu, 12 Feb 2009 16:50:15 +0000

@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.

By: Dhananjay Nene

Dhananjay Nene — Thu, 12 Feb 2009 16:02:23 +0000

@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.

By: Dhananjay Nene

Dhananjay Nene — Thu, 12 Feb 2009 15:58:30 +0000

@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.

By: Imagist

Imagist — Thu, 12 Feb 2009 15:50:38 +0000

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.

By: Fogus

Fogus — Thu, 12 Feb 2009 14:29:10 +0000

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

By: Ferengi Programmer and the Dreyfus Model at Mark Needham

Ferengi Programmer and the Dreyfus Model at Mark Needham — Thu, 12 Feb 2009 14:03:39 +0000

[...] these levels at which any person may be at for a given set of skills, as Dhananjay Nene points out someone who is an expert in this area is not going to be referring to a checklist of design [...]