Sunday, 4 September 2011
Quality Assurance is a myth
Anyone who stands before you and tells you that they can assure quality in your application is talking rubbish.
There is no way to achieve assured quality. Quality can not be assured. I was taught this by some of the best QAs in the world. Let me explain to you what they explained to me.
The first thing that people seem to tout when they instigate continuous integration, X driven development or employ a QA is that they can now assure quality in everything they build.
Let me break the truth to you. There is absolutely no way of ASSURING quality in anything you build. Ask the guy who forgot to used the metric system and caused the Mars Orbiter to crash. NASA has the strictest of all environments to assure there are no mistakes.
The way I build software is to ensure rigour. To ensure that the practices that are used in managing a team, gathering and expressing requirements, writing the code and meeting the acceptance criteria are so engrained and bought in to that quality emerges.
People speak of methodologies. I speak of rigour.
People speak of best practices. I speak of rigour.
People speak of theory and practice. I speak of rigour.
There is a distance between the project management focused Scrum and developer focused XP. Companies can sell you their flavour of this and that but the truth is that you need to find the way that works best for you.
Find that way. Find the practices and methods that bring the benefits to you and your company. Hold on to them and repeat them. Do them over and over in small sprints or iterations or bursts or waves. I don't care what you call them. Just find them and correct them as you travel. Allow yourself to be wrong and fail as long as you learn from it.
It's not rocket surgery. Consultants try to tell you it is. It's not. Good software can be built in a way that allows quality to emerge. It is a craft and as such must be built by craftsman.
Companies try to undervalue the craftsman and sell their solution. The reason is because they know that software is a true craft and it must be taught by a master craftsman to a novice. Great software takes great individuals. It takes guidance and a honing of skills. It does not come from big M methodologies or style focused companies.
If you want to build good quality software then find a very good craftsman and let them build a team. Let them teach the team. Let them guide your progress. Close your eyes and take a leap of faith. You will be rewarded.
Quality comes from great team work. Great practices. Rigour. Craft. Buy in. Pride in product.
This is why it seems random. You are looking for the wrong patterns. Find a great lead who enables and cares and you will build bliss.
Apple started a user experience trend many iOSes ago when it accepted Settings changes and did not ask for confirmation. Once the chang...
Five years ago, everybody seemed to want to have the word "architect" in their title. Firstly, they all needed a title and having...
After posting a quick how-to about Ruby-LDAP , I received a couple of very helpful comments that pointed me towards ruby-net-ldap . This is ...
It seems that the tools I take for granted are not used by all. This is the first in a series of posts where I will be sharing some of ...