Comments on: Quality is a bogus variable http://niksilver.com/2006/09/26/quality-is-a-bogus-variable/ Mostly about the management of software development Wed, 27 Jan 2010 09:48:25 +0000 http://wordpress.org/?v=2.8.4 hourly 1 By: Fast, Cheap, Good « Said Svec http://niksilver.com/2006/09/26/quality-is-a-bogus-variable/comment-page-1/#comment-55 Fast, Cheap, Good « Said Svec Sat, 30 Sep 2006 18:07:06 +0000 http://niksilver.com/2006/09/26/quality-is-a-bogus-variable/#comment-55 [...] Edit: Niksilver.com has some interesting comments on “good”. [...] [...] Edit: Niksilver.com has some interesting comments on “good”. [...]

]]> By: Nik http://niksilver.com/2006/09/26/quality-is-a-bogus-variable/comment-page-1/#comment-54 Nik Sat, 30 Sep 2006 15:18:21 +0000 http://niksilver.com/2006/09/26/quality-is-a-bogus-variable/#comment-54 Mishkin, you touch on two very important areas which really need their own separate exploration, but are worth at least identifying in brief. I really feel for the support team you describe, and to me this is all about "whole teams". Whole teams must work together and be empowered to create the system. But once it goes into production most of that team often disappears and it's just the support people who are left. The team is no longer whole. The support people cannot possibly have the power to make improvements when those improvements really are the domain of the long-departed developers. The other area relates to common understanding. You're hinting at the point (which I didn't consider) that while it's one thing for the developers to report technical debt, it's quite another for the rest of the business to understand what they're being told. It does relate to truthfulness, your hot topic, but it's also apparent that truthfulness is going to be very hard to attain if your two parties don't understand each other in the first place. And it's not helped that quality is rather intangible in the way that time and budget are not. That issue of common understanding also takes us right back to the beginning: is quality about a bug count (nice and tangible) or about the bigger issues including usability, architecture, scaleability, etc? I suspect that because developers see a different side of the software from the client there will often be a mismatch on this issue. Maybe the most we can hope for is that whole teams in constant communication with each other will be able to agree among themselves on a per-project basis, even if there isn't ever a single standard understanding throughout everyone in the industry. Mishkin, you touch on two very important areas which really need their own separate exploration, but are worth at least identifying in brief.

I really feel for the support team you describe, and to me this is all about “whole teams”. Whole teams must work together and be empowered to create the system. But once it goes into production most of that team often disappears and it’s just the support people who are left. The team is no longer whole. The support people cannot possibly have the power to make improvements when those improvements really are the domain of the long-departed developers.

The other area relates to common understanding. You’re hinting at the point (which I didn’t consider) that while it’s one thing for the developers to report technical debt, it’s quite another for the rest of the business to understand what they’re being told. It does relate to truthfulness, your hot topic, but it’s also apparent that truthfulness is going to be very hard to attain if your two parties don’t understand each other in the first place. And it’s not helped that quality is rather intangible in the way that time and budget are not.

