Hacker News Reader

Comment by eyelidlessness | Hacker News Reader

> In my view, a manufacturer should work on software quality until they can state on the box "If there is ever one glitchy weird thing that requires a reboot to fix, we'll give you a full refund".

As a developer, I fall very near the total perfectionist end of the spectrum in my preferences, but what you’re asking for would probably mean ~nothing ever ships.

It’s not that provably correct code is impossible, it’s that the economies of software (even free/open/labors of love) and physics (time) impose tradeoffs for the vast vast majority of software people write outside a research context.

I too wish software quality was substantially better. I put a lot of effort into not only making it better, but making it easier to make better software in the first place. But the level of perfection you’re describing is unrealistic.

View on HN

There are plenty of other branches of engineering with similar reliability goals. When I eat my lunch with a fork, I expect the prongs of the fork not to fall off... And so far, in my whole life of using forks, the prongs have never fallen off. The fork has been 100% reliable. It has always worked.

And before you say a fork is unrealistically simple, a metal fork is still the result of centuries of metalworking, casting, mining, etc. I'm sure some early forks did fall apart. But now, we have it refined, and they're close enough to bug-free.

I think the way to achieve it is to have a fixed feature set that you never add to.

I don’t think even your proposed solution would yield the results you’re seeking. Even if the software were provably correct and never updated, it has to operate on hardware. Hardware will fail. Battery life will degrade, screens will crack, power cables will fray. Even other (real) engineering disciplines don’t guarantee 0% failure, they guarantee tolerances.

Metal forks don’t lose a prong, but their prongs do bend. They do get scraped in garbage disposals. They do get hot when left too long on a heated surface. Some (silver) forks are considerably softer, amplifying those failure modes. And while I’m sure there must be fork vendors who offer solutions with guarantees against those failure modes—there are niche products for nearly every imaginable niche—the vast majority of people knowingly buy forks with these known limitations, trading some reliability for economy and utility. If everyone had the expectations you seem to have, very few people could afford forks at all, and they very well may not have been developed because the market would be so small.

That is probably true, but a zero vision is a very nice goal to aspire to (and perhaps not too unrealistic, who knows the potential of languages, hardware and new developments?).

In any case, tying quality to some tangible, bold measurement like refunds is not a bad idea.

Not necessarily a refund, but some sort of compensation could be in order. “A reboot has occurred. For this inconvenience, we have credited the CC associated with your AppleID $2, (or $5 Applebucks or a free coffee).” Design out the potential for gaming the system for infinite coffees.

If you impose a cost on a user, you compensate the user for that cost. I think that is the basic idea behind tort law. To keep lawyers and associated expense out of the system, do it voluntarily.

But if voluntary compensation of users is being ignored, a change in liability doctrine for software might be in order. Start with the biggest players who can afford the legal costs to resolve the doctrinal issues.

The target isn't zero errors. It's low enough that offering a refund to any user who sees one is financially viable.

You already offer a refund to users where the hardware fails. Why not the same for the software?

Reply on news.ycombinator.com