[pjc50]

Software development is, apart from a few rare outposts like GOV.UK, conducted in the private sector for a profit.

That means that the number one consideration for the software is profitability. For internal-only software, this means that cost is the prime consideration.

In support of that, often software startups are trying to capture a winner-takes-all market, so time-to-market is critical.

Thirdly, consumer protection law is weak in the US, and product liability is almost nonexistant for software everywhere. The cost of failure is very low even if you leak all your customers' data or your product ceases to work after 18 months because you've "pivoted".

Fourthly, a lot of software is ""free"" or ad-funded. This further weakens the cost of failure.

There are techniques for delivering extremely high quality software. Few sectors of the industry care about them because it's not required and is unprofitable, but the aerospace people can usually get it right and the security people can usually get it right (when dealing with security products, not general purpose junk like Flash).

The automotive industry is kind of on a boundary. The Toyota "unintended acceleration" bug revealed some tremendously poor quality software. This is one of the main worries about self-driving cars: how minimal is the quality assurance going to be?

[alok-g]

Only thing I can add (indirectly covered in your comment) is that software companies are competing with each other too. So once quality vs. price bar gets set, it is hard for another company to offer a better quality while asking for a higher price. This is one of the reasons how a lot of software has gotten to ad-funded.

Dan Ariely (author of the book Predictably Irrational) called allowing free apps on AppStores to be a mistake made by the industry. The customers have now gotten used to free apps, making it harder for the industry/developers to offer better quality.

[pjc50]

Theoretically software products could compete on "quality", but this is quite rare because it's hard for the customers to measure. See https://en.wikipedia.org/wiki/The_Market_for_Lemons

I don't agree with the idea that free apps are inherently bad - that would rule out Open Source / Free Software, and it would also put the boundary vs "free" web pages in a strange place.

"Free"+adsupported and "Free"+IAPs have certainly produced some strange and terrible incentives though. As has the incredibly bad discovery process on app stores.

[alok-g]

We are mostly in agreement. See my other comment here: https://news.ycombinator.com/item?id=15532543

I do find open-source software to be generally lower in quality than paid products. Though there are many exceptions at this point in time where open-source is rather highly superior.

However, even in cases where someone could produce a better paid software for an open-source alternative, they practically cannot as it is hard to compete with free.

[tinus_hn]

In my opinion open source software typically has worse design but better implementation.

For instance, in the latest iOS there is a stupid bug where the calculator blocks the buttons if you press them too fast. So if you enter 1+2+3 the display will show 23.

In open source this would be trivial to fix. In closed source you have to wait for Apple to do its implementation, testing, distribution.

In open source you would have a customizable calculator with a million generally useless buttons though because it’s so easy to add them.

[fjsolwmv]

Ariely was talking about free crapware, not community ware. But even opensource only works in the community. Once you go to apptore you get tons of derivatives of open source stuff, laden with crap layers

[njarboe]

I think it is even worse than that. I would like to pay for all of my apps. I could not find any way on Android to filter out all of the free apps and just show ones that have a price.

[fjsolwmv]

You obviously don't want to pay for the same app+crap currently offered for free, but the purveyer would happily offer it for a fee. What you say you want isn't actually what you want. What you want is a quality filter. And that is what Apple claims to provide, and Google intentionally does not.

[twobyfour]

I would suggest that the problem is that the app stores don't properly support the free trial model.

I won't spend $10 on an app sight unseen because if it's crap or even just plain doesn't do what I need, there's no way to know that aside from trying to parse it out of the reviews that the developer probably bought from a spammer.

I will spend $10 in a heartbeat on an app that I've tried for two weeks and don't want to go back to living or working without.

But AFAICT, Apple explicitly forbids that business model in its store. Dunno whether or why Google Play apps don't use it more, tho.

[detaro]

Google Play also doesn't really have a good way of implementing that as far as I know. You can do free app and unlock via IAP, but no matter how clearly you spell it out on the page people will not read it and kill your ratings with "1-star, SCAM!" reviews.

Something like this really should be a store-level feature

[alok-g]

Indeed. I am often happy to pay the developer for a better software, but no such thing may even be available.

[ekr]

> the security people can usually get it right

Having worked for an AV vendor, I assure you that is not the case. Just check Project Zero[1], most of them do parsing of complex binary formats in kernel mode, 'nuff said.

This is just one example, but all major vendors have had issues:

[1]https://googleprojectzero.blogspot.ro/2016/06/how-to-comprom...

-----------------

OTOH, there are a few individuals who show a great deal of care about software correctness. Daniel Bernstein comes to mind, but many other people are offering big bounties for their personal projects, and have a track record of delivering correct software. But even in cases such as these, there are probably some hidden bugs in there, because of the inherent complexity. Nobody has the time to verify the fine interactions between the compiler, OS, libraries etc.

At the end of the day, if you want higher quality software, you have to incentivize it, as others have mentioned.

[fjsolwmv]

Parsing binary formats in kernel mode isn't more dangerous than text. Taking user input as executable instructions in your host computing environment is dangerous.

