Understanding the Problem
In my previous post I supplied a riddle entitled “Where’s the Dollar?” and asked for the problem with its logic. This may seem ridiculous but these things come up all the time in software development when translating what our customers/clients want into sound logic and precise calculations.
One thing I’ve been trying to do better is ask the “five whys” to really get to the root of the problem. I’ve found that asking these questions and providing solutions can open up more opportunities than previously existed. While working on an ecommerce site, we were supposed to restrict a payment type when shipping to certain locations. Upon digging deeper, I found that if the payment type was restricted because the shipping amount needed to be calculated “on the floor” (the amount is determined by the weight, size and location of the shipment) as most of the shipments to these locations were, but not all. Since not all shipments to these locations were calculated later by rule, there were some opportunities to provide an additional payment for these circumstances. By truly understanding the problem and not just what is projected, we were able to provide more value to online shoppers in this case.
When looking back on the problem of the missing dollar you’ll have figured out by now that the incorrect calculation is based on adding up amounts gained and amounts spent. This becomes more clear when the numbers aren’t off by only one dollar. Now that I have a better understanding of the situation, I would rephrase it like so:
… Here’s the fun. You have three men who paid 10 dollars a piece and received one dollar back… this means they each paid nine dollars. The bellboy kept two dollars for himself. So, one x 3 equals 3 plus the 2 dollars the bellboy kept plus the 25 dollars at the front desk equals 30 dollars — why did the men pay a total of 27 dollars? Because 25 went to the room and the bellboy stole the other two dollars. Add that to the 3 they got back, and voila, you have all $30 accounted for.
There’s no substitute for domain experts, but domain experts aren’t much help for improving the process if they can’t share their knowledge and ability to solve problems within the process. If you’re a subject matter expert or you’re dealing with one, be sure you/they share how you/they came to the solution with others. This not only provides the visibility of how the problem was solved, but also gets others thinking in the same manner. Describing in detail the problem, the causes and the resolution not only provides a better understanding for everyone, but can also provide confidence in those that may need it.