When writing code, on what do you base your business logic? Assumptions? Requirements given to you by your boss? Knowledge of the business process your programme is supporting?
I was recently helping someone debug some code written to manage orders in an e-commerce system. It's a fairly complex system and there are a lot of variables around if, when and how an order is shipped out. While looking through the code, I found a piece of code that flagged some data after 7 days. I asked the programmer about this and he told me that his assumption was that orders would definitely have been shipped within a week, so he could treat all these orders as having been shipped.
Assumptions may be correct, most of the time. Is that good enough?
An assumption may be correct most of the time. However, how often can an assumption about business processes be wrong before it's not good enough any more? For example, if orders are shipped within 7 days 98% of the time and you average one order per day, about 7 times per year you'll mishandle an order. Is that OK? The primary school answer is to say, no, it's never OK. However, let's look at some other questions:
1. How expensive is this problem to fix? Is catching outliers significantly more expensive than dealing with these errors manually? Sometimes, for 7 mishandled orders a year, you can manually change the order for much less work than spending two weeks fixing the problem technically. I try to balance cost vs. benefit when discussing this sort of work with a customer.
2. How much of a problem is it for your customers? If these 7 customers are hospitals ordering liver transplants and they don't get their livers in time, then you'd better go back to the drawing board! On the other hand, if this is merely a reporting issue for a site that sells marbles, the marbles have been shipped out, and it just introduces a +-2% error in your sales reporting, then maybe it's something you can live with or fix manually.
3. What if your site is handling three thousand orders per day? If this is the case, your company will need at least one full-time staff member to track down the 60 or so mishandled orders that happen every day due to this assumption in the code. It's probably a lot cheaper to fix your code.
Instead of assuming, why not base your code on reality?
In the case of the example in this article, there were quite a few reasons why it was not safe to assume an order was shipped after 7 days. Backorders, partial shipments, lost orders, and customer returns would all break this assumption. Because of this, all reports created by the tool were suspect and couldn't really be trusted.
However, by digging deeper into the database, the actual status of every order was available. Instead of assuming the order had been shipped, the proper answer was to spend the time asking what the actual status of these orders was, and then dealing with them based on the reality of their (reported) status. By doing this, the tool suddenly became useful, as not only was the output trustworthy, but it also served to highlight some orders that might otherwise have been mishandled.
A report is only as good as the data upon which it's based. However, if the report is not even based on data but on assumptions, then it's only as good as the assumptions.