5 ms·

Man the dead weight around development in corporations are mind numbing..

nerpderp82 4y ago
The institutionalized brain damage is real, I see bright new hires coming in, within 3 months they are towing all the lines, spouting tautologies, seeking alignment with corporate velocity vectors to gain momentum, generate impulse. Talking in non-specific platitudes that could literally mean anything and thus mean nothing. The biggest problem with a simple architecture and often why someone would complexify it up, is as a protection mechanism so you don't get some performance review motivated yokel doing a drive by to add in a feature and look like a rock star because it was so damn easy. NSS, that was the next step. You see this in open-source as well. Someone builds a beautiful foundation, and Steve rolls up with a submarine pull request to slam that cherry on top. A complex architecture ensures that you can adequately gate keep. The next aspect is you have to relentlessly say no to feature requests that literally destroy the system to add some new feature, the pressure to smash it to bits and make it a no longer simple system is such a perverse incentive that unless you have support from on high, every simple system will decay into a total mess, then the finger-painters will have moved on to some other system to predate on.
- babyshake 4y ago
  > non-specific platitudes Anything specific that tends to be used often?
  - nerpderp82 4y ago
    It is org specific, I have already triggered myself and need to find a safe space.
  - damiankennedy 4y ago
    "Move fast and break things". At 48 I've stopped fixing other people's things.
    - runlaszlorun 4y ago
      Prob OT but ‘break things’ old Zuck sure did. A bit sad given the billions folks made in the meantime. I almost said that I’m surprised they weren’t held accountable… but we all know better.
  - bradstewart 4y ago
    Appealing to "best practice" without concrete, specific reasoning is a big one.
  - whstl 4y ago
    "We need to build something that scales" to justify virtually every single source of complexity.
    - dahauns 4y ago
      Especially when then understanding of scaling only distinguishes between "unmaintainable monolith" and "full-blown web scale".
- waynesonfire 4y ago
  I don't think it has to be so nefarious. What I've experienced is developers taking the path of least resistance and failing to perform proper analysis to arrive at a less complex architecture. Why are folks taking the path of least resistance becomes an interesting question.
- a4isms 4y ago
  FYI, it's "toeing" the line. It's an expression from track and field, where at the start of each race the competitors place the tip ("toe") of their foot on the start line when they're ready to run. Similar to the expression "Up to scratch." In a boxing ring, there is a line in the ring that boxers must come to to begin the fight. To be "up to scratch" is to be ready and worthy of the fight, and from that, to be of acceptable quality or capability.
  - pksebben 4y ago
    Minor correction for your correction: "Toe the line" most likely has it's roots in military tradition [1]. To toe the line is to stand at the line for inspection - it's still used that way today (I had to do it myself in boot camp). Relevant, as in this context, it means being obedient to the hierarchy. 1 - https://en.wikipedia.org/wiki/Toe_the_line#:~:text=The%20most%20likely%20origin%20of,to%20%22toe%20the%20line%22 https://en.wikipedia.org/wiki/Toe_the_line#:~:text=The%20mos....
    - a4isms 4y ago
      Most interesting, I do believe you're right!
    - piotr-yuxuan 4y ago
      Interesting, I hadn't seen #:~:text=abc before. It does nothing on my browser (Firefox 109.0b9 on macOS) but is it inteded to highlight text?
      - aidos 4y ago
        It does on Chrome. I believe it’s used from Google search results to link you to the relevant place in the page.
- radlad 4y ago
  > The next aspect is you have to relentlessly say no to feature requests that literally destroy the system to add some new feature, the pressure to smash it to bits and make it a no longer simple system is such a perverse incentive that unless you have support from on high, every simple system will decay into a total mess, then the finger-painters will have moved on to some other system to predate on. Would you rather have a simple system that does nothing, or a complex / difficult-to-work with system that solves customer needs? It's easy to go too far in either direction.
  - hbrn 4y ago
    In my experience, most of the software complexity is accidental, i.e. it doesn't directly emerge from customer needs. And even if your framework is to use customer needs as justification for complexity, people will still use something like Kubernetes for an app with 10 monthly users, because it "helps us deliver features faster, have zero-downtime deployments and be scalable". Most (non-product) engineers have a natural inclination to introduce more complexity, and will use mental gymnastics to justify it.
    - nerpderp82 4y ago
      The majority of human intellect is used to justify actions they have already taken.
  - PaulStatezny 4y ago
    > Would you rather have a simple system that does nothing, or a complex / difficult-to-work with system that solves customer needs? With respect, this is clearly a false dichotomy. Creating the "simplest possible system" that solves customer needs is the entire point of this discussion. Avoiding as much complexity as possible brings enormous benefits. (Less bugs, less employee turnover, higher productivity, etc.) Never accept the notion that systems must be "difficult-to-work with" in order to solve customer needs.
    - radlad 4y ago
      It would be a false dichotomy, if I meant to say that you must choose one of these paths. I suppose "it's easy to go too far in either direction" was not clear enough. The argument I'm making is that the OP is creating a false dichotomy: that you must reject feature requests, or ruin the system. My point is that there are many, many developers who "relentlessly say no to feature requests that literally destroy the system to add some new feature" when the reality is that they do not want to put in the effort required to add the (meaningful) feature to the system. They are choosing system purity and laziness over delivering customer value, which requires more work in order to keep things simple.
- deleted 4y ago
  [deleted]
