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.
10 comments:
This post peripherally reminds me of this: http://jchyip.blogspot.com/2009/01/no-matter-how-many-times-you-say-it-we.html
Quality Assurance are the guys at the end of the production line, with the big sledge hammers that they use to "correct" any misaligned parts.
The people at the end of the line with sledge hammers are actually Quality Control, not Quality Assurance.
Jason, your post is brilliant as always. I have read it before. I shall use it as a great reference for explaining the different between Quality Assurance and Control. Thanks!!
Writing is the same, the only way you become a better writer is to write, a lot. Surrounding yourself with writers that are superior to yourself helps too. But like developing good software requires rigour, so does developing good technical documentation.
Having said that I appreciate and thank my QA team for being there to check that the software and documentation are both correct before we release it to customers. However having QA built into our processes doesn't mean that you can be less thorough when doing your job. I expect my bugs to pass QA all the time, and sometimes get surprised when the odd one doesn't.
I agree. There's no such thing as quality assurance. I do believe that everyone involved in the software development process should implement measures for Quality Control though (UX, Business Analysts, Developers, Project Managers...). Not just Testers. Like you say in your post, rigour is always important.
Quality of the perception of it lays in the hands of the client. Why do we keep forgeting the ultimate goal?
Thanks for the comments.
I think quality can be pursued through many software development practices and those of other roles but I don't think it can be assured.
Jason's post above is the best explanation I have seen in a long time.
As for rigour being important, I think it is everything.
I would agree that quality is almost impossible to assure, if only because the software industry is still relatively young, and still lacks the rigour of the more established disciplines (hence the wide spread in ability among, for example, programmers. I've seen far more egregious code than enlightening code).
The various processes and methodologies that we employ can definitely help us in the right direction; Agile, TDD, CI, XP and a whole host of other TLAs can help us achieve some level of quality, but it's still ultimately down to the individuals on the team, and the "togetherness" of the team (for want of a better word. I'm trying to avoid using management consultant buzzwords like "synergy").
I was interested to read this article on the lie of certainty shortly after posting; it touches on a similar theme.
Post a Comment