Hacker News Reader

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

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

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

“Find a solution that works for your particular situation.”

A slight change in wording clarifies the case for me. Don't be attached to a/the solution.

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.