That issue of common understanding also takes us right back to the beginning: is quality about a bug count (nice and tangible) or about the bigger issues including usability, architecture, scaleability, etc? I suspect that because developers see a different side of the software from the client there will often be a mismatch on this issue. Maybe the most we can hope for is that whole teams in constant communication with each other will be able to agree among themselves on a per-project basis, even if there isn’t ever a single standard understanding throughout everyone in the industry.

]]> By: Mishkin Berteig http://niksilver.com/2006/09/26/quality-is-a-bogus-variable/comment-page-1/#comment-53 Mishkin Berteig Sat, 30 Sep 2006 02:04:19 +0000 http://niksilver.com/2006/09/26/quality-is-a-bogus-variable/#comment-53 Thanks for writing this! I agree with many of the things you are saying. I recently taught a course where there were several support folks in the audience. Their problem was complex in its details, but fundamentally it came down to them not being empowered to _really_ fix their users' problems. Everything they did was surface patches, bandaids, appeasment, etc. In a lean environment (and I admit to not being an expert here), my understanding is that any time a quality problem is found (in the large sense, not just in the "bug" sense), everyone stops what they are doing and fixes the problem... but not just the surface problem, but the root cause of the problem so that hopefully, the problem never re-surfaces again. For a support organization, that would mean that instead of providing one-off workarounds to users, the support people would solve the problem so that it never happened again. In fact, a support organization (e.g. a help desk) could be thought of as the sensory apparatus for detecting quality problems. A user calls and says "how do I do X"? and the support organization will normally just tell the user how to do X. But wouldn't it be better if the support organization also figured out how to make it so that no user would ever have to call and ask that question again? This gets to your comments about quality including usability, performance, etc. The trouble with this encompassing definition of quality is that it is in fact never perfectly attainable. That is also the good thing about this definition: it provides a very high standard to which we can aspire, and always find ways to move towards. This gets to my belief that with software we are ultimately looking to create the perfect servant: an uber-system which can do what we want and need before we even know it... and that's an intro to a huge topic in and of itself!!! Also, thanks for calling me on the arrogant comment. You are right: that is arrogant. I guess that lately I've been very focused on the idea of truthfulness and how incredibly foundational it is to being able to do valuable work. Again, a long discussion, but I think that we have a long way to go in developing our ability to be truthful. This isn't something that can be enforced with a process, and yet it is at the very core of what I think of as "agile". Now to get back to my comment... The problem with technical debt is that most organizations aren't really aware of the conseqences of allowing it to build up. We have a good understanding of financial debt: debt ratios, cash flow, assets vs. liabilities, etc. But when it comes to technical debt, it is a lot harder to measure, it is often obsure or hidden, and it is often incurred without the _informed_ consent of those who are taking the risks, namely the owners of the business funding the software development. This is where we get into a bit of trouble. Software development is a black art, an esoteric discipline. It is difficult to truly communicate the consequences of technical debt to the people who should be making the decisions about that debt. In fact, I think that software developers often don't know the consequences. Thanks for writing this! I agree with many of the things you are saying. I recently taught a course where there were several support folks in the audience. Their problem was complex in its details, but fundamentally it came down to them not being empowered to _really_ fix their users’ problems. Everything they did was surface patches, bandaids, appeasment, etc. In a lean environment (and I admit to not being an expert here), my understanding is that any time a quality problem is found (in the large sense, not just in the “bug” sense), everyone stops what they are doing and fixes the problem… but not just the surface problem, but the root cause of the problem so that hopefully, the problem never re-surfaces again. For a support organization, that would mean that instead of providing one-off workarounds to users, the support people would solve the problem so that it never happened again. In fact, a support organization (e.g. a help desk) could be thought of as the sensory apparatus for detecting quality problems. A user calls and says “how do I do X”? and the support organization will normally just tell the user how to do X. But wouldn’t it be better if the support organization also figured out how to make it so that no user would ever have to call and ask that question again? This gets to your comments about quality including usability, performance, etc. The trouble with this encompassing definition of quality is that it is in fact never perfectly attainable. That is also the good thing about this definition: it provides a very high standard to which we can aspire, and always find ways to move towards. This gets to my belief that with software we are ultimately looking to create the perfect servant: an uber-system which can do what we want and need before we even know it… and that’s an intro to a huge topic in and of itself!!!

Also, thanks for calling me on the arrogant comment. You are right: that is arrogant. I guess that lately I’ve been very focused on the idea of truthfulness and how incredibly foundational it is to being able to do valuable work. Again, a long discussion, but I think that we have a long way to go in developing our ability to be truthful. This isn’t something that can be enforced with a process, and yet it is at the very core of what I think of as “agile”. Now to get back to my comment… The problem with technical debt is that most organizations aren’t really aware of the conseqences of allowing it to build up. We have a good understanding of financial debt: debt ratios, cash flow, assets vs. liabilities, etc. But when it comes to technical debt, it is a lot harder to measure, it is often obsure or hidden, and it is often incurred without the _informed_ consent of those who are taking the risks, namely the owners of the business funding the software development. This is where we get into a bit of trouble. Software development is a black art, an esoteric discipline. It is difficult to truly communicate the consequences of technical debt to the people who should be making the decisions about that debt. In fact, I think that software developers often don’t know the consequences.

]]>