Hacker News Reader

Comment by fauigerzigerk | Hacker News Reader

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.

View on HN

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.

> 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.

>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.

> You're implying that buggy software has no impact on the bottom line. I'm not so sure.

The problem is that very little competition exists for computer operating systems. Apple, Google, and Microsoft collectively control nearly all of the consumer OS market share on both desktop and mobile. Thus, macOS just needs to be "better than Windows", and iOS just needs to be "better than Android".

> Then I moved the company off Microsoft 365 because it turned out to be too buggy to be useful.

What did you move to?

In general, Microsoft 365 is extremely successful, despite any bugs. There doesn't appear to be any imminent danger of financial failure.

Software vendors also face tradeoffs, engineering hours spent on fixing bugs vs. writing new features. From a bean counter's perspective, they can often live with the bugs.

> In general, Microsoft 365 is extremely successful, despite any bugs.

That's because of some very hard monopolistic anti-consumer behavior from Microsoft in their ecosystem.

> You're implying that buggy software has no impact on the bottom line.

I'm not implying that, and I don't think my manager was implying that either. I think rather there were 2 things going on:

1. It's often hard to connect bug-fixing to metrics.

A specific feature change can easily be linked with an increase in sales, or an increase in usage. It's much harder to measure the impact of a bugfix. How can you measure how many people are _not_ churning thanks to a change you pushed? How can you claim an increase in sales is due to a bugfix?

In your case, I'm sure some team at Microsoft has a dashboard that was updated the minute you used one of these features you bought Microsoft 365 for. How could you build something similar for a bugfix?

Bugfixes don't tend make the line go up quickly. If they make the line go up it often is a slow increase of regained users that's hard to attribute to the bugfixes alone. Usually you're trying to measure not an increase, but a "not decrease", which if possible is tricky at best. The impact is intuitively clear to anyone who uses the software, but hard to measure in a graph.

2. A ruthless prioritization of the most clearly impactful work.

I wouldn't have minded working on something less-clearly measurable which I nonetheless thought was important. But my manager does care though because their performance is an aggregate of all those measurable things the team has worked on. And their manager cares, and so on and so forth.

So at the end of the day, in broad strokes, unless the very top (which tends to be much more disconnected from triage and edge-cases) "doesn't mind" spending time on less measurable things like bugfixing, said bugfixing will be incentivized against.

I think we all know this impacts the bottom-line. Everyone knows people prefer to use software that is not buggy. But a combination of "knowing is not enough, you have to show it" and "don't work on what you know, you have to prioritize work on what is shown", makes for active disincentivizing of bug-fixing work.

Reply on news.ycombinator.com