I don't suppose we have any foresters on this board who can comment?
One Way Smart Developers Make Bad Strategic Decisions
61–70 of 81 posts
Re: One Way Smart Developers Make Bad Strategic Decisions
#62Earlier quoted context omitted.
I've worked at bigger companies and there are plenty of folks much higher than 'middle dev' forcing these types of things down the organization's throat.
You can certainly be a mid-level in skill but be a senior/staff/principal at the company, or a senior/staff/principal in technical skill but middle or junior in strategic or design skill.
Re: One Way Smart Developers Make Bad Strategic Decisions
#63This 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…
It's the large-scale version of taking "DRY" too literally. Junior devs just repeat themselves because they don't know better. Middle devs rush into an incomplete abstraction by overzealously not-repeating-themselves. Senior devs just repeat themselves because they know they don't understand what it would take to abstract out the solution. Like everything... "It Depends". Don't Repeat Yourself Too Much .
Re: One Way Smart Developers Make Bad Strategic Decisions
#64Nice, 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…
Caveat, for small enough problems, good enough solutions, and charismatic enough leaders, global solutions can work. But they all break eventually.
Re: One Way Smart Developers Make Bad Strategic Decisions
#65If you think of the United States, you might argue having a central government was better than each state being its own country and maybe that's the edge the US has over Europe.
Deciding to build roads everywhere top down definitely helped with overall car transportation.
Having HDMI as a common format for streaming video and audio sources is a big improvement over each TV using its own format.
There's plenty of counterexample to what the article talks about. So what gives? And on the example mentioned, how do you know if that's a great use of standardization or not?
I've been in many companies and I think they often fail to invest enough in frameworks and standards across the tech side. AWS was born out of Amazon's own effort to do top down standardization for example. And now it's their biggest cash cow and the entire industry is standardizing over its services.
Way too often I see people stuck on contract like work. Each locally scoped small problem needs its own locally scoped big project to be handled. That just simply doesn't scale.
The beauty of most engineering is exactly finding these top-down mechanism that do scale, even if it involves changing the business processes themselves. Think of a dishwasher for example, a top-down design that can wash most things but not all, eventually things that are not dishwasher safe became less and less popular and almost extinct, because people want to scale their efficiency.
Can top-down standards fail, ya sometimes, but when they succeed they take things to the next level of scale.
Don't shoehorn every problem in the same solution, but also, don't solve every solution independently of one another and reinvent the same wheel, or your engineering team of 10 will quickly become thousands while your business product will have barely grown.
Re: One Way Smart Developers Make Bad Strategic Decisions
#66This article does a good job describing one failure mode that's not understood well, but the opposite failure mode is much more common in my experience- having lots of ways to do the same thing can be very inefficient and brittle, even at small companies. The right answer is not "never unify systems" or "always unify systems", but develop judgement about when things should be unified.
Of course, this is such a rampant problem in the software industry that a whole market for reusable standard generic solutions was created. That's why we got the cloud, and the array of SaaS, PaaS, IaaS, etc. And don't forget the entire open source is about standards, being able to reuse existing components and frameworks.
What I think the article doesn't mention is that unifying and creating a standard solution is a harder task then creating custom solutions one after the other for each use case/local context. In practice I've seen people try and fail, but often it's not the person with most experience trying, or the business isn't truly willing to put in the effort to succeed, both of these can sabotage things. And again, because it is hard, you have to be willing to fail the first time, but use those learning to try again, and again, until you crack it. And doing that is often worth it long term, cause when you crack it the efficiency and scale will go through the roof, if your business is smart, you might even realize what you have is more valuable than your current business, and pivot to being a SaaS vendor haha. Or you can keep it secret as a competitive advantage.
Re: One Way Smart Developers Make Bad Strategic Decisions
#67Earlier 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…
> 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 pr…
Author makes no claim to why Tim's approach couldn't work. Instead they bring up other scenarios about different things in different contexts and somehow try to say, see, attempting standardization never works. Except in many cases where it did work, like the internet, like USB, like HDMI, like all SaaS and cloud vendors, like Ruby on Rails, like Scikit, like GitHub, etc.
Re: One Way Smart Developers Make Bad Strategic Decisions
#68A well publicized example is EA mandating all its studios to use the Frostbite engine
Re: One Way Smart Developers Make Bad Strategic Decisions
#69As 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…
Maybe everyone understands "unification" differently, but for me making something simpler means making things that are small, independent, and where if they change internally they break nothing externally.
But for this to work, you need common patterns, properties, interfaces, otherwise you can't combine your modules into a greater more complex system.
If you do it right, the system as a whole might be complex, but each piece is simple to understand and reason about and making changes to them is not a risk to breaking the whole system.
But it also means reuse, those small simple independent parts can be reused for more than one thing, that's why the system grows complex, so each micro-service is very much a unified standard on its own, just of a small enough scope to successfully build and maintain for multiple clients to leverage.
But now, if you go to the next level up, you have a problem with the complex set of micro-services you now have, and that complex arrangement gets hard to reason about. That is where people added the idea of Supervisor, to have systems that watch over the subsystems, it serves as a way to unify a set of micro-services into a more reliable and understandable hole.
Re: One Way Smart Developers Make Bad Strategic Decisions
#70This 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…
It's the large-scale version of taking "DRY" too literally. Junior devs just repeat themselves because they don't know better. Middle devs rush into an incomplete abstraction by overzealously not-repeating-themselves. Senior devs just repeat themselves because they know they don't understand what it would take to abstract out the solution. Like everything... "It Depends". Don't Repeat Yourself Too Much .