[fuzzfactor]

I just made a general comment above, but your message is very well put about software in particular.

Reading along with HN for a few years now is making me more terminology-oriented in areas of coding and capitalism, two of the major themes.

So to me it's only software if it's intended for sale (or profitable distribution), otherwise it's just computer programs.

Same with hardware, if it's not built for profit then it's not wares, just equipment.

Nothing wrong with building in quality for profit, but you may not be able to compete with low-quality-focused operators, especially ones which are strongly established.

[fjsolwmv]

OK but no one else uses your idiolect, so it's just making it hard to communicate.

[AnimalMuppet]

Two points:

First, to extend what you said about startups, you generally aren't totally sure that the market is really there. If it turns out that nobody cares about what you're building, it doesn't matter what quality you built it with. Therefore, as long as it's cheaper to build it with lower quality, startups are rational to build it with little concern for quality.

Second, Toyota: I'm not going to be any kind of apologist for Toyota's horrible software. From what I read about the situation, the way it was written was appalling. And they rightly got a lot of heat over it. (Arguably, they should have gotten more.)

But I wonder if the quality bar isn't being set too high in this situation. If Toyota didn't implement things in software, they would have had to implement it in hardware (either mechanical or electrical). That hardware would have some failure modes and failure rate. If the software has a lower failure rate than the hardware, that's progress, even if the software has a higher failure rate than it should have.

Our discussion of the Toyota flaws is colored by the fatalities. Still, hardware flaws can kill people, too...

[twobyfour]

But some of the stuff they're implementing in software wouldn't have to be implemented in hardware in a less high-tech car. It would just have manual controls for a human to operate the underlying hardware that the software is now meant to control.

[rahimnathwani]

Fourthly, a lot of software is ""free"" or ad-funded. This further weakens the cost of failure.

I'm not sure being ad-funded weakens the cost of failure. Losing users or having down time impacts revenue immediately if you're ad-funded.

[pjc50]

Yes, but the users aren't going to ask for refunds. Also they feel that because it's free they aren't really entitled to customer service (and you certainly wouldn't offer them any).

[rahimnathwani]

Your original seems to suggest that loss of revenue from software not working will be more severe for directly-paid software than for ad-supported software. It's not clear to me that's the case, especially given that some of the highest revenue software currently in use (consumer services from FB etc.) is ad-supported.

Anyway, this is tangential to this thread, so I won't go on about it.

[notlob]

> The Toyota "unintended acceleration" bug revealed some tremendously poor quality software.

Did Toyota ever recall the affected ETCs?

[fsloth]

"aerospace people can usually get it right "

Are you refererring to adherence to standards like Misra and DO-178B or something else?

[pjc50]

Yes, that kind of thing. The observed failure rate is pretty low although there have been a few high profile incidents (A400M, the whole Chinook fiasco http://www.computerweekly.com/blog/Public-Sector-IT/One-of-t... )

The Chinook fiasco is, like most quality issues, really a project management fiasco. The decision to do special software rather than get Boeing to do it, then a series of oversight failures on known problems.

[mannykannot]

Adherence to standards is a means to an end, but it is neither an end in itself, nor a guarantor of that end.

[fsloth]

Sure, stupid tools are pointless. But usefull tools...

If the point is to reduce the number of errors then it helps to at least have a checklist of the errors, and someone reminding the team of the checklist. Checklist process is one of the easiest quality and safety tools to implement.

Having a premade checklist that makes sense in the form of a process plan makes things easier.

[mannykannot]

Exactly - a means to an end.

I'm not sure why you are mentioning "stupid tools", whatever they are - they would not even be means to an end.

[Spearchucker]

I was going to say that we still seem to measure everything except code quality - your answer is way more insightful though.

[joelthelion]

> That means that the number one consideration for the software is profitability. For internal-only software, this means that cost is the prime consideration.

> In support of that, often software startups are trying to capture a winner-takes-all market, so time-to-market is critical.

I think we software engineers should embrace this reality, and learn to live with it. Your employer is willing to spend years to develop top-notch quality software? Great, you can employ all the software engineering best practices. That's not the case? Well, we should have a standard approach for gracefully handling strong time constraints without completely giving up on quality.

[smackay]

Therein lies the disconnect between what we want to achieve as a profession and the commercial needs of companies. Too often these are conflated in our view of what we do and that creates unhappy developers pushed to deliver stuff quickly is the result.

One way this unhappiness with our lot is expressed is Technical Debt. For me this just cognitive dissonance on the developers part trying to reconcile / justify why the codebase is a mess and why all those shortcuts were taken to get the thing shipped. If you want to pursue your craft and deliver a result you would be proud of then probably commercial software companies are not for you.

Well all might be great writers at heart but if all the employers want is a pool of people to write pulp fiction and romance novels the sooner we get over it the better.

Of course one solution to this identity crisis is sort of mapped out with Erik Dietrich's Developer Hegemony, https://leanpub.com/developerhegemony but it might take a while to get there.