Having worked in and around software development most of my life, I’ve seen a lot and I’ve been responsible for a lot. Some I’ve been very proud to be responsible for and some not so proud. One of the things that we all strive for, but is not always achieved because of the pressures brought about by delivering solutions quickly or under unrealistic timeframes, is QUALITY! In this article, I’ve coined the phrase “Absolute Quality” and from a software development perspective, Absolute Quality is key to how we tackle software development.
In mentioning the term “Absolute Quality” to my staff, many mentioned the Six Sigma processes. I’d obviously heard of Six Sigma and its relevance in the manufacturing sector but I honestly never thought to look into its principles for software development. I’m not sure why; after all, as software engineers we’re simply manufacturing software solutions. But I think there’s a fundamental difference in my meaning to “Absolute Quality”, and it relates to cultural and behavioural changes in how we develop software, and not just process improvement during the manufacturing process.
I realised a long time ago that nothing is perfect, and certainly software has bugs. Perfection is not the outcome of thinking “Absolute Quality” and to me setting the quality bar at “perfect” is unrealistic. Absolute Quality is about raising the bar; raising it to heights you never expected you could reach. Implementing a way of thinking and working that dismisses the concept of “path of least resistance” and aims for “going above and beyond”.
Absolute Quality is at risk though, and I see it every day. Especially under strict deadlines and unrealistic and meaningless timeframes that are arbitrarily set to make people feeling as though they are achieving results, when all they are really doing is setting things up to fail. I worked for a very clear man once who ran a wedding function business (when I was much younger, earning extra money after hours), he said something to me that was very profound. He was constantly under pressure to reduce his price as weddings are an expensive and emotive business. He used to say, “Do you want a cheap wedding, or a good wedding, because you can’t have both.” This resonated with me because software development solutions are a bit the same. My point is, quickly delivered software solutions very rarely result in good software solutions. The principle of Absolutely Quality means we focus on what needs to be done, in the right order, not setting end dates we’ll never achieve and by setting these unrealistic end dates we’re just cheating on quality.
My product development software business, Qualitem, builds SharePoint software products. Although Qualitem is a new venture, our SharePoint products have been in the market since 2007 (via Connected Systems). Throughout the journey of building SharePoint products (or any software for the matter) it’s obvious that quality must be the highest tenant within the company – quality products must be what we deliver, whether it’s through Qualitem or Connected Systems our services business. Although this is a simple and obvious statement, what I’m really talking about is encapsulated in the phase – “Absolute Quality”.
The reason I’m speaking about quality is because it’s the one thing we tend to let drift, especially when we’re under pressure to deliver. Quality is more than just good code, it’s an attitude and something that takes adjusting to, especially if you’ve had the need cut corners to get it done on time. Too often I hear within a project, “we’re finished”, with the reality not matching the expectations of those that just don’t get what “Absolute Quality” is all about.
When I worked for Microsoft Consulting Services in the early 2000’s, it taught me a lot about what was important and how to approach software development. Tools like Microsoft Solutions Framework were extremely helpful to me and helped me understand the importance of doing the right things in the right order. This is where I learnt that quality can never be compromised. This is the diagram that encapsulated software development best.
This simple but elegant diagram taught me that no matter which of the 3 sides changed (time, features and resources/money), quality was at the centre and it never changed (it should always be at the highest level) and should never be compromised. This diagram represents our approach to software delivery. If features were fixed then time and resources had to change to accommodate the features changes. Similarly, if resources were fixed then features or resources had to change etc.
Absolute Quality means we decide to do things that make NO assumptions. We do the right things in the right order and we should not be driven by deadlines that are unachievable. An example of this is implementing support for verbose logging in our software. It’s not good enough to just cater for exception handling of errors (of course we do this), however, we must log what’s happening and even support a tracing mechanism so we can understand where the issues lie. Absolute Quality is needed with everything we do, whether it be software development, business development, marketing, support or administration, everyone must take ownership for achieving Absolute Quality.
And remember, when you’re under pressure to deliver something quickly, ask yourself (and the customer), do you want a quality systems or one delivered quickly, because chance are, you cannot get both.