Archive for the ‘Analysis’ Category

Ode to the Change Request

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.


Disagree to Disagree

90% of the time when two people disagree about a solution, they really disagree about the problem.

Usually Person A’s solution is the best for the problem that Person A sees.

And usually Person B’s solution is the best for the problem that Person B sees.

But since they go back and forth about who’s solution is best, they never realize that they are talking about two different problems.

If they would just step back and discuss the problem, they will resolve their disagreement so much sooner. But alas, defining the problem is boring analysis and who wants to do that?

Giant Sucking Noise

Has this every happened at your company?

A problem is identified. The person doing the analysis only does a little before announcing their wonderful solution.

It seems problem solving is fun and creative. The person coming up with the solution feels so clever.

However, when full analysis is not done, it leaves a vacuum. And that giant sucking noise we hear is that solution based on half-assed analysis. It sucks because it does not fully solve anything.

But problem solving is funner when the analysis is incomplete – actual constraints and issues puts boundaries on the clever solutions. And analysis is so much work – not nearly as fun a being a clever problem solver.

A complete analysis usually practically points directly to a solution. The issue is vivid, the need real. But when we are led to the answer, where is the satisfaction of clever problem solving?

It is overwhelmed with the satisfaction of a good solution.