5 ms·

Something I found annoying at a previous big-tech work, was how the focus on top-level metrics (read, revenue-linked metrics) meant we couldn't fix things. The

by aylmao 2y ago

Something I found annoying at a previous big-tech work, was how the focus on top-level metrics (read, revenue-linked metrics) meant we couldn't fix things. There were a lot of smart people, very interested in fixing things— not only because engineers tend to like fixing things, but also because we, and everyone around us, were users too. For example, many things related to text input were broken on the site. Korean was apparently quite unusable. I wanted to fix it. A Korean manager in a core web team wanted to fix it. But we couldn't because the incentive structures dictated we should focus on other things. It was only after a couple years, and developing a metric that linked text-input work with top-level (read, revenue-linked) metrics, that we were able to work on fixing these issues. I find a lot of value in the effort to make incentives objective, but at a company that was already worth half a trillion dollars at the time, I just always felt there could be more room for caring about users and the product beyond the effects on the bottom-line.

aikinai 2y ago
This is exactly the problem. Hyper efficient (or at least trying to be) businesses have no room for craftsmanship. If you take the time to make quality software, you’ll be left behind by someone who doesn’t. Unfortunately the market doesn’t care, and therefore efficient businesses don’t either. The only solution I know of is to have a business that’s small enough and controlled by internal forces (e.g. a founder who cares) to pay attention to craftsmanship.
fauigerzigerk 2y ago
You're implying that buggy software has no impact on the bottom line. I'm not so sure. Users weigh the availability of features against the quality of features. Getting bugs fixed is not necessarly the highest priority for users either. It's a trade-off. Our use of Microsoft 365 is a pretty good example of that. I moved our company to Microsoft 365 because it had some features we wanted. Then I moved the company off Microsoft 365 because it turned out to be too buggy to be useful. I realise that the actual users of software are not necessarily the same people making the purchasing decisions. But if productivity suffers and support costs rise then the consequences of choosing low quality software eventually filters through to purchasing decisions.
- Cthulhu_ 2y ago
  > You're implying that buggy software has no impact on the bottom line. I'm not so sure. Users weigh the availability of features against the quality of features. The problem is that managers / those that determine priorities don't get the numbers, they don't see a measurable impact of buggy software. There's only two signals for that, one is error reporters - which depend on an error being generated, that is, software bug - and the other is user reporting, but only a small fraction of users will actually bother to make reports. I think this is a benefit of open source software, as developers are more likely to provide feedback. But even then you have some software packages that are so complex and convoluted that bugs emerge as combinations of many different factors (I'm thinking of VS Code with its plugins as an example) that the bug report itself is a huge effort.
  - fauigerzigerk 2y ago
    >The problem is that managers / those that determine priorities don't get the numbers, they don't see a measurable impact of buggy software. I don't believe that. IT departments have to support users. Users complain and request support. It costs money and it affects productivity and everybody knows it. But that's not enough. You would also have to believe that there are significantly less buggy alternatives and that the difference justifies the cost of switching. For big companies that is an incredibly high bar. But small companies do dump software providers like my company dumped Microsoft. [Edit] Ah, I think I misunderstood. You're looking at it from the software provider's perspctive rather than the user organisation. Got it.
- citrin_ru 2y ago
  Even if buggy software has an impact on the buttom line, managers can continue pretending it doesn't and not allocate any budget to fix them. They assume bug fixes somehow will be squeezed in between the work they really value - new features or better completely new projects. Because creating something new (asking debelopers to create) is the easiest way for a manager to get a promotion. It was many years ago when I last seen a manager (with the power to set priorties and not just translate them form above) who pays more than a lip service to quality and cares about maintenance.

by aylmao 2y ago

aikinai 2y ago

This is exactly the problem. Hyper efficient (or at least trying to be) businesses have no room for craftsmanship. If you take the time to make quality software, you’ll be left behind by someone who doesn’t. Unfortunately the market doesn’t care, and therefore efficient businesses don’t either. The only solution I know of is to have a business that’s small enough and controlled by internal forces (e.g. a founder who cares) to pay attention to craftsmanship.

fauigerzigerk 2y ago

You're implying that buggy software has no impact on the bottom line. I'm not so sure. Users weigh the availability of features against the quality of features. Getting bugs fixed is not necessarly the highest priority for users either. It's a trade-off. Our use of Microsoft 365 is a pretty good example of that. I moved our company to Microsoft 365 because it had some features we wanted. Then I moved the company off Microsoft 365 because it turned out to be too buggy to be useful. I realise that the actual users of software are not necessarily the same people making the purchasing decisions. But if productivity suffers and support costs rise then the consequences of choosing low quality software eventually filters through to purchasing decisions.

Cthulhu_ 2y ago
> You're implying that buggy software has no impact on the bottom line. I'm not so sure. Users weigh the availability of features against the quality of features. The problem is that managers / those that determine priorities don't get the numbers, they don't see a measurable impact of buggy software. There's only two signals for that, one is error reporters - which depend on an error being generated, that is, software bug - and the other is user reporting, but only a small fraction of users will actually bother to make reports. I think this is a benefit of open source software, as developers are more likely to provide feedback. But even then you have some software packages that are so complex and convoluted that bugs emerge as combinations of many different factors (I'm thinking of VS Code with its plugins as an example) that the bug report itself is a huge effort.
- fauigerzigerk 2y ago
  >The problem is that managers / those that determine priorities don't get the numbers, they don't see a measurable impact of buggy software. I don't believe that. IT departments have to support users. Users complain and request support. It costs money and it affects productivity and everybody knows it. But that's not enough. You would also have to believe that there are significantly less buggy alternatives and that the difference justifies the cost of switching. For big companies that is an incredibly high bar. But small companies do dump software providers like my company dumped Microsoft. [Edit] Ah, I think I misunderstood. You're looking at it from the software provider's perspctive rather than the user organisation. Got it.
citrin_ru 2y ago
Even if buggy software has an impact on the buttom line, managers can continue pretending it doesn't and not allocate any budget to fix them. They assume bug fixes somehow will be squeezed in between the work they really value - new features or better completely new projects. Because creating something new (asking debelopers to create) is the easiest way for a manager to get a promotion. It was many years ago when I last seen a manager (with the power to set priorties and not just translate them form above) who pays more than a lip service to quality and cares about maintenance.