Live data from Hacker News

One Way Smart Developers Make Bad Strategic Decisions

earthly.dev

51–60 of 81 posts

Re: One Way Smart Developers Make Bad Strategic Decisions

#51
post #43
post #25

Nice, interesting article. But I would stress less that "Seeing Like a State" -- that is a top-down, global solution -- was not the problem. The problem was that "Tim" didn't really understand the problem he was trying to solve (well, none of us truly understand very much at all, but he didn't understand it better than many of the teams associated with the individual services). "Tim"'s proposal probably solved some p…

> That's just flat wrong. A global solution can solve global concerns and also allow for local conditions. Past a certain level of complexity, that's no longer true. _Seeing Like a State_ is a great introduction to this, but I think Carol Sanford's work goes much more into detail. The main thing with the high-modernist view that James Scott was critiquing is that it comes from what Sanford would call the Machine Worl…

Truly, a fascinating perspective, thank you.

Just for the context: I would say I'm a natural intuitive bottom-upper, except that I can't help but reconsider everything my intuitive self learns from a strongly analytical top-down way.

From that perspective and 30+ years of experience (where I like to think I'm at least open to being completely wrong about anything and everything), I think top-down, prescriptive solutions can be useful and effective, but need to understand and carve out the holes (and conservatively large ones at that) for "local" concerns - BTW, "local" often typically just means lower, where there the lower level itself can have "global" and "local" concerns.

Now, I know this often doesn't happen, so let's lay out how it can work:

- there's a top-down person -- "Tim" in the article -- who has responsibility for for developing a solution

- there are the separate teams, who are responsible for communicating feedback on potential solutions.

Also, I wish I didn't need to point this out, but "responsibility for" === "authority/control over".

(If that's not the case, then never mind: you essentially have a "free-for-all" organization, and just better hope someone who's not too crazy wins the cage-match and can hang on long enough to be a net positive.)

Re: One Way Smart Developers Make Bad Strategic Decisions

#52
post #48
post #43

Earlier quoted context omitted.

> That's just flat wrong. A global solution can solve global concerns and also allow for local conditions. Past a certain level of complexity, that's no longer true. _Seeing Like a State_ is a great introduction to this, but I think Carol Sanford's work goes much more into detail. The main thing with the high-modernist view that James Scott was critiquing is that it comes from what Sanford would call the Machine Worl…

Oh yeah, and I just remembered -- Go. It's a great way of training strategic analysis and making decisions. After moving past the basis, what one explores are global vs. local, influence vs. territory, discerning urgent vs. big moves, direction of play, and so forth. It is theoretically a perfect-information game, but it is sufficiently complex enough for humans that it simulates the fog of war and having to make dec…

"It is theoretically a perfect-information game"

Ha, ha! A concept for suckers.

Re: One Way Smart Developers Make Bad Strategic Decisions

#53
post #25

Nice, interesting article. But I would stress less that "Seeing Like a State" -- that is a top-down, global solution -- was not the problem. The problem was that "Tim" didn't really understand the problem he was trying to solve (well, none of us truly understand very much at all, but he didn't understand it better than many of the teams associated with the individual services). "Tim"'s proposal probably solved some p…

The scenario reminds me of this story:

https://mwl.io/archives/605

Re: One Way Smart Developers Make Bad Strategic Decisions

#54
post #43
post #25

Nice, interesting article. But I would stress less that "Seeing Like a State" -- that is a top-down, global solution -- was not the problem. The problem was that "Tim" didn't really understand the problem he was trying to solve (well, none of us truly understand very much at all, but he didn't understand it better than many of the teams associated with the individual services). "Tim"'s proposal probably solved some p…

> That's just flat wrong. A global solution can solve global concerns and also allow for local conditions. Past a certain level of complexity, that's no longer true. _Seeing Like a State_ is a great introduction to this, but I think Carol Sanford's work goes much more into detail. The main thing with the high-modernist view that James Scott was critiquing is that it comes from what Sanford would call the Machine Worl…

> This includes clinging to the idea that for any given problem, there is a global solution which will satisfy all local conditions.

The parent comment wasn't stating this. It was stating that there could be a partial global solution that would benefit all microservices, a solution which teams would have to adapt for covering local conditions as well. A middle ground per se.

Thanks for sharing the "Living Systems World View" btw, very interesting!

Re: One Way Smart Developers Make Bad Strategic Decisions

#55
post #52
post #48

Earlier quoted context omitted.

