Attempts to define quality

So software quality can help us grow our business. Can make our customers loyal. Gives us an edge when it comes to competition.

Let's define what we mean by software quality. Software quality from the user perspective is its correctness (it does what is it supposed to), reliability (it does actually work even if we deviate from tutorial), scalability (larger inputs don't get it out of balance), completeness (models whole domain it represents, ratio of quirky NYI message boxes/produced assertions is rather small), intuitiveness (user spends more time with the program than its documentation). Software quality from developer point of interest means also readability (software can be still read after several sequences of improvements), extendibility (extension of the domain doesn't require creating of separate program), maintability (if defect is found there is no need to shut down the business).

And many other factors really. Anything what could support 'My program is better because' cause in ideological war between two geeks or sales-reps (on CRM system choice) would do.

So software quality can be described as a vector of certain aspects of quality and our overall goal (quality engineering) would be to first normalize the vector (figure out which aspects are how important) by most likely putting weights to them and then try to maximize resulting value given resources we have or are obtainable (people, time etc). Why do we need this measure which combines all aspects into one - very often quality requirements are contradictory - to speed up application you need to sacrifice readability, to increase reliability you need to sacrifice speed etc. Don't be scared in the real world this measure is most often described in sentences like: 'reliability is the most important for us' or 'it has to be the fastest processing product' which gives you (a developer) a good framework to assess where to go when the fork on the road appears. This is also the place where projects can get dead-on-arrival status right away - if you (a manager) combine two contradicting aspects together and force developers to 'accept' them - you (still the same manager) build strong foundation for failure. Not to mention sacrificing morale of developers, who (usually) have better understanding what can and what cannot be achieved together when it comes to code construction.

But back on the subject - quality seems to be a task of finding a maximum in some vertex space. When we take a closer look at any one of the aspects we find that it's characteristic is kind of monotonous - if you can apply A to improve it, and then B to improve it - overall improvement will be aggregated. That means that continuous improvement would be our method of choice. Which is a good thing as we live by continuous improvement all our lives (or at least I hope we are). Now let's think what we can be improved - it's obvious like in the old joke: code can be improved. How do we go about improving code - we need to modify something in process of its' creation or we modify it post-mortem (which is also altering process of code creation). And that's where the fun begins...