Live data from Hacker News

One Way Smart Developers Make Bad Strategic Decisions

earthly.dev

31–40 of 81 posts

Re: One Way Smart Developers Make Bad Strategic Decisions

#31
While there is much to worry about over centralization, there are benefits to at least trying if you can consolidate n-m efforts when n is the total number efforts using a queue and m are the snowflakes. It all depends on organization size and whether some costs can be amortized.

Everyone having specialized everything is exceptionally expensive at scale. Here, the key is tower of babel. What Tim should have done is kick start the effort with one or two teams, then organically grown it by reducing operational burden for new teams.

The mistake here is trying to globally optimize rather than seeking different vertical consolidation.

By the way, this is why Amazon has so many services.

Re: One Way Smart Developers Make Bad Strategic Decisions

#33
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…

> A global solution can solve global concerns and also allow for local conditions. Not if standardization is the priority.

> Not if standardization is the priority.

Is standardization always a priority?

Re: One Way Smart Developers Make Bad Strategic Decisions

#34

A well publicized example is EA mandating all its studios to use the Frostbite engine

I used to work on the Frostbite team at EA and it was quite the train-wreck. Many game teams spent considerable time moving to Frostbite only to fail and go back to the old game engine, the game teams which managed to move to the frostbite engine were unable to keep up with engine updates and got stuck on old arcane engine versions, the frostbite engine team was split between multiple geolocations and the teams in different locations didn’t get along well and ended up developing silos, and finally there were about a million layers of management in the frostbite team — I heard from old timers that the team used to be much more engineering focused.

Re: One Way Smart Developers Make Bad Strategic Decisions

#35
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 depends a lot on the cardinality of the set of Tims.

If there’s one Tim per team, you’ll have 100 Tims proposing different global improvements and 100 teams needing to respond intelligently to those suggestions.

Re: One Way Smart Developers Make Bad Strategic Decisions

#36

I disagree with the conclusion although not necessarily with the situation described. A programmer only has so many hours in the day; if you want to be a more efficient programmer you either have to learn to type/think faster or you need to build frameworks, write libraries, and codify common practices. There are situations where that doesn't work but if your job is to pump out code for an organization there's a good…

> to be a more efficient programmer you either have to learn to type/think faster or you need to build frameworks, write libraries, and codify common practices.

That’s focused on the writing/creating side of the equation. In my side projects, I became a lot more efficient when I decided to put effort into using frameworks, adopting libraries, and copying common practices.

Re: One Way Smart Developers Make Bad Strategic Decisions

#37
post #3

This seems to be hallmark of a “Middle” developer. Not so junior that they couldn’t build a working solution that they assume everyone should use, but not senior enough to think twice about whether they should be building it. The “we should make a common framework” for this line is the dominant thought at this level. Never even a library. A framework. Everyone must do it this way. The more senior people share concept…

This kind of consequential decision can happen at high levels. Obviously less often when a truly brilliant developer ends up in a small organization (but that has its own risks.)

In the example, it was determined that they could not afford to let each service solve its individual bottlenecks ad hoc. So a corresponding strategic error was also made/forced at the senior business level.

It's easy to speculate in hindsight, but in this case I could imagine a globally enforced throughput mandate supported by a widely visible and frequently reviewed dashboard, new tools/libraries as needed, and an optional central queue service required to 'compete for business' of the individual service teams.

I can see potential problems with that too, though. In a sense, failure has already happened when growth management is deemed to be too important to be left to capable individuals on decentralized teams.

Enjoyed the article.

Re: One Way Smart Developers Make Bad Strategic Decisions

#38
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 depends a lot on the cardinality of the set of Tims. If there’s one Tim per team, you’ll have 100 Tims proposing different global improvements and 100 teams needing to respond intelligently to those suggestions.

That's when the business needs to assign one Tim, or a team of Tims as dictator(s). Everyone else can provide feedback but isn't the decision maker.

Re: One Way Smart Developers Make Bad Strategic Decisions

#39

I disagree with the conclusion although not necessarily with the situation described. A programmer only has so many hours in the day; if you want to be a more efficient programmer you either have to learn to type/think faster or you need to build frameworks, write libraries, and codify common practices. There are situations where that doesn't work but if your job is to pump out code for an organization there's a good…

> to be a more efficient programmer you either have to learn to type/think faster or you need to build frameworks, write libraries, and codify common practices. That’s focused on the writing/creating side of the equation. In my side projects, I became a lot more efficient when I decided to put effort into using frameworks, adopting libraries, and copying common practices.

You should absolutely be using existing frameworks, libraries, and common practices. But a popular framework will allow you make any application imaginable. If you're not making radically different applications every day, you can extend and constrain existing frameworks with your own code to make them specific to your needs.

For example, all my applications have the same look and feel, corporate branding, and authentication features. We use a popular framework but extended it to handle all of this stuff so it's never repeated between projects.

Re: One Way Smart Developers Make Bad Strategic Decisions

#40
post #12

For anyone interested in social systems that help avoid this top-down, centralized failure mode, I cannot recommend RFC 7282 enough: https://datatracker.ietf.org/doc/html/rfc7282 A whole lot of wisdom is captured in that document, including a deep understanding of the differences between unanimity, majority rule, and consensus. If you're involved in standardization efforts in any way, whether it's deciding where your…

interesting. For long time i've found that negative logic is more powerful/overarching than positive one - #ifndef NOT_THIS is more powerful than #if THIS .. and this article applies that even to agreeing vs not-disagreeing.
Post reply on HN