4 ms·

> 30 years ago, nobody in their right mind would have thought "du'h, I'll just recursively scan whatever directory THIS environment variable points at and then

> 30 years ago, nobody in their right mind would have thought "du'h, I'll just recursively scan whatever directory THIS environment variable points at and then apply whatever this library does to each file in it to get some list and then extract the files I need from that list".. I think plenty of people would have made the error of filtering after applying an expensive operation than before. This seems like a classic rookie mistake, not an indication of some paradigm shift in thinking. What was impressive was that no one at Rockstar thought of improving the loading performance for so long that a use decided to reverse-engineer it.

yellow_lead 4y ago
I think some of these issues should be looked through a lens of incentives though as well. At my previous job, management didn't care much about performance improvements or bug fixes, they care more about delivering projects or big features. Fixing stuff like this wouldn't help you get promoted.
- dusted 4y ago
  Absolutely, from a local perspective, decisions (or lack thereof) in regards to performance and efficiency make perfect sense, they simply shift the cost to the customer.. Pay less for development at the cost of performance which the customer will pay for with more computing capacity, electricity and time. It scales terribly though, something that may cost an additional $20000 in development cost, may cost each customer a few tens of dollars over the lifetime of the product (not including putting a price on frustration and quality of life).. But if they have a few million customers using that feature, it's terrible for society and the greater economy/ecology. Not only due to electricity, but also the high rate of replacing perfectly working computing equipment for higher-performing, only to spend any additional capacity running increasingly crappy and demanding software.
- vultour 4y ago
  Excuse my ignorance as I work in infrastructure, but do "pure" software engineers never have any time to do work outside of their assignments? Is it constant agile crunch to smash as many story points as possible into the current sprint?
  - pjmlp 4y ago
    Unless it can be made billable it is usually frowned upon.
  - pacifika 4y ago
    In an agency setting anyways the percentage of billable time is usually a kpi
  - loup-vaillant 4y ago
    In some places, such as the one I'm working in right now, explicitly discourage working on anything but what you've been assigned. I've even been scolded from taking items from the next sprint when I was done with the current (and in no position to really help my colleagues).
  - dusted 4y ago
    In my experience, pretty close to constantly working on whatever has been prioritized from above and needing actively to push back and have exceptionally good arguments for improving things that are not in scope.
  - Manuel_D 4y ago
    > Excuse my ignorance as I work in infrastructure, but do "pure" software engineers never have any time to do work outside of their assignments? A valid point, but that just kicks the same question down the road: why was no engineer assigned to investigate loading times? That might be indicative of a culture that is biased towards projects with an outcome decided a priori. A lot of managers don't want to assign tasks where the definition of "done" is ambiguous.
  - michaelt 4y ago
    Almost every developer can fit a bit of discretionary work into their existing stories. You can polish up the performance when you first code it. Almost every employer also has a bunch of things they'd like you to do outside of your stories - mentoring junior developers, recruiting, planning, team building, professional development. Some employers have SOC2 compliance policies that all changes should be traceable to a documented requirement, so fixes after the change is complete can be a bit more bureaucratic. If the project is behind schedule, the bosses might want you to work on something else instead. Many developers are given pretty high-spec machines, so they can compile quickly and run weighty IDEs and so on - meaning an issue that's painful for users with 2GB of RAM and 2 CPU cores might be barely noticeable to users with 32GB of RAM and 8 cores. And of course, some workplace cultures would say if you've 'got your work done' you can do discretionary performance work or you can leave early - and who'd choose performance work over spending time with their loved ones?
- ajyotirmay 4y ago
  This is the exact issue I face at my present job. Our clients have low budgets for hosting, and that means code needs to be as optimized as possible. Sadly, the people I report to don't care enough about it. All they want is to push through the visible changes as fast as possible. And every single time these performance bugs come to bite us. Our solution? Scale the system resources. I'm not particularly satisfied with the work. But as an engineer I don't get to call the shots.
- projektfu 4y ago
  Eventually, this attitude develops software that takes all day to generate erroneous results and nobody really understands the code because it was all added quickly without refactoring. It's the dark side of "Do the Simplest Thing that could Possibly Work" which is probably the most misunderstood practice in XP. At that point, every developer on the team becomes an interchangeable useless warm body and the promotion goes to the "rock star" from outside who comes in and rewrites it or surgically fixes the top performance issues.
