alt Hacker NewsI have often observed something about how we build software; I just realized that my observations are of a more fundamental human problem.
First, people are not good at defining problems. They may describe the problem that they want to solve in terms of an outcome, but often times the outcome that they want also includes some aspect that benefits them personally that is separate from the problem that they are describing.
Second, people are not good at separating problem from implementation. in fact, people are horrible at this. I think people have a very difficult time envisioning that the problem and the existing solution implementation (which itself might be making the problem worse) are separate things. so most people rarely consider and often actively oppose, radically different solutions.
In the political sphere, ideology Influences how one frames the problem that one wants to solve, and limits the universe of acceptable solutions. This exemplifies the two points that I raised above.
For example, when talking about healthcare policy, the two main “sides” in the US, both have ideologies that define outcomes in terms of consumer access to medical services, and which constrain allowable implementations to something that resembles insurance, with key differences being about who pays and what is covered and how much coverage one gets.
Just for the purposes of elaborating on my premise, I would point out that not all healthcare delivery systems in the world are designed around the insurance model, And that such a model includes vested interests, regulatory capture, and often incentivizes many participants to optimize in ways that don’t forward the implicit goal of making more people more healthy.
Please don’t reply with your opinions on my imperfect example; I don’t want to have a healthcare policy discussion. I just wanted to provide an example my main points about how humans approach political problem-solving.
Replies
People aren't good at defining problems when it comes to political views because - as far as I can tell - nearly everyone has zero interest in actually solving the issue, or putting in work to do so.
They want someone else to do the hard work and play Monday morning quarterback. To extend the sportsball metaphor, the football team is doing the actual work and they're just spectators rooting for their team.
No one wants to do work without being compensated, and virtually no one is being compensated to actually solve these problems. Politicians are there to get re-elected first and anything else second. Charitable organizations pay little to nothing, and get the kind of personnel that are OK with that.
At this point, there's so much tribalism wrapped around policy issues that it might be impossible to get anyone to try to objectively solve the issue. And all too often, there is no viable way to A/B test the solution and people have to hope that their solution works best, which is... Not a great way to get great results.
> Second, people are not good at separating problem from implementation. in fact, people are horrible at this. I think people have a very difficult time envisioning that the problem and the existing solution implementation (which itself might be making the problem worse) are separate things. so most people rarely consider and often actively oppose, radically different solutions.
I'm bouncing back and forth on this. One thing I've learned over nearly two decades of programming, is that problems often are not separate from implementation - the one often defines or shapes the other to a large degree. Moreover, often enough it's not worth it to aim for clean separation - that's the road to becoming an "architecture astronaut".
I've also noticed this generalizes outside of programming. The key insight being, when people accuse "techies" of being "know-it-alls" and coming up with simplistic solutions (or my pet peeve of a term, "technological solutions to social problems"), what they're complaining about is generalizations - the kind you get when you focus on the abstract problem and forget about implementation details. This is particularly notable when one then tries to transfer a general solution/framework from one problem space to another, because whether or not it applies is largely determined by implementation details.
An example: understanding exponential growth and connecting it with basic virology is good. Applying that model to virological problems is okay - but the devil's in the details. Transferring that model to something else by means of analogy? Well, that very much depends on which assumptions you borrowed from virology, and it's helpful to be aware of those assumptions (implementation details) in the first place.
Seen plenty of that on every side of argument during COVID.