Devdelivery's Blog

I’m trying to figure out why anyone would call software defective that perfectly executes the requirements. What I think is that people associate defect fixes as being free and quick while change requests are charged and require lots of paperwork. Thus they want to classify everything a defect.

The reason that defect fixes (and here I am using my definition of ‘defect’ as being that which does not meet requirements) are usually quick is that we already have requirements and the code is already written. We know what to do and it is already mostly done, we just have to fix it.

A change request is not usually quick because

a)      we don’t know what to do. We are not the ones talking to the customer. Besides, we have to cover all exceptional cases. Also, most change requests are inconsistent with the rest of the application and basically wrong. We need to discuss it. I’ve found that in the cases where the situation is intuitively obvious and no discussions are needed, somehow QA comes up with a different understanding and we go around in circles over whose understanding is more intuitively obvious. Besides, we need documentation for traceability. This documentation does not need to be an epic novel, just enough to list the requirements.

b)      The code is not written. New features require new code which takes longer than fixing existing code.

None of this magically goes away by calling the issue a defect. If there are not written requirements concerning the issue (for whatever reason) then we need written requirements made. Simple as that. If there used to be written requirements but no one can find them, then new requirements covering this issue need to be made.

If we don’t want to charge the customer, then let’s not charge them. We don’t have to charge for CR’s. In fact, the overhead of justifying every hour far outweighs the revenue received for the minor CR’s. I don’t understand why we nickel and dime our big customers anyway. We should be doing this stuff as a matter of routine as part of the maintenance agreement.

Let’s imagine a scenario where the customer thinks the functionality should change for a particular scenario that was not covered in the original requirements.

We could a) call it a defect, or b) call it a change request.

Imagine a) call it a defect. We admit our software does not do what it is supposed to do. Our programmers are sloppy. Our QA apparently is incompetent. We apologize and humbly ask for forgiveness. The customer wonders if there are less idiotic vendors to deal with.

Now, imagine b) call it a change request. We explain to the customer that while this scenario was not considered, it is very common in software that once a new feature is released that new situations are discovered and that we would be very glad to discuss it with them. While discussing it with them, we point out how related areas might need to change and some risks involved. We also make some suggestions so that they know all their alternatives. An agreement is made on how the new scenario should behave and documented so that there are no misunderstandings. A service pack is released a month later to address the new scenario. Of course, all of this was at no cost to the customer as part of our comprehensive service. The customer is glad to have partners who understand their business so well and know that there is no one in the world that could possibly replace us.

Change requests are our chance to shine. It is our chance to get face time with the customer and be their partners in planning their business. It is our chance to show the value we add and to actually add value. Let’s not miss the opportunity.