P5fRxh5kUvp2th 4y ago
Plenty of people would have made the mistake, few would have left it there for years after performance was absymal.

yellow_lead 4y ago

I think some of these issues should be looked through a lens of incentives though as well. At my previous job, management didn't care much about performance improvements or bug fixes, they care more about delivering projects or big features. Fixing stuff like this wouldn't help you get promoted.

dusted 4y ago
Absolutely, from a local perspective, decisions (or lack thereof) in regards to performance and efficiency make perfect sense, they simply shift the cost to the customer.. Pay less for development at the cost of performance which the customer will pay for with more computing capacity, electricity and time. It scales terribly though, something that may cost an additional $20000 in development cost, may cost each customer a few tens of dollars over the lifetime of the product (not including putting a price on frustration and quality of life).. But if they have a few million customers using that feature, it's terrible for society and the greater economy/ecology. Not only due to electricity, but also the high rate of replacing perfectly working computing equipment for higher-performing, only to spend any additional capacity running increasingly crappy and demanding software.
vultour 4y ago
Excuse my ignorance as I work in infrastructure, but do "pure" software engineers never have any time to do work outside of their assignments? Is it constant agile crunch to smash as many story points as possible into the current sprint?
- pjmlp 4y ago
  Unless it can be made billable it is usually frowned upon.
- pacifika 4y ago
  In an agency setting anyways the percentage of billable time is usually a kpi
- loup-vaillant 4y ago
  In some places, such as the one I'm working in right now, explicitly discourage working on anything but what you've been assigned. I've even been scolded from taking items from the next sprint when I was done with the current (and in no position to really help my colleagues).
- dusted 4y ago
  In my experience, pretty close to constantly working on whatever has been prioritized from above and needing actively to push back and have exceptionally good arguments for improving things that are not in scope.
- Manuel_D 4y ago
  > Excuse my ignorance as I work in infrastructure, but do "pure" software engineers never have any time to do work outside of their assignments? A valid point, but that just kicks the same question down the road: why was no engineer assigned to investigate loading times? That might be indicative of a culture that is biased towards projects with an outcome decided a priori. A lot of managers don't want to assign tasks where the definition of "done" is ambiguous.
- michaelt 4y ago
  Almost every developer can fit a bit of discretionary work into their existing stories. You can polish up the performance when you first code it. Almost every employer also has a bunch of things they'd like you to do outside of your stories - mentoring junior developers, recruiting, planning, team building, professional development. Some employers have SOC2 compliance policies that all changes should be traceable to a documented requirement, so fixes after the change is complete can be a bit more bureaucratic. If the project is behind schedule, the bosses might want you to work on something else instead. Many developers are given pretty high-spec machines, so they can compile quickly and run weighty IDEs and so on - meaning an issue that's painful for users with 2GB of RAM and 2 CPU cores might be barely noticeable to users with 32GB of RAM and 8 cores. And of course, some workplace cultures would say if you've 'got your work done' you can do discretionary performance work or you can leave early - and who'd choose performance work over spending time with their loved ones?
ajyotirmay 4y ago
This is the exact issue I face at my present job. Our clients have low budgets for hosting, and that means code needs to be as optimized as possible. Sadly, the people I report to don't care enough about it. All they want is to push through the visible changes as fast as possible. And every single time these performance bugs come to bite us. Our solution? Scale the system resources. I'm not particularly satisfied with the work. But as an engineer I don't get to call the shots.
projektfu 4y ago
Eventually, this attitude develops software that takes all day to generate erroneous results and nobody really understands the code because it was all added quickly without refactoring. It's the dark side of "Do the Simplest Thing that could Possibly Work" which is probably the most misunderstood practice in XP. At that point, every developer on the team becomes an interchangeable useless warm body and the promotion goes to the "rock star" from outside who comes in and rewrites it or surgically fixes the top performance issues.

P5fRxh5kUvp2th 4y ago

Plenty of people would have made the mistake, few would have left it there for years after performance was absymal.