Tag Archives: Swiss Army Manual

What is your Software Development Religion today ? And where does the Customer fit in that ?

The Swiss Army manual says: When the map and the terrain disagree, trust the terrain. However, in software industry, there seems to be an unending effort to make sure the terrain is retrofitted so that it looks much more like the map in hand ! So, I have modified the Swiss Army saying to suit the reality in the software development community as: When the real-life and bookish process definition differs, it clearly shows you have not understood the bookish definition, and hence you must change the real-life until it looks like the bookish definition and then trust the bookish definition.

Statutory Health Warning: Reading this blog post further could be bad for health, especially for those who love the process vocabulary more than the process intent, see the means more clearly than the ends and anyday favor the established processes of the day even to solve newer class of problems that clearly require fresh thinking lest they end up shaking the establishment. Author takes no material responsibility for anyone proceeeding from this point beyond and suffering serious health problems because of the radical views presented in this blog.

The conventional definition, popular understanding and state of practice of Software Quality is seriously flawed. They have created a very lopsided perspective that adherence to certain standards is Software Quality, howsoever hard- or soft-baked those standards be. On one hand of the rather colorful spectrum are the die-hard process zealots who won’t stop short of anything less than an ISO, CMMi or the likes and on the other end of the spectrum are the neo-rebels who believe anything Waterfall is bad and unless anything is Agilized, it ain’t good enough. On the innumerable discussion boards that I subscribe and listen to, completely petrified to speak up lest be asked my credentials to back up my anti-establishment views, I find more productive hours being lost on what should be the exact definition of a ‘product owner’, what should an ‘iteration zero’ be better known as, and whether you pass the Nokia test or not. I find the neo-rebels falling in the same honeytrap that they once so detested and fought tooth and nail – compliance over creativity. I see more mail threads getting fatter and longer because there are linguistic differences that probably should be settled so that practitioner’s camp can have peace after all, but where is the Customer in all this ?

We are probably forgetting that software came first, the generic notion of Quality came much earlier and everything else is only a recent model that some wise men and women have put together – and is likely to change with time. In fact, if that doesn’t change, there is something seriously wrong. So, there is a shelf life associated with Waterfall, and there is a shelf life associated with Agile as well ! Granted that Waterfall has had a rather long-tail that simple refuses to die (much to the chagrin of agilists), and so is Agile likely to have, but the fact remains if the software community stops innovating at and after Agile, it is not just bad enough for Agile – it is bad enough for the entire industry for the wheels of innovation and continuous improvement would have come to a grinding halt. 

I believe quality is not about how much the goods or services that a manufacturer or a service provider produces confirms to requirements. They are also not about whether it is achieved using Waterfall or Agile, whether CMM or ISO, whether done in-house or oursourced, or qualified using random testing or automated testing. Quite frankly speaking, I couldn’t care less if it was done by a bunch of social misfits or comforming cousins as long as I get what I want. But in all the noise and the alphabet soup of neo-processes, I think “what customer wants” isn’t audible much these days.

So, what really is quality. Well, to me, Quality is THAT differentiator in a product or a service that

  • makes me drive a few extra miles just so that I could buy or experience something I really like even when other, relatively cheaper options are available nearby. (=sarcifice time, effort and comfort to get something I value)
  • makes me choose one over other even when, everything else being rather equal, the one I choose might be costlier but not exorbitantly priced. (= availability of other altarnatives, freedom and ability to choose what I want)
  • makes me patiently wait in a line for my turn to come (=sacrificing my comfort to get something that I believe it worth it)
  • makes me pick up a product blindfold (=blind trust, but not trust blindly; reliable everytime)
  • I can recommend to my friends and family (=what is good enough for me is good enough for people I care)”

When I view quality from this perspective, it becomes very easy to substantiate what I said earlier – who cares what process was used, where the software was written, which language was used and what metrics were collected as long as I got what I wanted ? When one is willing to take a customer-centric view of software quality like this, the choice between Waterfall or Agile is only a matter of what class of problem we are trying to solve and what is the best-proven technique to address that situation. There are no permanent ideologies nor permanent religions – you must be flexible to choose what suits the problem at hand, rather than view it from a fixed-focus lens and try to ‘retrofit’ the problem to your software development religion.

So, what is your Software Development religion today ? and where does the Customer fit in that ?

PS: This post happened in response to a question on my favorite Q&A forum – LinkedIn.