One Way Smart Developers Make Bad Strategic Decisions
1–10 of 81 posts
Re: One Way Smart Developers Make Bad Strategic Decisions
#2Very interesting article! I was left wondering though in what ways the queue abstraction solution failed?
Re: One Way Smart Developers Make Bad Strategic Decisions
#3This 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 concepts and maybe libraries, and allow the team to use them if they see fit.
Re: One Way Smart Developers Make Bad Strategic Decisions
#4This 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'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.
Re: One Way Smart Developers Make Bad Strategic Decisions
#5In general, "unity" is something software developers routinely pursue just for the sake of unity itself, failing to understand that unity comes with significant tradeoffs. It is much harder to build a unified solution than a localized, one-off solution. Divide-and-conquer is often a much better engineering strategy: DAC might create more work than unity, but the work is more likely to succeed instead of falling apart because we failed to anticipate all the use cases within the unified framework, especially when we lack experience in the domain.
Also refer to Jeff Atwood's Rule of Threes (which he borrowed from someone else) here.
Re: One Way Smart Developers Make Bad Strategic Decisions
#6This 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'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
#7This 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.
Re: One Way Smart Developers Make Bad Strategic Decisions
#8As 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 than trying to unify everything think about micro-services. Each service can be its own isolated solution. Of course it needs to be optimized in terms of how well it works when all the other services are running as well. But I think isolation is the key to independently optimizing everything.
I like this sentence from the article: "Lots of it doesn’t matter, but some of it matters a lot".
Re: One Way Smart Developers Make Bad Strategic Decisions
#9Some good points. At the same time, sometimes standardization is good and necessary. Imagine if everyone had to reimplement TCP/IP analogues to communicate over a network; we'd never get anything done!
Re: One Way Smart Developers Make Bad Strategic Decisions
#10Some good points. At the same time, sometimes standardization is good and necessary. Imagine if everyone had to reimplement TCP/IP analogues to communicate over a network; we'd never get anything done!
And those types of universal standards arrive by a process not unlike evolution - everyone who wants to has a crack at the problem and the solutions compete for a painful decade or two. Eventually a winner emerges from the top few frontrunners, and by 2040 only networking historians remember ALOHAnet or token ring networks.
However, you can't top-down design a universal standard.
With sufficient skill, patience, and wisdom, you may be able to design a standard that's good enough to be widely applicable.
Humans have free will, though (in practice, at least, no matter what you think about the philosophical question).
A standard only becomes universal when everyone chooses to adopt it.