4 ms·

Sure they do. You just need to spell it out in business terms, not tech terms: "Reduced incidents by 80%", "Decreased costs by 40%", "Increased performance by

Sure they do. You just need to spell it out in business terms, not tech terms: "Reduced incidents by 80%", "Decreased costs by 40%", "Increased performance by 33% while decreasing server footprint by 25%" Simplicity for its own sake is not valued. The results of simplicity are highly valued.

reactordev 9mo ago
This used to be true. Companies love efficiency. How does this stack up with modern AI? Seems those metrics would go in the opposite directions.
- candiddevmike 9mo ago
  The "time to market" folks finally have everything they could hope for, let's see all of that business value they claim is being missed due to pesky things like security, quality, and scalability checks.
nautilus12 9mo ago
You are citing negative metrics. The reality is that companies only care about positive metrics: increase marginal revenue by 30% That's regardless of the lip service they pay to cost cutting or risk reduction. It will only get worse, in the AI economy it's all about growth.
deleted 9mo ago
[deleted]
wccrawford 9mo ago
Absolutely. And if you asked them if they're rather have it sooner, or keep it simpler, they'd pick "sooner" every time.
- withinboredom 9mo ago
  I once used the analogy of the PM coming to the shop with a car that had a barely running engine and broken windows, and he's only letting me fix the windows. His response: "I can sell a good looking car and then charge them for a better running engine"... https://www.youtube.com/watch?v=T4Upf_B9RLQ https://www.youtube.com/watch?v=T4Upf_B9RLQ hits a little too close to home.
steveBK123 9mo ago
> "Reduced incidents by 80%", "Decreased costs by 40%", "Increased performance by 33% while decreasing server footprint by 25%" My experience is no one really gets promoted/rewarded for these types of things or at least not beyond an initial one-off pat on the back. All anyone cares about is feature release velocity. If it's even possible to reduce incidents by 80% then either your org had a very high tolerance for basically daily issues which you've now reduced to weekly, or they were already infrequent enough that 80% less takes you from 4/year to 1/year.. which is imperceptible to management and users.
- ambicapter 9mo ago
  You can reduce a single type of incident by 80%. The overall incident rate for this particular type wasn't high enough to kill your company, but it's still a big number on your promotion packet.
- tripledry 9mo ago
  > All anyone cares about is feature release velocity. And at the same time it's impossible to convince tech illiterate people that reducing complexity likely increases velocity. Seemingly we only get budget to add, never to remove. Also for silver bullets, if Big Tech promises a [thing] you can pay for that magically resolves all your issues, management seems enchanted and throws money at it.
- deleted 9mo ago
  [deleted]
- jamiemallers 9mo ago
  [dead]
praptak 9mo ago
You can't measure the impact of not creating a steaming pile of complexity.
- nyeah 9mo ago
  Really you can. You look at the engineers who create steaming piles, and you look at the ones who don't. Over a year or two, the difference is easy to spot. For people who care to spot it. If there's no competent front-line technical management who can successfully make this simple comparison, then, sure, in that case the team may be fucked.
  - bagacrap 9mo ago
    I think this is often true and it's the limiting factor that prevents complexity from spiraling out of control. But there's also a certain type of engineer who generates Rube Goldberg code that actually works, not robustly, but well enough. A mad genius high on intelligence and low on wisdom, let's say. This is who can spin complexity into self reward.
  - praptak 9mo ago
    Yes, I should have added "...this way" because I meant that to address GP's claim of the metric-based numerical measurement. In general, I agree that you can and should judge (not necessarily measure) thing like simplicity and good design. The problem is that business does want the "increased this by 80%, decreased that by 27%" stuff and simplicity does not yield itself to this approach.
    - deleted 8mo ago
      [deleted]
  - cloverich 9mo ago
    It's easy to gloss over this assessment but ultimately this needs to be a key decision point for where you choose to work. No matter how well you manage complexity as an IC or a lower tier leader, if your upper tier of leaders don't value it, it won't last. Simplicity IME is not a "tail that wags the dog" concept. It's too easy to stomp out if nobody in power cares.
esprehn 9mo ago
Those verbs (reduced, decreased, increased) all assume the situation was "bad" already. Avoiding that in the initial design is what's poorly rewarded. Building a system that's fast on day one will not usually be rewarded as well as building a slow system and making it 80% faster.
- bagacrap 9mo ago
  Yes, and ironically there are promotion ladders that explicitly call out "staff engineers identify problems before they become an issue". But we all know that in reality no manager-leader is ever going to fix problems eagerly, if they even agree with someone's prediction that that thing is really going to become a problem.
Oras 9mo ago
Never seen these metrics in real life, especially in engineering.
vjvjvjvjghv 9mo ago
And mostly these numbers are made up BS. But management will eat them up.
erelong 9mo ago
"Code footprint is 80% more efficient / less" (when there is a simpler design over more complex "big ball of mud abomination" in contrast)
causal 9mo ago
Thanks for the sane take. This article is engagement-porn for every engineer who ever looked at a system they didn't understand and declared they could do it much simpler. It's not because people love to promote complexity-makers, soothing as that thought might be.
1024core 9mo ago
Except when one of the criteria for promos is "demonstrates complexity". Then you results do matter, but you don't have the "complexity" box checked.
hrmtst93837 9mo ago
[flagged]

