The question?
They say that a question well asked is half answered. And so it appears to be.
> "the answer is therefore always in the data"
Now, while the answer might be in the data, whether it is or not will depend on what the question is. If you collect data regarding the size and distribution of pebbles on a beach, that won't provide answers to questions about the price of gold. You have to have the correct data and know what is the right question.
Knowing what the right question actually is, is the most overlooked part of software design. That is what makes it so difficult. Ask one person what it (a new project) should do and you'll get one answer, ask another person and you'll get a different answer. Ask a third and they'll tell you "I can't say: but I'll know it when I see it".
In most cases, the primary goal (no matter what the management team might say) of a piece of software is to meet the expectations of the users. Leaving aside the functional requirements: often the smallest part and the easiest to get right, most users simply want three things - they want the software to be fast, they want it to work intuitively and they want it to be consistent. After that we get down to small matters like producing the correct answer, not requiring an entire datacentre to support a single instance and not taking 20 years to develop.
So far as how that meshes with the "business requirements", so long as the users are happy, the auditors are happy and the budget wasn't exceeded, that is pretty much all you need to count a project as a success, The problem is that hardly any company ever asks the users what they want from a new application and hardly any of the attributes they value are ever measured, or designed in. So we end up with all the correct technical data to design a project, but none of the data necessary to answer the important questions that will define whether it will succeed or not.
Biting the hand that feeds IT
