4 ms·

How did the team report out things that weren’t new features? Performance improvements and bug fixes are often more important than adding more stuff to the prod

How did the team report out things that weren’t new features? Performance improvements and bug fixes are often more important than adding more stuff to the product.

yurishimo 3y ago
I had a similar report structure, and generally we would relay the same information. "Here's a graph of measurements from before and after the code change, showing a 20% reduction in resources saving us $X/year". Generally that was good enough.
- mdorazio 3y ago
  I like this approach with a graph. In the past I’ve run into people ignoring text bullets about the “boring” development wins.
cookie_monsta 3y ago
Is there some reason you can't report on performance improvements and bug fixes?
- itsoktocry 3y ago
  >Is there some reason you can't report on performance improvements and bug fixes? Exactly. What does "performance improvement" even mean if you aren't measuring performance before and after?
- feoren 3y ago
  Because a shiny new feature that takes 1/10th of the time gets 10x more praise and attention. Because naive senior vice president MBAs believe there never should have been bugs in the first place, and every fix is an admission that the bug existed at all. Because every email is now a weekly contest between teams, and when hard times come the ones who reported on performance improvements and bug fixes will lose their jobs long before the ones who made the header the president's favorite color. Because every email is your team trying to convince the company of your own worth and it's much harder to show a pretty screenshot of a performance improvement than a new feature (Graphs of before/after performance every week? Every week?) Because bugs don't always follow your bullshit schedule made by a bullshit manager who is looking for a pat on the back by replacing bullshit A with bullshit B, instead of anyone anywhere in the company ever just trusting anyone.
darkwater 3y ago
Not GP but what about: - Improved p50 latency of endpoint /very/important/endpoint by 22% [attached mini-graph showing the change] - Fixed this bug that had been reported by 37 clients in the last 30 days as seldomly affecting them etc
hliyan 3y ago
E.g. "Foobar page for lists larger than 1000 now load in under 3 seconds, down from 10 earlier", "You no longer have to log out and login again when we update config Y", "Now when you report money mismatches, you no longer have to send screen shots (we have added logs)" etc.

How did the team report out things that weren’t new features? Performance improvements and bug fixes are often more important than adding more stuff to the product.

yurishimo 3y ago

I had a similar report structure, and generally we would relay the same information. "Here's a graph of measurements from before and after the code change, showing a 20% reduction in resources saving us $X/year". Generally that was good enough.

mdorazio 3y ago
I like this approach with a graph. In the past I’ve run into people ignoring text bullets about the “boring” development wins.

cookie_monsta 3y ago

Is there some reason you can't report on performance improvements and bug fixes?

itsoktocry 3y ago
>Is there some reason you can't report on performance improvements and bug fixes? Exactly. What does "performance improvement" even mean if you aren't measuring performance before and after?
feoren 3y ago
Because a shiny new feature that takes 1/10th of the time gets 10x more praise and attention. Because naive senior vice president MBAs believe there never should have been bugs in the first place, and every fix is an admission that the bug existed at all. Because every email is now a weekly contest between teams, and when hard times come the ones who reported on performance improvements and bug fixes will lose their jobs long before the ones who made the header the president's favorite color. Because every email is your team trying to convince the company of your own worth and it's much harder to show a pretty screenshot of a performance improvement than a new feature (Graphs of before/after performance every week? Every week?) Because bugs don't always follow your bullshit schedule made by a bullshit manager who is looking for a pat on the back by replacing bullshit A with bullshit B, instead of anyone anywhere in the company ever just trusting anyone.

darkwater 3y ago

Not GP but what about: - Improved p50 latency of endpoint /very/important/endpoint by 22% [attached mini-graph showing the change] - Fixed this bug that had been reported by 37 clients in the last 30 days as seldomly affecting them etc

hliyan 3y ago

E.g. "Foobar page for lists larger than 1000 now load in under 3 seconds, down from 10 earlier", "You no longer have to log out and login again when we update config Y", "Now when you report money mismatches, you no longer have to send screen shots (we have added logs)" etc.