5 ms·

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

by 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.

by eterm 3y ago

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.