6 ms·

Own the problem, not the solution

47 points by milkglass 3y ago

ensocode 3y ago
This is how it should be and I think we should go back to this approaches. Too many buzzwords, too much agile ideology. Not that we should ignore Agile but the solution to a problem must bring in the expected value for the customer. On the other hand I feel the pressure with my clients that they go into a strategic direction with decisions for specific platforms and technologies. So sometimes you are forced to use platforms and tools which are not an ideal solution for a specific problem
eterm 3y ago
I don't understand what the author is trying to say with this post. "Don't be a solution looking for a problem"? Okay, but there's little insight beyond that pithy statement, no guidance of how to avoid that trap, just an anecdote that someone did that once? Or is the point the middle about Kubernetes? The author brings up questions and says: > What problem was Kubernetes trying to solve? How did the solution address the problem? What problem was Agile trying to solve? How did the solution address the problem? It’s only by examining these questions can an organization make the solution their own. But then doesn't go onto to actually examine or explore these questions in the blogpost, just moves on and ignores those questions after bringing them up. Overall, this post feels half-baked. The author seems to want the audience to do the work in fleshing out his thoughts. What does it mean to "own the problem" and what advantage does that have over "[owning a] solution".
- CaptainOfCoit 3y ago
  I don't think this blogpost is particularly revolutionary, it's fairly standard way of approaching things, but I also think I understand the gist of it. So the author is somewhat of an consultant, and a company would approach them and ask "Which solution should I purchase?", and the author thinks it's a better approach to consider "What problems am I having?" first, and then which solution is needed becomes obvious. So Kubernetes is a solution to some problem(s), and unless you actively know and understand the problem you're trying to solve, you might go for a solution that solves a problem you're not having. Again, the blogpost is not presenting any new ideas, and seems to have been written on a subway ride home from work, but still the process described is useful in a lot of contexts. The TLDR of the blogpost is essentially: "customize solutions to specific problems rather than blindly adopting popular methods or technologies", or put another way "don't cargocult". That's basically the shortest version possible of this blogpost.
- sebastianconcpt 3y ago
  I feel you. He is having a good point but presenting it in a way that is weak to make himself understood. As an engineer, I have to say that the people that understands this issue better is the product people and not software people. I highly recommend this talk from Marty Cagan, he makes a fantastic case talking exactly on the same nature of the issue: The Nature Of Product by Marty Cagan https://www.youtube.com/watch?v=T3VRz18ntjQ https://www.youtube.com/watch?v=T3VRz18ntjQ
- codeptualize 3y ago
  I think your surprise is sort of the point of the article, it seems so simple and logical and that makes it kind of crazy how often people do things without a good reason and without fully understanding nor solving the problem they have and are trying to solve. I thought the article did a good job of explaining this issue, the intro with the cover is a nice analogy
- confd 3y ago
  “Find a solution that works for your particular situation.”
- lelanthran 3y ago
  > > What problem was Kubernetes trying to solve? How did the solution address the problem? What problem was Agile trying to solve? How did the solution address the problem? It’s only by examining these questions can an organization make the solution their own. > But then doesn't go onto to actually examine or explore these questions in the blogpost, just moves on and ignores those questions after bringing them up. Isn't that the point of the article? He is not trying to demonstrate to the audience "This is the problem Agile was intended to solve. This is how it addressed that problem.", he is pointing out that Agile is deployed as a solution without ever considering the problem that that solution was supposed to address. The blog post, to me, seemed to be proposing a refinement of the problem before a solution is proposed. Pointing out that many solutions are proposed before a problem statement is posed is the entire point of the blog post, not answering the questions he asks about commonly deployed solutions.
- karmakaze 3y ago
  A slight change in wording clarifies the case for me. Don't be attached to a/the solution.
weego 3y ago
What rambling mess connects bands doing covers in various styles, cargo cults and implementing Kubernetes? Reads like a bunch of ideas thrown together looking for a point
- paulcole 3y ago
  > a bunch of ideas thrown together looking for a point A late contender for the annual Accidental HN Motto Contest emerges.
- voidpointer 3y ago
  The cover-band analogy isn't so great; the issue where a specific solution becomes a proxy for solving some problems that no one bothered to fully understand is real though. Describing problems and doing thorough discovery is hard and silver bullets are attractive. The cargo-cult analogy is quite fitting for a lot of hyped-up topics. When you go to a car dealer and tell them your problem is getting from A to B, guess what their solution is going to be...
  - CaptainOfCoit 3y ago
    > When you go to a car dealer and tell them your problem is getting from A to B, guess what their solution is going to be... This is more accurate, more succinct and easier to understand than the submission article. Good analogy work! :)
