(Originally published at www.servicevirtualization.com.)
After my recent webinar (entitled Agile is Dead, replay is here, registration required but is free) I was having a follow up discussion with someone about it when the discussion turned to the nuances between what Agile actually promised and what people perceived it was supposed to deliver. From my perspective, the simplest explanation is that Agile promised to help ensure that business requirements were being met while people thought it meant that applications would be produced with far fewer defects. In the webinar, I described how Agile, if anything, increased the total number of defects due to its attempt to be more adjustable to the needs of the business mid-implementation.
The question was then asked: are software defects inevitable? If not then why do they exist? We're not talking about an insignificant problem. As I've often quoted, NIST produced a study in 2002 that illustrated a cost multiple of 30 to fix a defect discovered in production and another study that same year showing the net impact on the US Economy of production defects to be $60 billion.
To answer those first two questions, let's look at a few things.
Businesses Exist to Generate Revenue
This seems obvious, but it's worth stating the obvious here since we're going to be chaining a few items like this together into a cohesive whole. "But what about government agencies whose sole purpose is to provide free services?" you ask. Let's redefine (slightly) the phrase "generate revenue": by this I mean they are trying to increase the amount of cash flowing into the entity. I hesitate to say "cash flow positive" because that has a specific accounting definition that isn't met here. For our purposes, the ability to convince the Federal, State, and/or Local government that more money would allow them to produce better or more services is considered "generating revenue."
Technology Isn't a Luxury
This also seems obvious, so let me explain why I'm pointing this out using a question: could an accounting firm offer a legitimate service to potential customers using paper based ledger books only? The answer is yes - they would be fulfilling the definition of "accountant" - but they would probably have no customers.
The reason they would have no customers: manual data entry and calculations are slow, error prone, and prohibit value added services like quick financial analysis, etc. Even I, the most accounting challenged individual in the entire world, stopped using my checkbook registry (the personal version of a ledger) years ago in lieu of an Excel sheet that I created because the latter let's me see, at a glance, where all of my money is going; perform cash flow analysis; and defend my argument that groceries are expensive to the point now that they are the modern day equivalent of highway robbery.
The net result of this is that technology is at the very least indirectly responsible for the influx of cash to a business, profit, non-profit, or government entity alike.
When Would You Release Your Software?
The next question I asked my conversation partner was, "If you were the only Amazon, when would you release the next version of the website?" The answer was quick: they said they would release it when the following two conditions are met:
Obviously, that last point is no easy task (if it's achievable at all) and would take significant amounts of time to achieve. And, unfortunately, you aren't the only "Amazon," i.e. you have competition. Therefore, when software is being developed a decision has to be made:
In part 2, we'll continue by examining how all of this amasses in a tidal wave of process problems that result in software defects being released to production in spite of all of the nasty side effects their presence causes.
After my recent webinar (entitled Agile is Dead, replay is here, registration required but is free) I was having a follow up discussion with someone about it when the discussion turned to the nuances between what Agile actually promised and what people perceived it was supposed to deliver. From my perspective, the simplest explanation is that Agile promised to help ensure that business requirements were being met while people thought it meant that applications would be produced with far fewer defects. In the webinar, I described how Agile, if anything, increased the total number of defects due to its attempt to be more adjustable to the needs of the business mid-implementation.
The question was then asked: are software defects inevitable? If not then why do they exist? We're not talking about an insignificant problem. As I've often quoted, NIST produced a study in 2002 that illustrated a cost multiple of 30 to fix a defect discovered in production and another study that same year showing the net impact on the US Economy of production defects to be $60 billion.
To answer those first two questions, let's look at a few things.
Businesses Exist to Generate Revenue
This seems obvious, but it's worth stating the obvious here since we're going to be chaining a few items like this together into a cohesive whole. "But what about government agencies whose sole purpose is to provide free services?" you ask. Let's redefine (slightly) the phrase "generate revenue": by this I mean they are trying to increase the amount of cash flowing into the entity. I hesitate to say "cash flow positive" because that has a specific accounting definition that isn't met here. For our purposes, the ability to convince the Federal, State, and/or Local government that more money would allow them to produce better or more services is considered "generating revenue." Technology Isn't a Luxury
This also seems obvious, so let me explain why I'm pointing this out using a question: could an accounting firm offer a legitimate service to potential customers using paper based ledger books only? The answer is yes - they would be fulfilling the definition of "accountant" - but they would probably have no customers.
The reason they would have no customers: manual data entry and calculations are slow, error prone, and prohibit value added services like quick financial analysis, etc. Even I, the most accounting challenged individual in the entire world, stopped using my checkbook registry (the personal version of a ledger) years ago in lieu of an Excel sheet that I created because the latter let's me see, at a glance, where all of my money is going; perform cash flow analysis; and defend my argument that groceries are expensive to the point now that they are the modern day equivalent of highway robbery.
The net result of this is that technology is at the very least indirectly responsible for the influx of cash to a business, profit, non-profit, or government entity alike.
When Would You Release Your Software?
The next question I asked my conversation partner was, "If you were the only Amazon, when would you release the next version of the website?" The answer was quick: they said they would release it when the following two conditions are met:
- When the user's new needs were met
- When no defects exist
Obviously, that last point is no easy task (if it's achievable at all) and would take significant amounts of time to achieve. And, unfortunately, you aren't the only "Amazon," i.e. you have competition. Therefore, when software is being developed a decision has to be made:
- If I can't achieve "nerd-vana" by waiting until the code is 100% perfect, what is the highest probability that a critical function will work incorrectly that I am willing to accept, i.e. what's my risk threshold that a production defect will cause material harm to the business?
In part 2, we'll continue by examining how all of this amasses in a tidal wave of process problems that result in software defects being released to production in spite of all of the nasty side effects their presence causes.