10 ms·

It gets worse than promo-driven development. Recently we had a chat with a lead from another team. Their product has a lot of similarities with ours so we sync

It gets worse than promo-driven development. Recently we had a chat with a lead from another team. Their product has a lot of similarities with ours so we sync up every now and then to bounce ideas off each other. They recently release a big change that we thought didn't provide much value, so we asked him about it. His candid answer was "you know how it works, we have a service running in production, so we need to make changes". This sounds simple, but the implications are deep. Unlike individual engineers, moving entire teams around is difficult. If you have a team, you need to "justify" their existence. Is not enough to keep the lights on or slowly polish the product, you need grand roadmaps to keep yourself busy the next year or two. Ideally you want to justify that you need extra headcount to keep the product expanding.

mirntyfirty 4y ago
I think this is one of the key frustrations I have with modern software development, change for the sake of change. I feel as though many products degrade over time and as a user I’m generally quite hesitant to upgrade anything if I don’t have to.
- oicU00 4y ago
  They have to show on investor calls the line went up. We’re propping up the wealth of a generation that has no idea how anything works, but they got there first so of course they are now the de facto deciders of our agency.
  - mirntyfirty 4y ago
    True, it’s difficult to know how things work when they become needlessly complicated and one is unable to move on from a project that is essentially complete.
    - oicU00 4y ago
      It’s presumed needlessly complicated is necessary to make the line go up; behind the scenes, they say, mathmagical forces exist that only the chosen few truly understand. You see everything is really a graph of infinite brand names, and the flow of value is determined by the taxonomy of brand ownership. Many a study have been attempted to quantify what character qualities or technologies boost productivity. Their model becomes so nebulous no reasonable conclusions can be made. But now of course computers learning helps us untangle that web and low and behold the same economic winners emerged! Wow!
- MisterBastahrd 4y ago
  It's a whole "growth" thing. Like, it's not good enough to have a quality product that generates a sustainable revenue stream year after year. You have to "grow" because companies don't really do dividends anymore, they want a constant increase in stock prices, product be damned.
madeofpalk 4y ago
Arguably one of the causes of this is high salaries and only hiring (supposedly, I have no personal experience) Very Smart Developers. You're going to pay Google salaries for someone just to keep the lights on?
- HWR_14 4y ago
  It would be a smart business decision. A Google mid-tier employee or two just isn't a large cost to keep a project running. It's not cheap, sure, but to have a product running at scale?
- astrange 4y ago
  The rationale for developing Go is that Googlers are fresh out of school and only barely smart enough to program Java, so I think they’ve eased off on the notion they only hire super-geniuses.
  - tormeh 4y ago
    I think it's more that they're smart as hell but know very little or have poorly developed taste. So you have to give them a short leash otherwise they'll hang themselves with it through over-engineering and accidental complexity.
    - astrange 4y ago
      The literal quote from Rob Pike is "They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt.".
ZainRiz 4y ago
The problem is a bit more insidious than that As an engineer, you want to be working on cool new features too! Very few folks will be content sitting on their laurels just fixing the occasional bug or adding a touch more polish to a product that's already "done" If you setup a team to work that way, very soon you'll find that most of your engineers have left. Heck, the manager might get bored and leave too. "Okay, that's fine," you might think "The product is still doing alright even without an owner. Higher level leadership should be fine with that" Until the day comes when the service crashes unexpectedly, and you realize that no one left on the engineering team has enough context to debug the issue properly Hello two week long outage Examples: Heroku - https://twitter.com/GergelyOrosz/status/1520770263977271296 https://twitter.com/GergelyOrosz/status/1520770263977271296 Atlassian - https://twitter.com/GergelyOrosz/status/1513605414029516806 https://twitter.com/GergelyOrosz/status/1513605414029516806
- simion314 4y ago
  Isn't the 20% time to work on whatever cool shit you want enough ? (like how googlers created that garbage angular1 because they were border, have no clue about GUIs and had some fun scewing around ) ? I know people that are fine with getting paid to maintain shit so maybe the problem is Google only hires cool developers and the cool developers only want to work on cool stuff and in 2 years the newest cool stuff of-course.
  - WalterSear 4y ago
    It's a lie.
- angarg12 4y ago
  There is that too, but you could solve that by having engineers/teams working in new, cool, and useful products. I feel my company doesn't have a good mechanism to maintain services that aren't actively developed. We experience it first hand when one of our services got deprecated and we moved to a new org. The solution was literally to hire a new team in a low CoL country and hand over the service to them. Needless to say it was difficult to hire for those positions.
- 4y ago
WithinReason 4y ago
This sounds like Eric Weinstein's Embedded Growth Obligation (EGO) concept. Notably also occurs in academia and economics.
tfp137 4y ago
> If you have a team, you need to "justify" their existence. Is not enough to keep the lights on or slowly polish the product, you need grand roadmaps to keep yourself busy the next year or two. Ideally you want to justify that you need extra headcount to keep the product expanding. This. It generates the Bullshit Jobs that David Graeber talked about. As a middle manager or tech lead (Taskmaster) you hire people (Flunkies) to make yourself seem more important as well as for roles (Box Ticker) that you might not need but that any "important" project will retain. In the end, this generates duplicate effort and needless work that requires fixing (Duct-Tapers). The only one of the five Graeber categories not represented is the Goon, and that's because those get moved to MTV and fast tracked to the executive suite.
- rodgerd 4y ago
  > and that's because those get moved to MTV and fast tracked to the executive suite. "The Goon" is the analyst from an investment firm who tells your directors and CEO how many of you are going to be fired to make him happy.

