I think the best way of thinking about it is to split problems up across levels. So if you have a code problem that you've worked out to be a design problem, you now have two problems. The higher level one needs to be fixed before you can fix the lower level one.
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.
Well analyzed, this is how real-world 'software problems' are interlocked one level to another and YES splitting problem across levels is way to go.
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.
> The higher level one needs to be fixed before you can fix the lower level one.
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)
More complex though, is the ripple effect each has on others, dependency on others etc...
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.
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.