We seem to have a problem in our society with extras. Fast food chains offer you a 'meal' and in a particular size. The sizes change. Cars on the lot come with 'extras', but they can't seem to find the basic car at anyone's lot. Software improvements contain items we just don't need.
We often hear that in order to be successful in the workplace, we need to accept that change is a part of it. And so the 40 hour work week earned on the sweat and blood of unions is fast disappearing. But in software, anyway, some of that extra work and programming is for extra features that the customers never said they wanted and rarely use. Features are determined by a cost benefit analysis, rather than determining whether new features are required at all.
Far from making the product more appealing, customers often feel forced to buy the only version available. But sometimes, there is blowback. Microsoft's Vista's is a case in point. Sometimes, the customer doesn't buy. Or the customer complains. Or Open Source becomes popular.
In fact, I sometimes think that features should face a battle such as we're seeing in the Democratic primaries before they are allowed in to a piece of software. Now you may think that Open Source would be the answer to that, but Open Source is more like, if you want it, you can have it (think Wendy's burgers), rather than a collective vote.
So, what's the answer? Rather than a constant march for new features, perhaps a new version that removes bugs from the existing version -- only. Just make it better. Just make it higher quality. What do you think?
Tuesday, May 27, 2008
Friday, May 23, 2008
The last test
You've got a test plan. You've followed the test plan. You've run the test cases.
...again...
...and again...
and again.
Finally, you have the final release candidate. You run through your tests.
Now it is time to go into production. And you get?
A printed farm bill sent to the White House only to find 34 pages weren't printed.
How did this happen? Simple fatigue and forgetting to have a clear implementation test? No one had a check list to check it? Or those that did had printed it so many times that they were sure it was there? Or they were rushing? Doesn't matter.
You must check the actual version -- the actual, actual version, not the one in the directory from which the actual version will be copied. You must have an implementation test that knows what you have to check.
What is just as interesting is how members of Congress and the White House are responding to this gaffe. And that also relates to Quality Software. But that's for another post.
...again...
...and again...
and again.
Finally, you have the final release candidate. You run through your tests.
Now it is time to go into production. And you get?
A printed farm bill sent to the White House only to find 34 pages weren't printed.
How did this happen? Simple fatigue and forgetting to have a clear implementation test? No one had a check list to check it? Or those that did had printed it so many times that they were sure it was there? Or they were rushing? Doesn't matter.
You must check the actual version -- the actual, actual version, not the one in the directory from which the actual version will be copied. You must have an implementation test that knows what you have to check.
What is just as interesting is how members of Congress and the White House are responding to this gaffe. And that also relates to Quality Software. But that's for another post.
Thursday, May 22, 2008
American Airlines and Perception Quality
Recently, American Airlines announced that it would charge for all checked bags. This is a good example of negative perception quality. Even though American Airlines is using shared risk communication to explain this new charge, the impact will be negative quality.
In addition to a potential increased cost, there is the message that the company is hurting, and must take away one of the features that you have come to expect. This is similar to the software that 'unbundles' features and ask customers to pay for those features, when they had initially been free.
In the same way that customers with buggy software often find workarounds, customers will find more and more ways to stuff their carry on luggage, thereby potentially irritating existing customers who would not ordinarily check bags. This will lead to increased stress on the workers, who will already be more concerned for their jobs, in the same way that the focus on software companies ongoing cost-cutting efforts impact developers and quality staff. And staff focused on the security of their jobs are more likely to make mistakes and be less focused on quality for their customers.
Perception quality applies not only to customers, but to staff as well. It impacts the quality of what is developed, and the value of what is produced. And negative perception quality can have long term impact even if there is a remedy or reversal relatively soon after the blunder.
In addition to a potential increased cost, there is the message that the company is hurting, and must take away one of the features that you have come to expect. This is similar to the software that 'unbundles' features and ask customers to pay for those features, when they had initially been free.
In the same way that customers with buggy software often find workarounds, customers will find more and more ways to stuff their carry on luggage, thereby potentially irritating existing customers who would not ordinarily check bags. This will lead to increased stress on the workers, who will already be more concerned for their jobs, in the same way that the focus on software companies ongoing cost-cutting efforts impact developers and quality staff. And staff focused on the security of their jobs are more likely to make mistakes and be less focused on quality for their customers.
Perception quality applies not only to customers, but to staff as well. It impacts the quality of what is developed, and the value of what is produced. And negative perception quality can have long term impact even if there is a remedy or reversal relatively soon after the blunder.
Thursday, May 15, 2008
The software contract
I want to discuss the software contract - not the one we all ignore in commercial software. There are many software contracts for custom software. These are often the result of RFP (request for proposal), response to RFP, negotiations, all resulting in a contract.
What does your contract contain? There are key elements that should be found in the contract. I will list those that relate to the quality of the software and in a separate post (or series of posts) discuss how.
1. Time or dollar constraint
2. Testing requirement (this is broken further down by who, when, how much, linkage to acceptance and payment)
3. Software requirements
4. Relationship to the RFP
5. Modification responsibilities
6. Guarantee of quality (including definition of what that means)
7. Personnel assignments (including both customer and producer)
8. Signoff authority (including both customer and producer)
Gartner has an article on negotiating contracts here.
What does your contract contain? There are key elements that should be found in the contract. I will list those that relate to the quality of the software and in a separate post (or series of posts) discuss how.
1. Time or dollar constraint
2. Testing requirement (this is broken further down by who, when, how much, linkage to acceptance and payment)
3. Software requirements
4. Relationship to the RFP
5. Modification responsibilities
6. Guarantee of quality (including definition of what that means)
7. Personnel assignments (including both customer and producer)
8. Signoff authority (including both customer and producer)
Gartner has an article on negotiating contracts here.
Subscribe to:
Posts (Atom)