jacknews 3y ago
"I help private equity portfolio companies maximize growth during the holding period using their technology organization." This sounds like a laser-focused specialization/niche, and yet no specific skill? That does explain the angle of the article.
geocrasher 3y ago
TL;DR: using $thing for the sake of $thing is just elevated cargo culting. He didn’t worry about what the Agile Alliance said to do, he made the solution his own, and he excelled. In other words, know what your problem is and solve that, instead of trying to force your problem into a favored solution.
dkarl 3y ago
Sometimes there's a perverse dynamic where you have to know a technology extremely well to use it simply, and if you can't invest time in understanding it at an expert level, you have to use it in a much more complicated way. If you stay on the well-trodden path, using it exactly the way everybody else uses it, you get easy fixes to the problems you encounter. You google for a problem, and the conversations you find apply straightforwardly to your situation. You never have to ask your own questions, because somebody has asked them before, and the only time you have to consult the docs is to help you understand the answers on Stack Overflow. However, you have to take on the burden of implementing the same architecture as everybody else, even if it's more complex than you need. This is how my last company used Kubernetes. When I arrived, they had a functioning bog-standard Kubernetes deployment. None of the (very small) team of full-time employees understood it very well, but they were able to cargo-cult their way forward. It worked out okay. I lived in fear of the day I would have to do a deep dive into Kubernetes to solve a production outage, but it never came. I think if we had had an expert in Kubernetes who understood the technology thoroughly, they might have been able to build a simpler solution that had fewer moving parts, fewer opportunities for failures and mistakes, while still meeting our needs. However, the downside of using a tool in a from-scratch expert way is that you have to take the same from-scratch approach to troubleshooting problems. The answers online won't apply to your setup. If you try to ask for help, people won't understand you. They might even tell you you're doing it wrong. If you tell them, "Module X is for Y, and we don't need Y. Our setup has been working fine without X for two years," they'll still say, "Your error must be because you're not using X." You'll be entirely on your own. That's how I imagine it would have been if somebody on our team invested the effort to become a Kubernetes expert and build exactly what we needed. If they left, we would have been left with a perfect bespoke solution, and we would have been screwed the first time something went wrong (or the first time our needs changed.) Again, that's not my expert opinion on Kubernetes, just what I imagine based on my experience with other complex technologies. I think something similar to an "innovation token" is at work here. Gaining fundamental expertise with a technology and building a bespoke solution with it (making a cover song your own, in the article's analogy) is an investment of effort. Cargo-culting your way forward (playing the song just like someone else) allows you to spend that effort elsewhere, at least for a while.
talkingtab 3y ago
When I read the title, I immediately went to medical care. Many doctors, hospitals, practices, insurance companies, etc. all own the solution not the problem. I once went to an eye doctor with blurry vision in both eyes. The doctor examined me, had a solution, got paid by the insurance company. There was only one problem. My vision was still blurry in both eyes. He told me my eyes were fine. He owned the solution but not the problem. I later realized I had started a new med and stopped it. The blurry vision went away. I owned the problem. My 2 cent biased view is that most medical care in the US - at least the kind available to us commoners - is now solution oriented. They own the solution but you still own the problem. There are some very notable exceptions including individual doctors. One exception I have personal experience with is Mass General Hospital. It is a remarkable place. When you go in to the Emergency room, they own the problem. They basically won't let you leave the place until they have owned the problem. It is remarkable how different that experience is compared to others. You sort of have to see it to believe it. They may not be able to fix you, but the problem is no longer yours. In most cases (and I have several) they do fix it. Once I went to the hospital, got a plan from the doctor to see someone who specialized in my condition and left. An hour later the doctor called telling me to go the ER immediately. She had called the other doctor to get his skill and So what does this have to do with the article? I believe we, as a culture, have become to a very large extent "solution" oriented. Ozempic. We have a whole generation of obese people, including five year olds. Now we have a solution. Just put everyone on ozempic. Sure it will cost them their life savings. Sure common people will not be able to afford. Sure they can never get off it. And that is the point of the article I believe. Don't go for solutions. Go for the problem. Why are so many people so obese now? We don't know and we don't care because we have a solution. Maybe so many people are obese because somewhere up the line people people chose to provide solutions and not fix the problem. <snark>Sugar, fat, industry owned food regulation anyone?</snark> So maybe the point of the Cargo Cult Theory is not so much imitation, but solution fixation.
- PH95VuimJjqBqy 3y ago
  you're just framing it in the same way the article did. really the problem is a lack of critical thinking and a by-rote approach to diagnosing problems, it has nothing to do with "owning" anything.
JackFr 3y ago
Sometimes Kubernetes is the answer. I don’t need Google scale, I don’t need all the bells and whistles, but what I get is abstracting server infra, and pushing it onto a dedicated corporate wide team.