Oh yeah, and I just remembered -- Go. It's a great way of training strategic analysis and making decisions. After moving past the basis, what one explores are global vs. local, influence vs. territory, discerning urgent vs. big moves, direction of play, and so forth. It is theoretically a perfect-information game, but it is sufficiently complex enough for humans that it simulates the fog of war and having to make dec…

"It is theoretically a perfect-information game" Ha, ha! A concept for suckers.

Perfect information must not be confused with perfect information processing.

GIGO does not imply its opposite.

Re: One Way Smart Developers Make Bad Strategic Decisions

#56
post #43
post #25

Nice, interesting article. But I would stress less that "Seeing Like a State" -- that is a top-down, global solution -- was not the problem. The problem was that "Tim" didn't really understand the problem he was trying to solve (well, none of us truly understand very much at all, but he didn't understand it better than many of the teams associated with the individual services). "Tim"'s proposal probably solved some p…

> That's just flat wrong. A global solution can solve global concerns and also allow for local conditions. Past a certain level of complexity, that's no longer true. _Seeing Like a State_ is a great introduction to this, but I think Carol Sanford's work goes much more into detail. The main thing with the high-modernist view that James Scott was critiquing is that it comes from what Sanford would call the Machine Worl…

Thanks for the reading recommendation! Learning about the Cynefin framework and thinking about those kinds of problems led me to James Scott and to Hayek, but I haven't come across Sanford's work before.

Re: One Way Smart Developers Make Bad Strategic Decisions

#57
post #51
post #43

Earlier quoted context omitted.

> That's just flat wrong. A global solution can solve global concerns and also allow for local conditions. Past a certain level of complexity, that's no longer true. _Seeing Like a State_ is a great introduction to this, but I think Carol Sanford's work goes much more into detail. The main thing with the high-modernist view that James Scott was critiquing is that it comes from what Sanford would call the Machine Worl…

Truly, a fascinating perspective, thank you. Just for the context: I would say I'm a natural intuitive bottom-upper, except that I can't help but reconsider everything my intuitive self learns from a strongly analytical top-down way. From that perspective and 30+ years of experience (where I like to think I'm at least open to being completely wrong about anything and everything), I think top-down, prescriptive soluti…

A point made that I think you are missing is that unless all of the separate teams fully understand the potential solution, then they can't provide useful feedback.

If team X doesn't know Kafka, then they can't tell you the ways in which it's not as good as their existing (potentially ad-hoc, but definitely working!) message system. There may be things that their system does that the team just automatically assumes all message-brokers will do because it's "obvious" that it's needed.

If, on the other hand, someone on team X organically considers Kafka as a local solution, learns it, tries it out, all of this stuff becomes obvious immediately.

So the pure top-down approach has two possible solutions:

1. It gets useless feedback "meh, seems fine"

2. All N organizations actually take the time to try out the solution before giving feedback, which means you spend a lot of resources evaluating each top-down hypotheses

The suggested solution from TFA is to have a top-down person embed in one team, find some improvements that work locally, then embed in a second team and do the same. Only then should one try to generalize from the shared experiences of the team. It recognizes that good feedback is expensive and bad feedback is likely, so just cut out the whole "give feedback" stage and have the top-down person learn from actually being embedded in a couple of teams.

Re: One Way Smart Developers Make Bad Strategic Decisions

#58

As a whole the strategy of "Let's see what's common in all these systems" is a good start to understanding the systems. There is a limit to the complexity any single person can understand. Unification is simplification. It helps understanding. But I agree it is no good trying to make the landscape fit a simple map when reality is much more complex. There's no Silver Bullet in trying to combat complexity. But rather t…

Except when Tim decides to standardize how each micro-service is built, using a custom framework...

Re: One Way Smart Developers Make Bad Strategic Decisions

#59

Earlier quoted context omitted.

> Counter example: Tom standardized a bunch of services... and it worked! Everything is easier and more efficient now. I’m sorry, but that isn’t really a counter point unless you have some cases to back it up. In my completely anecdotal experience standardisation never really works. I say this as someone who’s worked on enterprise architecture at the national level in Denmark and has co-written standardisations and p…

As far as I can tell how well standardization works depends on "how close to the humans" it is. HTTP; TCP; json; xml: all standardize pretty well. Want to standardize your micro services on nginx with data in json? It will work swimmingly and save time because it is one less decision to be made, and overtime everyone will become familiar with how nginx is setup. Standardizing on what json libs to use so that everyone…

So the answer is, standardize communication/protocols but leave procedure to the free market?
Post reply on HN