4 ms·

There’s also a mitigating liability aspect to this. If you start providing minutiae detail, you may start revealing pretty big faults that have escaped to prod.

There’s also a mitigating liability aspect to this. If you start providing minutiae detail, you may start revealing pretty big faults that have escaped to prod. People question the safety of your product and now you’re open to lawsuit or at least micromanaged by some unforgiving end-customers. To cope, you start to not fix certain problems so you won’t have to report the bugs or you start lying what the bugs were. I’m not so sure it’s on net a useful direction to be quite that open.

maxerickson 6y ago
Aren't the flaws the sources of the liabilities?
- curryst 6y ago
  Sure, but most people accept that flaws are inevitable. It's not practical (or profitable) for most industries to produce totally flaw-free software. If you can't stop the flaws, the next best option is to shield yourself from those flaws harming your financial well being.
  - pc86 6y ago
    Having a changelog does not make you more open to lawsuits.
    - lmz 6y ago
      A detailed changelog wouldn't change the facts, but it just provides more free information to potential plaintiffs.
WesolyKubeczek 6y ago
This explanation doesn't make me empathetic at all, and lousy changelogs are still lousy.
julik 6y ago
This is likely why useful and important details in changelogs are suppressed. Products where owners/managers value and emphasise transparency are much better at this, but it requires a specific culture. I mean - it does take guts to say "All media in the application could be downloaded without authentication by anybody on the internet. This has now been fixed."
wbl 6y ago
Has there ever been a lawsuit in which a company was held liable for bugs despite the usual disclaimer?
Nextgrid 6y ago
Let’s stop condoning covering up incompetence. If you fuck up, admit to it, fix it and learn from it. If you fuck up bad enough that someone had a good case against you then you should make them whole and use the opportunity as a wake-up call to make sure this never happens.
pjc50 6y ago
Are there ever successful software product quality liability lawsuits?
- deleted 6y ago
  [deleted]
WalterBright 6y ago
Back in the 80s when I was starting out in the compiler business, I thought it would be a good service to include with it a list of the known bugs. It didn't take long before a magazine reviewer did a compiler roundup and simply printed the bug list as his "review". It was a disaster for my business. It took me 20 years to get over being brutalized by that and make the bug list publicly available again. https://issues.dlang.org/ https://issues.dlang.org/
- leesalminen 6y ago
  I had a competitor do something like this to me in the 10s. We had a structured weekly/monthly small/big release cadence compared to their bi-annual update. When we started thoroughly documenting our bug-fixes publicly, they used that against us in negotiations on a large deal. Basically alluding that our software was buggy, seeing that we had something to fix every week. Luckily we thwarted that logical fallacy by asking how many bug fixes they did last year and had no real answer. People suck. Glad to hear you’ve overcome the fear on this, it’s worth it and I also still maintain a public list of bug fixes.
gregmac 6y ago
The take-away from this is if a vendor doesn't provide a good changelog, it's fair to assume they're trying to cover up incompetence (or some other shortcoming). With good automated testing, a bug recurring should be extremely rare. A piece of the software that constantly has bugs is a sign there's high technical debt that needs to be addressed. New features consistently not working could be a sign of a problem in the team/org itself (not the right people, enough people, or enough time allocated). Even with all the best practices, big faults will make it through sometimes -- that's just the nature of most software dev. I think the best way to handle them is be transparent, but also be specific. "Fix bug where entire database can be corrupted" will cause you a lot of grief (rightfully so). Something like "Fix critical data corruption bug when saving a record containing specific trailing unicode characters on systems with libzip 1.3.3 or earlier installed" is much better and helps reinforce that: 1. You have thoroughly investigated the problem 2. The scope of problem is limited, and doesn't affect all customers (even though it could be most) 3. It's understandable how such a bad bug could happen and why testing didn't catch it

maxerickson 6y ago

Aren't the flaws the sources of the liabilities?

curryst 6y ago
Sure, but most people accept that flaws are inevitable. It's not practical (or profitable) for most industries to produce totally flaw-free software. If you can't stop the flaws, the next best option is to shield yourself from those flaws harming your financial well being.
- pc86 6y ago
  Having a changelog does not make you more open to lawsuits.
  - lmz 6y ago
    A detailed changelog wouldn't change the facts, but it just provides more free information to potential plaintiffs.

WesolyKubeczek 6y ago

This explanation doesn't make me empathetic at all, and lousy changelogs are still lousy.

julik 6y ago

This is likely why useful and important details in changelogs are suppressed. Products where owners/managers value and emphasise transparency are much better at this, but it requires a specific culture. I mean - it does take guts to say "All media in the application could be downloaded without authentication by anybody on the internet. This has now been fixed."

wbl 6y ago

Has there ever been a lawsuit in which a company was held liable for bugs despite the usual disclaimer?

Nextgrid 6y ago

Let’s stop condoning covering up incompetence. If you fuck up, admit to it, fix it and learn from it. If you fuck up bad enough that someone had a good case against you then you should make them whole and use the opportunity as a wake-up call to make sure this never happens.

pjc50 6y ago

Are there ever successful software product quality liability lawsuits?

deleted 6y ago
[deleted]

WalterBright 6y ago

Back in the 80s when I was starting out in the compiler business, I thought it would be a good service to include with it a list of the known bugs. It didn't take long before a magazine reviewer did a compiler roundup and simply printed the bug list as his "review". It was a disaster for my business. It took me 20 years to get over being brutalized by that and make the bug list publicly available again. https://issues.dlang.org/ https://issues.dlang.org/

leesalminen 6y ago
I had a competitor do something like this to me in the 10s. We had a structured weekly/monthly small/big release cadence compared to their bi-annual update. When we started thoroughly documenting our bug-fixes publicly, they used that against us in negotiations on a large deal. Basically alluding that our software was buggy, seeing that we had something to fix every week. Luckily we thwarted that logical fallacy by asking how many bug fixes they did last year and had no real answer. People suck. Glad to hear you’ve overcome the fear on this, it’s worth it and I also still maintain a public list of bug fixes.

gregmac 6y ago

The take-away from this is if a vendor doesn't provide a good changelog, it's fair to assume they're trying to cover up incompetence (or some other shortcoming). With good automated testing, a bug recurring should be extremely rare. A piece of the software that constantly has bugs is a sign there's high technical debt that needs to be addressed. New features consistently not working could be a sign of a problem in the team/org itself (not the right people, enough people, or enough time allocated). Even with all the best practices, big faults will make it through sometimes -- that's just the nature of most software dev. I think the best way to handle them is be transparent, but also be specific. "Fix bug where entire database can be corrupted" will cause you a lot of grief (rightfully so). Something like "Fix critical data corruption bug when saving a record containing specific trailing unicode characters on systems with libzip 1.3.3 or earlier installed" is much better and helps reinforce that: 1. You have thoroughly investigated the problem 2. The scope of problem is limited, and doesn't affect all customers (even though it could be most) 3. It's understandable how such a bad bug could happen and why testing didn't catch it