47 points by milkglass 3y ago

This is how it should be and I think we should go back to this approaches. Too many buzzwords, too much agile ideology. Not that we should ignore Agile but the solution to a problem must bring in the expected value for the customer. On the other hand I feel the pressure with my clients that they go into a strategic direction with decisions for specific platforms and technologies. So sometimes you are forced to use platforms and tools which are not an ideal solution for a specific problem

eterm 3y ago

I don't understand what the author is trying to say with this post. "Don't be a solution looking for a problem"? Okay, but there's little insight beyond that pithy statement, no guidance of how to avoid that trap, just an anecdote that someone did that once? Or is the point the middle about Kubernetes? The author brings up questions and says: > What problem was Kubernetes trying to solve? How did the solution address the problem? What problem was Agile trying to solve? How did the solution address the problem? It’s only by examining these questions can an organization make the solution their own. But then doesn't go onto to actually examine or explore these questions in the blogpost, just moves on and ignores those questions after bringing them up. Overall, this post feels half-baked. The author seems to want the audience to do the work in fleshing out his thoughts. What does it mean to "own the problem" and what advantage does that have over "[owning a] solution".

CaptainOfCoit 3y ago
I don't think this blogpost is particularly revolutionary, it's fairly standard way of approaching things, but I also think I understand the gist of it. So the author is somewhat of an consultant, and a company would approach them and ask "Which solution should I purchase?", and the author thinks it's a better approach to consider "What problems am I having?" first, and then which solution is needed becomes obvious. So Kubernetes is a solution to some problem(s), and unless you actively know and understand the problem you're trying to solve, you might go for a solution that solves a problem you're not having. Again, the blogpost is not presenting any new ideas, and seems to have been written on a subway ride home from work, but still the process described is useful in a lot of contexts. The TLDR of the blogpost is essentially: "customize solutions to specific problems rather than blindly adopting popular methods or technologies", or put another way "don't cargocult". That's basically the shortest version possible of this blogpost.
sebastianconcpt 3y ago
I feel you. He is having a good point but presenting it in a way that is weak to make himself understood. As an engineer, I have to say that the people that understands this issue better is the product people and not software people. I highly recommend this talk from Marty Cagan, he makes a fantastic case talking exactly on the same nature of the issue: The Nature Of Product by Marty Cagan https://www.youtube.com/watch?v=T3VRz18ntjQ https://www.youtube.com/watch?v=T3VRz18ntjQ
codeptualize 3y ago
I think your surprise is sort of the point of the article, it seems so simple and logical and that makes it kind of crazy how often people do things without a good reason and without fully understanding nor solving the problem they have and are trying to solve. I thought the article did a good job of explaining this issue, the intro with the cover is a nice analogy
confd 3y ago
“Find a solution that works for your particular situation.”
lelanthran 3y ago
> > What problem was Kubernetes trying to solve? How did the solution address the problem? What problem was Agile trying to solve? How did the solution address the problem? It’s only by examining these questions can an organization make the solution their own. > But then doesn't go onto to actually examine or explore these questions in the blogpost, just moves on and ignores those questions after bringing them up. Isn't that the point of the article? He is not trying to demonstrate to the audience "This is the problem Agile was intended to solve. This is how it addressed that problem.", he is pointing out that Agile is deployed as a solution without ever considering the problem that that solution was supposed to address. The blog post, to me, seemed to be proposing a refinement of the problem before a solution is proposed. Pointing out that many solutions are proposed before a problem statement is posed is the entire point of the blog post, not answering the questions he asks about commonly deployed solutions.
karmakaze 3y ago
A slight change in wording clarifies the case for me. Don't be attached to a/the solution.

weego 3y ago

What rambling mess connects bands doing covers in various styles, cargo cults and implementing Kubernetes? Reads like a bunch of ideas thrown together looking for a point

paulcole 3y ago
> a bunch of ideas thrown together looking for a point A late contender for the annual Accidental HN Motto Contest emerges.
voidpointer 3y ago
The cover-band analogy isn't so great; the issue where a specific solution becomes a proxy for solving some problems that no one bothered to fully understand is real though. Describing problems and doing thorough discovery is hard and silver bullets are attractive. The cargo-cult analogy is quite fitting for a lot of hyped-up topics. When you go to a car dealer and tell them your problem is getting from A to B, guess what their solution is going to be...
- CaptainOfCoit 3y ago
  > When you go to a car dealer and tell them your problem is getting from A to B, guess what their solution is going to be... This is more accurate, more succinct and easier to understand than the submission article. Good analogy work! :)

jacknews 3y ago