mirntyfirty 4y ago

I think this is one of the key frustrations I have with modern software development, change for the sake of change. I feel as though many products degrade over time and as a user I’m generally quite hesitant to upgrade anything if I don’t have to.

oicU00 4y ago
They have to show on investor calls the line went up. We’re propping up the wealth of a generation that has no idea how anything works, but they got there first so of course they are now the de facto deciders of our agency.
- mirntyfirty 4y ago
  True, it’s difficult to know how things work when they become needlessly complicated and one is unable to move on from a project that is essentially complete.
  - oicU00 4y ago
    It’s presumed needlessly complicated is necessary to make the line go up; behind the scenes, they say, mathmagical forces exist that only the chosen few truly understand. You see everything is really a graph of infinite brand names, and the flow of value is determined by the taxonomy of brand ownership. Many a study have been attempted to quantify what character qualities or technologies boost productivity. Their model becomes so nebulous no reasonable conclusions can be made. But now of course computers learning helps us untangle that web and low and behold the same economic winners emerged! Wow!
MisterBastahrd 4y ago
It's a whole "growth" thing. Like, it's not good enough to have a quality product that generates a sustainable revenue stream year after year. You have to "grow" because companies don't really do dividends anymore, they want a constant increase in stock prices, product be damned.

madeofpalk 4y ago

Arguably one of the causes of this is high salaries and only hiring (supposedly, I have no personal experience) Very Smart Developers. You're going to pay Google salaries for someone just to keep the lights on?

HWR_14 4y ago
It would be a smart business decision. A Google mid-tier employee or two just isn't a large cost to keep a project running. It's not cheap, sure, but to have a product running at scale?
astrange 4y ago
The rationale for developing Go is that Googlers are fresh out of school and only barely smart enough to program Java, so I think they’ve eased off on the notion they only hire super-geniuses.
- tormeh 4y ago
  I think it's more that they're smart as hell but know very little or have poorly developed taste. So you have to give them a short leash otherwise they'll hang themselves with it through over-engineering and accidental complexity.
  - astrange 4y ago
    The literal quote from Rob Pike is "They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt.".

ZainRiz 4y ago

The problem is a bit more insidious than that As an engineer, you want to be working on cool new features too! Very few folks will be content sitting on their laurels just fixing the occasional bug or adding a touch more polish to a product that's already "done" If you setup a team to work that way, very soon you'll find that most of your engineers have left. Heck, the manager might get bored and leave too. "Okay, that's fine," you might think "The product is still doing alright even without an owner. Higher level leadership should be fine with that" Until the day comes when the service crashes unexpectedly, and you realize that no one left on the engineering team has enough context to debug the issue properly Hello two week long outage Examples: Heroku - https://twitter.com/GergelyOrosz/status/1520770263977271296 https://twitter.com/GergelyOrosz/status/1520770263977271296 Atlassian - https://twitter.com/GergelyOrosz/status/1513605414029516806 https://twitter.com/GergelyOrosz/status/1513605414029516806

simion314 4y ago
Isn't the 20% time to work on whatever cool shit you want enough ? (like how googlers created that garbage angular1 because they were border, have no clue about GUIs and had some fun scewing around ) ? I know people that are fine with getting paid to maintain shit so maybe the problem is Google only hires cool developers and the cool developers only want to work on cool stuff and in 2 years the newest cool stuff of-course.
- WalterSear 4y ago
  It's a lie.
angarg12 4y ago
There is that too, but you could solve that by having engineers/teams working in new, cool, and useful products. I feel my company doesn't have a good mechanism to maintain services that aren't actively developed. We experience it first hand when one of our services got deprecated and we moved to a new org. The solution was literally to hire a new team in a low CoL country and hand over the service to them. Needless to say it was difficult to hire for those positions.
4y ago

WithinReason 4y ago

This sounds like Eric Weinstein's Embedded Growth Obligation (EGO) concept. Notably also occurs in academia and economics.

tfp137 4y ago

> If you have a team, you need to "justify" their existence. Is not enough to keep the lights on or slowly polish the product, you need grand roadmaps to keep yourself busy the next year or two. Ideally you want to justify that you need extra headcount to keep the product expanding. This. It generates the Bullshit Jobs that David Graeber talked about. As a middle manager or tech lead (Taskmaster) you hire people (Flunkies) to make yourself seem more important as well as for roles (Box Ticker) that you might not need but that any "important" project will retain. In the end, this generates duplicate effort and needless work that requires fixing (Duct-Tapers). The only one of the five Graeber categories not represented is the Goon, and that's because those get moved to MTV and fast tracked to the executive suite.

rodgerd 4y ago
> and that's because those get moved to MTV and fast tracked to the executive suite. "The Goon" is the analyst from an investment firm who tells your directors and CEO how many of you are going to be fired to make him happy.