In order to fix a problem at certain Level, you have to go to 'Bottom Most' layer which is ROOT cause of the problem.
>So you might have
a data problem,
a code problem,
a workflow problem,
a design problem,
an architectural problem,
a team problem,
a project problem,
an organizational problem,
a leadership problem, or
an existential problem.
So the client complains about software behavior. You now have a client problem. You isolate the issue down to a problem in the data. You fix the data but the problem recurs. You now have two problems, a client problem and a code problem, that's generating the bad data. You go to change the code but find a design problem. You now have three problems. You have to solve the design problem so that you know how to fix the code, so that you can then go tell the client that his problem's fixed and here's a free month's service for your trouble.
Here is one thing I gained from this Analysis. At times we encounter 'a Code problem' partly caused by ' a workflow problem' and partly caused by 'a Design problem' .
We may do a CODE patch fix for time being (ex. production bug), but having it documented as '40% Workflow problem, 60% Design problem' will help to consolidate all these 'contributing percentages' to come up with permanent fixes at a Later time.
well sometimes problems have workarounds, otherwise the poor 100x programmer would have to solve all existential problems first. (maybe a 1000x programmer could do that, when he finally reveals himself)
Far more nuanced than Maslow's
A shitty team can produce great code - a great team can produce shitty code. A shitty leader can kill a great team. an existential problem can destroy the value of any data-set. etc...
overall I totally agree with you and OP, and thinking through this is a great idea.
There's no way it's a data problem
It was a data problem