reactordev 9mo ago

This used to be true. Companies love efficiency. How does this stack up with modern AI? Seems those metrics would go in the opposite directions.

candiddevmike 9mo ago
The "time to market" folks finally have everything they could hope for, let's see all of that business value they claim is being missed due to pesky things like security, quality, and scalability checks.

nautilus12 9mo ago

You are citing negative metrics. The reality is that companies only care about positive metrics: increase marginal revenue by 30% That's regardless of the lip service they pay to cost cutting or risk reduction. It will only get worse, in the AI economy it's all about growth.

deleted 9mo ago

[deleted]

wccrawford 9mo ago

Absolutely. And if you asked them if they're rather have it sooner, or keep it simpler, they'd pick "sooner" every time.

withinboredom 9mo ago
I once used the analogy of the PM coming to the shop with a car that had a barely running engine and broken windows, and he's only letting me fix the windows. His response: "I can sell a good looking car and then charge them for a better running engine"... https://www.youtube.com/watch?v=T4Upf_B9RLQ https://www.youtube.com/watch?v=T4Upf_B9RLQ hits a little too close to home.

steveBK123 9mo ago

> "Reduced incidents by 80%", "Decreased costs by 40%", "Increased performance by 33% while decreasing server footprint by 25%" My experience is no one really gets promoted/rewarded for these types of things or at least not beyond an initial one-off pat on the back. All anyone cares about is feature release velocity. If it's even possible to reduce incidents by 80% then either your org had a very high tolerance for basically daily issues which you've now reduced to weekly, or they were already infrequent enough that 80% less takes you from 4/year to 1/year.. which is imperceptible to management and users.

ambicapter 9mo ago
You can reduce a single type of incident by 80%. The overall incident rate for this particular type wasn't high enough to kill your company, but it's still a big number on your promotion packet.
tripledry 9mo ago
> All anyone cares about is feature release velocity. And at the same time it's impossible to convince tech illiterate people that reducing complexity likely increases velocity. Seemingly we only get budget to add, never to remove. Also for silver bullets, if Big Tech promises a [thing] you can pay for that magically resolves all your issues, management seems enchanted and throws money at it.
deleted 9mo ago
[deleted]
jamiemallers 9mo ago
[dead]

praptak 9mo ago

You can't measure the impact of not creating a steaming pile of complexity.

nyeah 9mo ago
Really you can. You look at the engineers who create steaming piles, and you look at the ones who don't. Over a year or two, the difference is easy to spot. For people who care to spot it. If there's no competent front-line technical management who can successfully make this simple comparison, then, sure, in that case the team may be fucked.
- bagacrap 9mo ago
  I think this is often true and it's the limiting factor that prevents complexity from spiraling out of control. But there's also a certain type of engineer who generates Rube Goldberg code that actually works, not robustly, but well enough. A mad genius high on intelligence and low on wisdom, let's say. This is who can spin complexity into self reward.
- praptak 9mo ago
  Yes, I should have added "...this way" because I meant that to address GP's claim of the metric-based numerical measurement. In general, I agree that you can and should judge (not necessarily measure) thing like simplicity and good design. The problem is that business does want the "increased this by 80%, decreased that by 27%" stuff and simplicity does not yield itself to this approach.
  - deleted 8mo ago
    [deleted]
- cloverich 9mo ago
  It's easy to gloss over this assessment but ultimately this needs to be a key decision point for where you choose to work. No matter how well you manage complexity as an IC or a lower tier leader, if your upper tier of leaders don't value it, it won't last. Simplicity IME is not a "tail that wags the dog" concept. It's too easy to stomp out if nobody in power cares.

esprehn 9mo ago

Those verbs (reduced, decreased, increased) all assume the situation was "bad" already. Avoiding that in the initial design is what's poorly rewarded. Building a system that's fast on day one will not usually be rewarded as well as building a slow system and making it 80% faster.

bagacrap 9mo ago
Yes, and ironically there are promotion ladders that explicitly call out "staff engineers identify problems before they become an issue". But we all know that in reality no manager-leader is ever going to fix problems eagerly, if they even agree with someone's prediction that that thing is really going to become a problem.

Oras 9mo ago

Never seen these metrics in real life, especially in engineering.

vjvjvjvjghv 9mo ago

And mostly these numbers are made up BS. But management will eat them up.

erelong 9mo ago

"Code footprint is 80% more efficient / less" (when there is a simpler design over more complex "big ball of mud abomination" in contrast)

causal 9mo ago

Thanks for the sane take. This article is engagement-porn for every engineer who ever looked at a system they didn't understand and declared they could do it much simpler. It's not because people love to promote complexity-makers, soothing as that thought might be.

1024core 9mo ago

Except when one of the criteria for promos is "demonstrates complexity". Then you results do matter, but you don't have the "complexity" box checked.

hrmtst93837 9mo ago

[flagged]