Louis Davidson has a parable about database design and systems auditing:
This brings me to my data question. If an order is processed in a store, but the expected data is not created, did that order ever occur?
Very often, the staff of a business are very focused on pleasing the customer, making sure they get their product, but due to software limitations, may not end up not capturing information about every sale in a satisfactory manner. Most of the blame I have seen lies in software that doesn’t meet the requirements of a customer, making capturing desired details tedious to achieve when the process is in the norm. Very often the excuse programmers give is that too much work of the work to build a system would need to be done for the atypical cases, but requirements are requirements, and it is generally essential that every action that occurs in a business is captured as data.
Read on for more. My conjoined twin case is, how much information do we have about why users give up? For example, if you have a three-part form, how many users get through part one, part two, and part three? There’s some natural level of attrition, but if you see an abnormally low follow-through rate, that might indicate a bug or major issue. Auditing is hard work, as you have to hit both sides of the problem at the same time.