My first thoughts about software quality
First time I thought about software quality was in my first agile project, a few years ago in Globant. I remember a message on the blackboard that said: "Quality is not negotiable". Back there, I didn't know much about agile, but I was impressed with all the good engineering practices that we were following in a very disciplined way. Now, having read a few more books, I could say that we were doing XP. My interpretation of the message at that moment was: We are not going to abandon any good engineer practice due to time constraints, because the consequences of doing so would be worse. In other words, even if it takes more time to do automated tests for all features, refactor every time we felt we need to, do pair programming, code reviews, etc we are going to do it because at the end, it pays off.
Different definitions of software quality
So what is software quality? Years have passed, books have been read and the definition is still vague for me (and looking at the forums, it is still a topic of heated debate).
Juran's definition is "Quality is fitness for use". But for use by who? Juran specified that the customers should be identified and their needs determined.
Crosby's definition is "Quality is conformance to requirements". The problem with this definition is "who creates the requirements?" (i.e. those requirements attend the needs of all users?)
The Poppendieck's make a separation of quality in production and quality in development. According to them, Juran's definition corresponds to quality in development and Crossby's to quality in production. Other differences are "variable results are good" in quality in development, but bad in production quality and "Iteration generates value" in quality in development, while it generates waste in production.
Quality in software development results in both "perceived and conceptual integrity". Perceived integrity means the products attains "a balance of function, usability, reliability and economy that delights the user". Conceptual Integrity means that "the system's central concepts work together as a smooth, cohesive whole".
Weinberg's definition is "Quality is value to some person". This definition acknowledges that quality may mean different things for different persons (i.e. quality is relative).
For example:
- Quality is Zero Defects for people that are disturbed by those defects
- Quality is having a lot of features for people that use them
- Quality is elegant coding for developers that appreciate that
- Quality is high performance to users whose work taxes the capacity of their machines
- Quality is low development to managers with low budgets
- Quality is rapid development to users who are waiting for the software or to marketers that want to sell it
- Quality is user friendliness to users who spend 8 hours a day in front of the software
Weinberg's reckons that the definition of quality is political and emotional, because it "involves a series of decisions about whose decisions count, and how much they count relative to one another"
Quality that can be measured versus Subjective Quality
A lot of the quality definitions are very subjective. Value to a person.. Fitness for use.. How can we measure that? (I guess the best measurement is how well the product sells). On the other hands, there are things that can be measured. For example, CMMI approach, in its levels 4 and 5 try to measure quality using statistical analysis.... But does that assures a satisfied customer? In Agile, certain measurements can be taken, for example how many tests there are, the code coverage. Do those number assure that the tests are well written?
Open Questions
- Can we divide Internal and External Quality? The Poppendieck's talk about perceived (external) and conceptual (internal) integrity. Marick, in his testing quadrants also specifies that some quadrants aim at internal quality while some others to external. Does it make any sense to make this separation? I know you cannot have external quality without internal quality. However, it could be entirely possible to develop an excellent product that doesn't provide any value to the customer (so external quality implies internal quality, but not viceversa).
- Weinberg's definition brings other dimensions to my current ideas. For example, that rapid development or time to market can be considered as quality attributes.This is not intuitive to me. I understand that having a product in a couple of weeks has a lot of value for some persons, but if that product is bad programmed, without tests (etc.!) I wouldn't consider it a quality product.
Conclusion
The definition is still vague to me. However, to think a little bit about quality made me realize that most of the Agile values and principles aim at improving it. For example, short iterations and user involvement improve the value to the user because something nearer to what is expected is built. Engineering practices like automated testing, refactoring and continous integration improve the conceptual integrity and thus the perceived one. In other words, Agile tries to maximize the quality - value - at the least possible cost.
No comments:
Post a Comment