One Way Smart Developers Make Bad Strategic Decisions • Hacker News Board

Re: One Way Smart Developers Make Bad Strategic Decisions

#71

Post by jamesfinlayson » Wed, Mar 09, 2022, 1:38 AM UTC

kingdomcome50 wrote: post #15

Counter 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…

> How would Tim's system look if they had opted for his approach from the start? How does the 3rd iteration of the system compare to the 1st iteration? Maybe Tim's solution is stepping-stone to something better. Impossible to tell.

Reminds of something a senior developer once told me about rewriting systems: the first iteration is ad-hoc and messy; the second iteration is well thought out but completely over-engineered and the third iteration gets it right because the developers have done extremes and know where the correct middle ground is.

Re: One Way Smart Developers Make Bad Strategic Decisions

#72

Post by orf » Wed, Mar 09, 2022, 2:19 AM UTC

People are similar to water: they will often the path of least resistance.

The trick is to find a solution, document its “shape”, make it easy to integrate and market the hell out of it internally. Then you let the market decide.

Building a big shared common library can be a mistake, but that’s not because it’s intrinsically the wrong choice, it’s impact is partly a function of how many resources you can dedicate to effectively designing and maintaining it. At a certain scale the economics of this suddenly flips.

The problem in the post seems to scream infrastructure rather than code. Identify the different types of queues services need, pick some off the shelf and preferably managed solutions, then make it take 5 minutes to get started.

Re: One Way Smart Developers Make Bad Strategic Decisions

#73

Post by speed_spread » Wed, Mar 09, 2022, 3:23 AM UTC

novembermike wrote: post #70

shuntress wrote: post #49

Earlier quoted context omitted.

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 .

One thing to remember here is that a senior dev might be at the beginner stage for org wide changes.

Master devs avoid writing code at all costs. They've read Sun Tzu and understand that writing new code is just admitting defeat.

Re: One Way Smart Developers Make Bad Strategic Decisions

#74

Post by chmod600 » Wed, Mar 09, 2022, 3:29 AM UTC

shuntress wrote: post #49

sudhirj wrote: 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…

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 .

Part of the motivation behind DRY was to avoid the mess of repeating yourself within a task by updating 17 levels of classes and factories to add a field somewhere. This is mainly solved by using a sane language and not having useless intermediary code.

But you are right: applying DRY between tasks requires good judgement, and sometimes it's best to just copy some similar code around than to prematurely invent an abstraction.

Re: One Way Smart Developers Make Bad Strategic Decisions

#75

Post by galaxyLogic » Wed, Mar 09, 2022, 3:34 AM UTC

Splizard wrote: post #58

galaxyLogic wrote: post #8

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...

Yes Tim is known to have done that :-)

But seriously I think there is something about micro-services that helps. It is that they unify things not on the application level but on a lower level by forcing a common communications protocol (http) to be used.

The services themselves can vary widely there is no need to make them all behave the same or even use the same database. All that is needed is for all of them to speak the same language, the same protocol with their clients.

We get the best of both worlds, unification and simplicity yet isolation at the same time. Micro-services are the greatest thing since sliced bread I think.

Re: One Way Smart Developers Make Bad Strategic Decisions

#76

Post by astrange » Wed, Mar 09, 2022, 3:56 AM UTC

hosh wrote: post #43

jmull wrote: 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…

> He is a building architect that greatly influenced how people think about Object Oriented Programming (http://www.patternlanguage.com/archive/ieee.html)

The funny part about this speech is that he's just telling everyone they did it wrong, and Richard Gabriel agrees:

https://dreamsongs.com/Files/DoingItWrong.pdf

The point of his pattern language is to enable people to create their own architecture for their own needs. The point of OOP design patterns is to lock you in a prison of enterprise Java programming in the Kingdom of Nouns. Of course, I think everyone realized this like a decade ago.

Re: One Way Smart Developers Make Bad Strategic Decisions

#77

Post by whakim » Wed, Mar 09, 2022, 4:05 AM UTC

jmull wrote: 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.

In theory, yes. But in practice, no (and this is the author's point, I think). In theory, the more "local conditions" you have to account for, the more exponentially complex your "global solution" becomes. (This is the "state" metaphor.) In practice, you can't build that impossibly complex system (and it might not be desirable, anyways!) - so you're likely to try to change local practices in service of a more streamlined global solution. The more you do that, the farther away you move from respecting local conditions.

Re: One Way Smart Developers Make Bad Strategic Decisions

#78

Post by hyperpallium2 » Thu, Mar 10, 2022, 4:35 AM UTC

I expect "Seeing Like a State" goes into it, but top-down global abstraction and standardization often does work. e.g. mass production, mass media, and States themselves are unbelievably, fantastically successful.

The point is more than it doesn't always work, as standardization is a poor substitute for actual understanding.

Re: One Way Smart Developers Make Bad Strategic Decisions

#79

Post by a1445c8b » Thu, Mar 10, 2022, 10:39 PM UTC

jamesfinlayson wrote: post #71

kingdomcome50 wrote: post #15

Counter 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…

> How would Tim's system look if they had opted for his approach from the start? How does the 3rd iteration of the system compare to the 1st iteration? Maybe Tim's solution is stepping-stone to something better. Impossible to tell. Reminds of something a senior developer once told me about rewriting systems: the first iteration is ad-hoc and messy; the second iteration is well thought out but completely over-engineer…

This has been my experience as well! This is why, if I have enough time to do it, I'd normally go through at least 2 throw-away prototypes before settling on a design to implement.

Re: One Way Smart Developers Make Bad Strategic Decisions

#80

Post by a1445c8b » Thu, Mar 10, 2022, 10:59 PM UTC

galaxyLogic wrote: post #8

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…

With a microservices architecture, it's still possible to locally optimize each microservice but then end up with a global architecture that is far from ideal. It seems to me that Tim's starting point was exactly that.