[deleted]
One Way Smart Developers Make Bad Strategic Decisions
21–30 of 81 posts
Re: One Way Smart Developers Make Bad Strategic Decisions
#22This 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…
I agree.
People use the most practical things at their disposal. If Tim had opted to publish a repository of easy and _simple_ recipes for managing kafka and postgres integrations, while retaining the ability to use original libraries, then I see no reason why it would not have gained traction.
Re: One Way Smart Developers Make Bad Strategic Decisions
#23A well publicized example is EA mandating all its studios to use the Frostbite engine
I have a bunch of friends who work for an EA studio (or who used to work for an EA studio) and they all _hate_ Frostbite. With a passion.
Re: One Way Smart Developers Make Bad Strategic Decisions
#24Very interesting article! I was left wondering though in what ways the queue abstraction solution failed?
for this specific example, I think the shared library is not the correct approach. Queues work for simple fifo behavior, but in this case they also need fairness (and perhaps other logic, like rate limiting per client, different priority for certain clients etc)
For example, "Customer-A is clogging up the work queue and starving other customers out". The solution to this could look something like linux's completely fair scheduler, where every client is allocated some amount of messages per interval of time. This means messages need to be processed in a different order then they are enqueued, and queues are not good at reordering messages.
I would suggest implementing the queue abstraction as a rest or grpc service, backed by a database like postgres, which holds message payloads and everything related to message state (in progress, retry after times, etc). Now we can implement all the necessary scheduling logic within our queue service.
Re: One Way Smart Developers Make Bad Strategic Decisions
#25Nice, 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 problems but created various other problems.
The best solution, though, (IMO) isn't that Tim should be smarted and better informed than everyone else combined, nor that every team should continue to create an independent solution. Instead "Tim" could propose a solution, and the 100 micro service teams would be tasked with responding constructively. Iterations would ensue. You still really, really need "Tim", though, because multiple teams, even sincere and proficient ones, will not arrive at a coherent solution without leadership/direction.
> A global solution, by necessity, has to ignore local conditions.
That's just flat wrong. A global solution can solve global concerns and also allow for local conditions.
Re: One Way Smart Developers Make Bad Strategic Decisions
#26Counter example: Tom standardized a bunch of services... and it worked! Everything is easier and more efficient now. I agree with the thrust of this post: Changing something that is not understood is a dubious undertaking. But the author fails to make a compelling connection between the above and software development. A poor solution may be a result of not understanding enough of the system as a whole, or it may not…
> 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…
> I’m sorry, but that isn’t really a counter point unless you have some cases to back it up.
My counter example is about exactly as detailed as the author's example. Of course I was being tongue-and-cheek, but clearly standardization has worked in software.
You can toss your example right on top of all of the other failed attempts at standardization. It in no-way supports the conclusion that "standardization" is a problem. Like I said, I agree with the author's argument, but their conclusion is not supported by that argument. There are many failure modes to large projects.
Re: One Way Smart Developers Make Bad Strategic Decisions
#27Nice, 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…
Makes sense. In my work I've seen this when trying to get developers on my team using certain patterns, styles, types, conventions, or tools (or the inverse - deprecating them).
Suggestions are usually well grounded (e.g., "let's migrate to this `std` class instead of this old home-rolled wrapper), but sometimes there's some nuance to how something is currently done and deep discussion of the proposal can work through these bits.
Re: One Way Smart Developers Make Bad Strategic Decisions
#28Nice, 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.
Re: One Way Smart Developers Make Bad Strategic Decisions
#29I 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 chance that most of your applications will have the same authentication, the same look and feel, etc. Putting effort into that core will pay dividends later. But you can't be a slave to your own code; if it doesn't fit in the box then don't force it.
Re: One Way Smart Developers Make Bad Strategic Decisions
#30Great short read and book recc.
I find myself often trying to articulate this idea (sometimes to myself, often to a friend) - starting with the map and building a territory from it --> generally bad.
While reading this article I wasn't even thinking about software. I think of a lot of progressive and/or socialist politics. To assert that the world should look as you one sees fit is flawed, both because one is not representative but mostly because the complexity of a system beyond toy example cannot be accurately modeled enough when the risk is catastrophe.