One of my the papers I share around a lot is "Nobody ever gets credit for fixing problems that never happened (2002)"[1]. I like it because it's not purely about software so the examples resonate better with some exec level people in other teams I work with.
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.
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.
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.
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.
Measure no, but only engineers care about that (and I'm not even saying that they're right, engineers care a whole lot too much about hard data). You can show alternative solutions, estimate, make assumptions, even make up numbers and boom, you have "data" to show you improved things. You don't even have to lie: you can be very open that these are assumptions and made-up numbers, that it's just a story, what's important is that people come out with confidence that thanks to you, things are better by a bit/a lot/enormously.
You can. GitHub is about to hit zero nines of uptime[0].
But feedback like that is far too late to be useful.
Maybe (principal or senior) engineers should be the ones to judge, and be trusted by management that their foresight is worth pushing the deadline?
You can't. You can hypothesize about the counterfactual in which you shipped a "steaming pile of complexity," but you definitionally cannot measure something that does not exist.
One of my the papers I share around a lot is "Nobody ever gets credit for fixing problems that never happened (2002)"[1]. I like it because it's not purely about software so the examples resonate better with some exec level people in other teams I work with.
[1]https://ieeexplore.ieee.org/document/1167285
Yes, this is the real cause, and the OP explanation is just a symptom of that.
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.
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.
Except it's not something you can really accurately assess before you start working somewhere.
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.
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.
Measure no, but only engineers care about that (and I'm not even saying that they're right, engineers care a whole lot too much about hard data). You can show alternative solutions, estimate, make assumptions, even make up numbers and boom, you have "data" to show you improved things. You don't even have to lie: you can be very open that these are assumptions and made-up numbers, that it's just a story, what's important is that people come out with confidence that thanks to you, things are better by a bit/a lot/enormously.
You can. GitHub is about to hit zero nines of uptime[0]. But feedback like that is far too late to be useful. Maybe (principal or senior) engineers should be the ones to judge, and be trusted by management that their foresight is worth pushing the deadline?
[0]: https://mrshu.github.io/github-statuses/
You can't. You can hypothesize about the counterfactual in which you shipped a "steaming pile of complexity," but you definitionally cannot measure something that does not exist.
The impact is that you get to go solve another problem. This absolutely does show up in a good performance review.
Won't that show up in roi numbers?