Is Quality an Absolute?
We build software so we can sell software.
One of my readers made a comment that my post was one sided. Peter’s point was that we shouldn’t subordinate quality, performance, time to market… and any other number of other software metrics… for the sake of making money. Okay… sure… but who says you have to build crap?
My point was that there are lots of teams building great software… teams that think they are doing great work… teams with great culture… defect free code… and terrific velocity… that are still not making any money. If you build crap… I doubt anyone will buy it. On the other hand… what good is high-quality software if no one uses it?
Value is about building a product of sufficient quality that people want to use.
At the end of the day… value is determined by the people who buy our products. Personally… I don’t believe there is an absolute here. We have to balance the time, cost, scope, and quality constraints to get products to market so people will give us money to keep going. At the end of the day, selling software is a prerequisite for being paid to build software.
Comments (10)
Scott Bellware
Is quality an absolute? Depends on the window within which you must achieve your goals. If it's a short window, you need the kind of quality that supports that goal. If it's a long window, you need the kind of quality that supports that goal. It's rarely 'whether quality' but 'which quality'.
Selling software is but one way to recoup value. Sometimes software is valuable when it just slows the hemorrhage of value. The directness or indirectness of the role that software plays in value informs the approach to working the software.
There's an endless landscape of crap software that people use all the time. There's an endless landscape of value squandered on software that is difficult to work. And there's an endless landscape of ineffective organizations who can suboptimize their efforts through any amount of overly-narrow perspectives on whole product development.
The problem with 'quality' is that it barely has an objective shared meaning, though 'workability' is rarely a quality that doesn't contribute to the goal.
Kevin E. Schlabach
I agree with you wholeheartedly. Unfortunately I've discovered that you can build crap and make money, sometimes more than the good stuff. That's where marketing and PR seem to come into play.
I've got a friend in the field of SEM and Internet Advertising, and he's seen guys prove that a 1 page site with junk content and mispellings on it performs better (revenue-wise) than a perfectly clean one they built first.
Sorry, that was a tangent…
I think the real meat behind your point is that whereever you are, Agile, Lean or whatever can be applied with a focus on revenue to improve your situation immensely. Without that focus, it won't be as powerful.
When people focus on delivery, quality, or satisfaction… they are simply focusing on indicators that lead to revenue. Your point seems to be… go straight to the end goal and work backwards.
Dennis Stevens
Mike,
Scope defines what you need to build to meet the needs of your customer. Quality is a function of Scope – crappy software doesn't meet the needs of the customer.
Dennis
Mike Cottmeyer
What Scott said!
Mike Cottmeyer
What Kevin said!
Mike Cottmeyer
What Dennis said!
Great comments guys!
Scott Duncan
I agree with Scott: "The problem with 'quality' is that it barely has an objective shared meaning, though 'workability' is rarely a quality that doesn't contribute to the goal."
I don't think quality can be an absolute because we cannot absolutely say what quality is divorced from the thing that does (or does not) have quality and, especially, the person(s) claiming whether it does or not.
Now I'm willing to try to apply a variety of quality "definitions" to see whether they help or not in a given circumstance. But the reason I like the Kano model (and use it in my blog/company logo) is that it suggests the continuum across which "quality" operates.
You can have more or less quality along this continuum. You can affect that by what you do. But, in the Kano model, there are three continuums and the customer gets to choose which one they believe they want to apply in a given situation:
1 – Do they believe they are dealing with a characteristic of a product that is obvious and should exist without question (or them mentioning it)? (On this continuum, you need to meet all the "expected" characteristics or the customer feels the result doesn't have, or if of low, quality.)
2 – Do they believe they are dealing with a characteristic of a product that they have specified and would expect to be present among the many others they have specified? (On this continuum, the more specified characteristics you meet the higher perception of quality the customer will have, though there is also a priority order for this continuum, not just volume.)
3 – Do they believe they are dealing with a characteristic of a product that they had not anticipated (or even imagined)? (On this continuum, any characteristics will usually produce some "delight" and a higher perception of quality.)
Naturally, the customer moves between and along these three for a given product.
Sometimes, I find myself thinking value == quality. But one can clearly argue they are different. However, it would be hard for me to believe something believed to be of high value would also be viewed as having low quality. Some characteristic of quality might be low(er), but I doubt the overall sense would be low Conversely, I cannot believe a sense of high quality could exist if the perception of value was low. Technical quality (as in low/no defects related to functionality/usability) could be there and value still be considered low, but that's not overall quality.quality.
So "absolute"? Can't imagine it being so.
Jim Highsmith
Mike, I just wrote about my view on Value & Quality, two corners of the Agile Triangle. The value corner emphasizes current value while the quality corner emphasizes continuous value. Quality enables future value.
Bob MacNeal
I have two observations to add to the excellent discussion.
1. Often teams are faced with a choice: more features or higher quality (e.g., refactoring, paying down technical debt, bug fixes).
2. Often that choice (more features or higher quality) is determined by whether your're a start-up or you’re supporting an established, public facing product.
On the start-up front:
Eric Ries (cf. http://startuplessonslearned.blogspot.com/2009/08/minimum-viable-product-guide.html) and Kent Beck wrote about Minimum Viable Product or MVP (cf.
http://www.threeriversinstitute.org/blog/?p=333) to describe a product created to elicit feedback. MVP is used to answer critical start-up type unknowns sooner rather than later. Presumably quality is sacrificed in this case to get answers for investors.
On the established, public facing product front:
Anna Forss wrote about giving bugs business value (cf. http://annaforss.wordpress.com/2009/07/24/what-value-does-bug-fixing-have-for-sales/). Anna said that bugs create more detractors than features create promoters. If you subtract the detractors from the promoters you have customer value. Presumably quality (user experience issues and bug fixes) provides real value; in some cases more than new features.
Given the appropriate context, I agree in both cases with the balance of expedience vs. quality.
Ultimately I'm with Mike when he says "selling software is a prerequisite for being paid to build software"