"I help private equity portfolio companies maximize growth during the holding period using their technology organization." This sounds like a laser-focused specialization/niche, and yet no specific skill? That does explain the angle of the article.

geocrasher 3y ago

TL;DR: using $thing for the sake of $thing is just elevated cargo culting. He didn’t worry about what the Agile Alliance said to do, he made the solution his own, and he excelled. In other words, know what your problem is and solve that, instead of trying to force your problem into a favored solution.

dkarl 3y ago

Sometimes there's a perverse dynamic where you have to know a technology extremely well to use it simply, and if you can't invest time in understanding it at an expert level, you have to use it in a much more complicated way. If you stay on the well-trodden path, using it exactly the way everybody else uses it, you get easy fixes to the problems you encounter. You google for a problem, and the conversations you find apply straightforwardly to your situation. You never have to ask your own questions, because somebody has asked them before, and the only time you have to consult the docs is to help you understand the answers on Stack Overflow. However, you have to take on the burden of implementing the same architecture as everybody else, even if it's more complex than you need. This is how my last company used Kubernetes. When I arrived, they had a functioning bog-standard Kubernetes deployment. None of the (very small) team of full-time employees understood it very well, but they were able to cargo-cult their way forward. It worked out okay. I lived in fear of the day I would have to do a deep dive into Kubernetes to solve a production outage, but it never came. I think if we had had an expert in Kubernetes who understood the technology thoroughly, they might have been able to build a simpler solution that had fewer moving parts, fewer opportunities for failures and mistakes, while still meeting our needs. However, the downside of using a tool in a from-scratch expert way is that you have to take the same from-scratch approach to troubleshooting problems. The answers online won't apply to your setup. If you try to ask for help, people won't understand you. They might even tell you you're doing it wrong. If you tell them, "Module X is for Y, and we don't need Y. Our setup has been working fine without X for two years," they'll still say, "Your error must be because you're not using X." You'll be entirely on your own. That's how I imagine it would have been if somebody on our team invested the effort to become a Kubernetes expert and build exactly what we needed. If they left, we would have been left with a perfect bespoke solution, and we would have been screwed the first time something went wrong (or the first time our needs changed.) Again, that's not my expert opinion on Kubernetes, just what I imagine based on my experience with other complex technologies. I think something similar to an "innovation token" is at work here. Gaining fundamental expertise with a technology and building a bespoke solution with it (making a cover song your own, in the article's analogy) is an investment of effort. Cargo-culting your way forward (playing the song just like someone else) allows you to spend that effort elsewhere, at least for a while.

talkingtab 3y ago

When I read the title, I immediately went to medical care. Many doctors, hospitals, practices, insurance companies, etc. all own the solution not the problem. I once went to an eye doctor with blurry vision in both eyes. The doctor examined me, had a solution, got paid by the insurance company. There was only one problem. My vision was still blurry in both eyes. He told me my eyes were fine. He owned the solution but not the problem. I later realized I had started a new med and stopped it. The blurry vision went away. I owned the problem. My 2 cent biased view is that most medical care in the US - at least the kind available to us commoners - is now solution oriented. They own the solution but you still own the problem. There are some very notable exceptions including individual doctors. One exception I have personal experience with is Mass General Hospital. It is a remarkable place. When you go in to the Emergency room, they own the problem. They basically won't let you leave the place until they have owned the problem. It is remarkable how different that experience is compared to others. You sort of have to see it to believe it. They may not be able to fix you, but the problem is no longer yours. In most cases (and I have several) they do fix it. Once I went to the hospital, got a plan from the doctor to see someone who specialized in my condition and left. An hour later the doctor called telling me to go the ER immediately. She had called the other doctor to get his skill and So what does this have to do with the article? I believe we, as a culture, have become to a very large extent "solution" oriented. Ozempic. We have a whole generation of obese people, including five year olds. Now we have a solution. Just put everyone on ozempic. Sure it will cost them their life savings. Sure common people will not be able to afford. Sure they can never get off it. And that is the point of the article I believe. Don't go for solutions. Go for the problem. Why are so many people so obese now? We don't know and we don't care because we have a solution. Maybe so many people are obese because somewhere up the line people people chose to provide solutions and not fix the problem. <snark>Sugar, fat, industry owned food regulation anyone?</snark> So maybe the point of the Cargo Cult Theory is not so much imitation, but solution fixation.

PH95VuimJjqBqy 3y ago
you're just framing it in the same way the article did. really the problem is a lack of critical thinking and a by-rote approach to diagnosing problems, it has nothing to do with "owning" anything.

JackFr 3y ago

Sometimes Kubernetes is the answer. I don’t need Google scale, I don’t need all the bells and whistles, but what I get is abstracting server infra, and pushing it onto a dedicated corporate wide team.