This post is a bit of a grab bag of brief thoughts on Quality.
What does it mean?
When you mention quality, people usually think immediately of high-end superlatives: The Ritz, filet mignon, Rolls Royce.
That is only a narrow concept of quality. I find it more useful to think of quality as being the best fit for purpose. After all, how useful do you think a Rolls Royce would be for delivering two tons of concrete to a muddy building site?
What is good quality in one context might be appalling in another. The trick is to understand what constitutes quality for the application you are building. Not all applications need high-end security, or hot failover redundancy, or real time transaction responses.
When is it important?
When you mention quality, most developers think of testing, and stop there. But quality should be a mind set throughout the development process.
Yes, testing code is an important part, but so is confirming the quality of other products along the way. You don't build a house without good foundations. Equally, what good is building quality code if your requirements aren't clear, or if the design is dodgy? Every step in your development process should have its own quality checks and quality assurance methods applied.
What is the purpose of testing?
This is a question I like to pose to developers when I need them to up their game.
Most will tell me that the purpose of testing is to find and correct any bugs in their code.
Wrong!
The purpose of testing, in my opinion, is to demonstrate that the code is working correctly.
It's a subtle difference in emphasis, but if you write code with that perspective in mind your attention is far more focused on getting it right than expecting others to pick up your mistakes.
Subscribe to:
Post Comments (Atom)
Posts
12 comments:
Quality...good value for the money and a product that stands the test of time.
I work in IT, and I know exactly what you mean. An app that looks beautiful, but doesn't work as advertized, or is buggy, or hard to use, is a waste of time. Aesthetics are important in software design, and quality extends to the look and feel of the app. But a good quality app will both look good, and do the job it needs to do.
After testing, I always hand over my app to a non-developer (without printed documentation). It's the only way I will know if the app is intuitive, which is what I like to achieve in my apps.
We don't compile documentation until after the intuitive testing is complete.
Quality is always context specific, no?
Excellent post, Ian - I enjoyed the last two paragraphs. Quality really is about getting it right the first time. While I am not a programmer of software, I use this model in my esthetic business whereby doing it right the first time is what I strive for.
Have a wonderful weekend - hopefully we see a little sun out there! I'm getting tired of this cold rain.
Jenny @ PEARSON REPORT
I can't argue with any of this, Ian. I'm reaching a conclusion that you write really good programming.
Another very well thought out post. :-)
I think your point about the difference in mindsets can really effect your end result is a very good one. It's something that can readily be applied to writers too, replacing the word 'beta tester' with 'editor' LoL
Delores, exactly!
Colin, glad I'm making some sense to other IT folks too :)
Diane, I'll be interested in your views on an upcoming post about training, because I think we have different views about training and intuition.
*Cowers in anticipation*
Johanna, most certainly yes :)
Jenny, I think if you are serious about quality you will naturally want to get it right. "First time" might be a bit of a stretch, but certainly get it right before handing it over to someone else.
Teresa, to be honest I would say I was only ever a moderately good programmer, but I hope I was a good software developer.
Rhonda, a lot of people are finding parallels between these posts and the writing world, and you are spot on here!
When I think "quality" I think fine cheeses. (But that's probably a given.)
I know what you mean with this programming angle though. My brothers and hubby are forever ranting about the brokeness or poor execution of code.
Ian,
Have you ever heard of a development philosophy where you design the test procedure for a function first? Then you create the function stub, run the test and verify that your function fails every one of the test criteria. At that point you write enough code in the function to pass the tests. Once it passes, you're done.
If you ever refactor the code, you already have the test written to ensure that you don't break the interface.
I would venture to add as part of the quality definition is that it contains nothing more than the minimum to get the job done. Anything beyond that is just something else to break.
--j--
Crystal, of course! I should have mentioned cheese! A nice bit of Stilton (with port) maybe?
J, I've not heard of that. I can see possible problems with all but the simplest of functions, though. Proving that your test criteria are complete and consistent will likely become as hard as writing the code in the first place.
Post a Comment