> Multiple scales. Move between scales freely. Maybe this is a design problem, not a testing problem. Maybe it is a people problem, not a technology problem [cheating, this is always true].
The key to this is realizing that once you decide a problem is at a certain scale, the fix needs to be at that scale too. 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. (on the level of the company)
Each type of problem has to be resolved by the resources on tap at that level. You fix data problems by editing the data. You fix code problems by changing code. You fix leadership problems by changing leaders. You fix existential problems by changing jobs.
Becoming a more effective programmer involves understanding at a deep level how everything interlocks and moves together. If you can't solve it at one level, escalate to the next level and try to solve it there.
So you might have a code problem that you get pushback on fixing, this makes it a design problem. So you get the stakeholders in a room to come to a decision about what the code should be doing. If they can't come to a decision then it's an organizational problem, so you go to the leader for a decision. If he can't make a decision then you've got clues to a hidden leadership problem at the company.
Problems should be instantly solvable once you get to the level they're really at. You don't escalate though until you know enough about it to make a short presentation to the next person in the chain.
Once you get above the workflow level, you're in the realm of politics. Political problems are defined by the fact that multiple people in the organization care about it and you need to get sign-off before you go and unilaterally change something.
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.
The corollary to this is to never solve the problem at the wrong level. It's always a recipe for pain when you, say, have a data issue and you decide you'll solve it with some clever code. Or perhaps you have a fundamental design problem, but maybe you can just tweak the data...
There's a concept from SEI's CMM levels that attempting to maintain an impedance mismatch of greater than 1 between different parts of the organization ends in pain.
I think in this case I agree with GP that it is possible to 'solve' a problem at one degree removed from the source if there is no way to actually solve the problem at the source.
So for instance, lots of people write code to scrub janky data from a partner (indeed, that may be part of the value you add to the system).
Projects exist to serve a business need. Teams serve the project. Projects can develop problems that the team can't solve, for instance if an e-commerce project is losing revenue for business reasons rather than technical reasons.
These problems have to be tackled by management. Management has to change the scope and goals of the project so that the design team can better create deliverables for the engineering team to build.
Once you get to this level, generally the coders can only raise issues, they don't have the expertise necessary to actually recommend solutions.
About the only thing a coder can do if he sees something like this is to work really hard to actually understand what's going on, raise his concerns to management, and if he doesn't like their answer, get another job. Because chances are, if the project dies, so will his job.
The key to this is realizing that once you decide a problem is at a certain scale, the fix needs to be at that scale too. 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. (on the level of the company)
Each type of problem has to be resolved by the resources on tap at that level. You fix data problems by editing the data. You fix code problems by changing code. You fix leadership problems by changing leaders. You fix existential problems by changing jobs.
Becoming a more effective programmer involves understanding at a deep level how everything interlocks and moves together. If you can't solve it at one level, escalate to the next level and try to solve it there.
So you might have a code problem that you get pushback on fixing, this makes it a design problem. So you get the stakeholders in a room to come to a decision about what the code should be doing. If they can't come to a decision then it's an organizational problem, so you go to the leader for a decision. If he can't make a decision then you've got clues to a hidden leadership problem at the company.
Problems should be instantly solvable once you get to the level they're really at. You don't escalate though until you know enough about it to make a short presentation to the next person in the chain.
Once you get above the workflow level, you're in the realm of politics. Political problems are defined by the fact that multiple people in the organization care about it and you need to get sign-off before you go and unilaterally change something.