For those who are still unaware of the Quality and Testing discussion, I would refer you to the first half of Do you wanna be the Picasso of programming? First learn the rules, and only after break them to first come upto speed on the events.

Subsequently Jeff Atwood wrote Real Ultimate Programming Power and I posted a comment on it which compared the issue to that related to fitness (search for fitness to reach my comment). Thats what also made me realise that if one really looked at the entire discussion as one between Happiness and Fitness, it just seemed so much easier to understand and comprehend.

So if one goes back to the first podcast #38 where Joel appears to take on software quality, and if one takes up an analogy where software usability and customer satisfaction are treated as happiness (of the software) and the quality is considered as fitness (again of the software) then what Jeff and Joel seem to be primarily saying is that (words are entirely mine)

In the overall scheme of things happiness is more important than fitness.

That would make a lot of sense that most would readily agree to. However one more statement in there says

Fitness doesn't matter so much

And thats what probably triggered off a whole bunch of reactions. It also seemed to offer an explanation of why there was such a storm raised.

The way I perceive it, Jeff and Joel were making an argument for happiness which probably would’ve gone unnoticed but for the fact that the portrayal of fitness was (if I may say so) a bit incendiary. It wasn’t so wrong as that it simply seemed to be sending out a completely wrong message. And if this was an opinion on some small blog it would still have gone unnoticed. But Jeff and Joel being the influential voices that they are were less than likely to be ignored especially when the message they were sending out was considered “dangerous” by the fitness community. Dangerous in the sense that it could lead to a whole bunch of people treat fitness with even lesser importance (especially in the context where general fitness levels were quite suspect). As I revisited the podcasts and the blog posts, the happiness / fitness analogy seemed to generally hold up.

This paragraph is a little speculative in the sense I don’t know that this is what actually happened and am speculating at my end. So Joe n Jeff got a little flustered about the fact that they couldn’t understand why they had kicked up a storm in the first place since they believed in what they had said about happiness. So they got together with Uncle Bob to sort things out in a subsequent podcast. To me it seemed like a rather uneasy and tepid podcast where they didn’t disagree with each other’s points of view but still continued to be uncomfortable with them. The multiple axes that were being referred to could’ve been happiness and fitness. Jeff still continued to defend their stance in a manner which perhaps only made matters worse. The Ferengi Programmer seemed to suggest that fitness regimens were bureaucratic steps (which cast them in a negative light) which were rather expensive to deal with and hence negotiable. The Real Ultimate Programming Power seemed to suggest that since most people wouldn’t worry about reading up on or attempting for better fitness, probably a much simpler set of rules along with a continuous thought to be more fit was what was really important.

I am convinced when I look at things in this perspective Jeff and Joel’s arguments make sense as do Uncle Bob’s. In my mind many of the differences can also be explained reasonably well by this analogy. It also explains why some of the statements seemed to invite so much ire. The issue probably lay in packaging of the arguments. If the statements are re-presented in a manner which does not seem to reduce the importance or desirability of fitness per se while continuing to emphasise the primary goal of happiness, it could be possible to close the discussion and move beyond the debate back into the real issues related to happiness and fitness, oops customer satisfaction and code quality.

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.