WakoMan12 4y ago
[flagged]
- zaphar 4y ago
  On the chance that this is a real cry for help and you are in a really bad place, please seek help.

The institutionalized brain damage is real, I see bright new hires coming in, within 3 months they are towing all the lines, spouting tautologies, seeking alignment with corporate velocity vectors to gain momentum, generate impulse. Talking in non-specific platitudes that could literally mean anything and thus mean nothing. The biggest problem with a simple architecture and often why someone would complexify it up, is as a protection mechanism so you don't get some performance review motivated yokel doing a drive by to add in a feature and look like a rock star because it was so damn easy. NSS, that was the next step. You see this in open-source as well. Someone builds a beautiful foundation, and Steve rolls up with a submarine pull request to slam that cherry on top. A complex architecture ensures that you can adequately gate keep. The next aspect is you have to relentlessly say no to feature requests that literally destroy the system to add some new feature, the pressure to smash it to bits and make it a no longer simple system is such a perverse incentive that unless you have support from on high, every simple system will decay into a total mess, then the finger-painters will have moved on to some other system to predate on.

babyshake 4y ago
> non-specific platitudes Anything specific that tends to be used often?
- nerpderp82 4y ago
  It is org specific, I have already triggered myself and need to find a safe space.
- damiankennedy 4y ago
  "Move fast and break things". At 48 I've stopped fixing other people's things.
  - runlaszlorun 4y ago
    Prob OT but ‘break things’ old Zuck sure did. A bit sad given the billions folks made in the meantime. I almost said that I’m surprised they weren’t held accountable… but we all know better.
- bradstewart 4y ago
  Appealing to "best practice" without concrete, specific reasoning is a big one.
- whstl 4y ago
  "We need to build something that scales" to justify virtually every single source of complexity.
  - dahauns 4y ago
    Especially when then understanding of scaling only distinguishes between "unmaintainable monolith" and "full-blown web scale".
waynesonfire 4y ago
I don't think it has to be so nefarious. What I've experienced is developers taking the path of least resistance and failing to perform proper analysis to arrive at a less complex architecture. Why are folks taking the path of least resistance becomes an interesting question.
a4isms 4y ago
FYI, it's "toeing" the line. It's an expression from track and field, where at the start of each race the competitors place the tip ("toe") of their foot on the start line when they're ready to run. Similar to the expression "Up to scratch." In a boxing ring, there is a line in the ring that boxers must come to to begin the fight. To be "up to scratch" is to be ready and worthy of the fight, and from that, to be of acceptable quality or capability.
- pksebben 4y ago
  Minor correction for your correction: "Toe the line" most likely has it's roots in military tradition [1]. To toe the line is to stand at the line for inspection - it's still used that way today (I had to do it myself in boot camp). Relevant, as in this context, it means being obedient to the hierarchy. 1 - https://en.wikipedia.org/wiki/Toe_the_line#:~:text=The%20most%20likely%20origin%20of,to%20%22toe%20the%20line%22 https://en.wikipedia.org/wiki/Toe_the_line#:~:text=The%20mos....
  - a4isms 4y ago
    Most interesting, I do believe you're right!
  - piotr-yuxuan 4y ago
    Interesting, I hadn't seen #:~:text=abc before. It does nothing on my browser (Firefox 109.0b9 on macOS) but is it inteded to highlight text?
    - aidos 4y ago
      It does on Chrome. I believe it’s used from Google search results to link you to the relevant place in the page.
radlad 4y ago
> The next aspect is you have to relentlessly say no to feature requests that literally destroy the system to add some new feature, the pressure to smash it to bits and make it a no longer simple system is such a perverse incentive that unless you have support from on high, every simple system will decay into a total mess, then the finger-painters will have moved on to some other system to predate on. Would you rather have a simple system that does nothing, or a complex / difficult-to-work with system that solves customer needs? It's easy to go too far in either direction.
- hbrn 4y ago
  In my experience, most of the software complexity is accidental, i.e. it doesn't directly emerge from customer needs. And even if your framework is to use customer needs as justification for complexity, people will still use something like Kubernetes for an app with 10 monthly users, because it "helps us deliver features faster, have zero-downtime deployments and be scalable". Most (non-product) engineers have a natural inclination to introduce more complexity, and will use mental gymnastics to justify it.
  - nerpderp82 4y ago
    The majority of human intellect is used to justify actions they have already taken.
- PaulStatezny 4y ago
  > Would you rather have a simple system that does nothing, or a complex / difficult-to-work with system that solves customer needs? With respect, this is clearly a false dichotomy. Creating the "simplest possible system" that solves customer needs is the entire point of this discussion. Avoiding as much complexity as possible brings enormous benefits. (Less bugs, less employee turnover, higher productivity, etc.) Never accept the notion that systems must be "difficult-to-work with" in order to solve customer needs.
  - radlad 4y ago
    It would be a false dichotomy, if I meant to say that you must choose one of these paths. I suppose "it's easy to go too far in either direction" was not clear enough. The argument I'm making is that the OP is creating a false dichotomy: that you must reject feature requests, or ruin the system. My point is that there are many, many developers who "relentlessly say no to feature requests that literally destroy the system to add some new feature" when the reality is that they do not want to put in the effort required to add the (meaningful) feature to the system. They are choosing system purity and laziness over delivering customer value, which requires more work in order to keep things simple.
deleted 4y ago
[deleted]

WakoMan12 4y ago

[flagged]

zaphar 4y ago
On the chance that this is a real cry for help and you are in a really bad place, please seek help.