Ask HN: Why is software quality an afterthought for many people/companies?

A thought: The slightest design flaw or manufacturing flaw in a microprocessor or memory chip can reduce its value to zero. Generally, flaws in software are easier to correct and don't have the same catastrophic effect on value.

Minimum Viable Product

In fact these days, people kinda know what they want, but really only understand what they want when they have something in front of them. I'd go so far as to suggest you can over-engineer a solution too easily and then spend a lot of time refactoring it. YMMV

Because of the fact that software is seen as a cost center rather than as a means of production. If you were to factor quality in right at the start most projects would never be approved and so we try to 'fix' the problem at two minutes to twelve.

This is also a large factor in why software projects tend to overrun both in terms of time and budget (the other large factor is bad project management).

Anything that you're not explicitly optimising for, you're optimising against.

And companies are built to optimise other stuff.

To most businesses, the core objective is creating a profitable business, and most other objectives, including engineering, marketing, support, and yes, in many companies even things like customer and employee satisfaction, are secondary to that, and only really prioritized to the extent that improving those areas also improves the bottom line (I would in fact argue that this is true of almost all companies, and that the difference in whether they prioritize customer and employee satisfaction or not, is mostly a matter of whether they look at the impact on the bottom line in a short-sighted manner, or in a more long-term way).

So in regards to your question, it would seem that the market reality is that a lot of the time, it is better for a company to have a quickly-cobbled-together piece of software that mostly does what the customers want (and maybe get to the market first) even if it is low-quality, than it is to have a piece of high-quality software that does less, or is finished later, but is maintainable, and potentially scalable in the future (which you'll never get to enjoy because the worse-is-better people already conquered the market).

I working in consulting, and in a lot of cases while we're well intentioned in delivering quality software, we're forced to fight against clients in time, budget, scope creep etc.

Sadly, things sometimes get rushed out the door and it's not until some time has passed that they realise the enormous tech debt they've incurred.

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?

Any organization that has a "normal" modern development process (Code reviews, Reasonable test suite, continuous builds, static analysis etc) has a decent focus on quality. That doesn't mean quality has the focus it needs within the organization but at least its then not secondary or a focus for late in the process.

In Peopleware, Tom DeMarco thinks it's because a business's customers will tolerate lower quality software, so there are diminishing marginal returns to revenue as investment in software quality continues. He predicts that while this management style works wonderfully for the bottom line in the short run, it causes long-term ailments such as team dissatisfaction, overly complex architectures, and other issues that may be more expensive overall.

Quality and security become increasingly important as we depend even more on software systems for essential functions such as cars, power grid management, agriculture, etc. Unfortunately, this situation is all too similar to how many opt for the emergency room over preventative care.

We should also consider that many businesses wouldn't exist if not for lax quality requirements for software products. How many product V1s are chock full of bugs and exploits, and to what extent is that okay? What about open source? As usual, it's pretty complicated.

If software is created within a profit oriented organisation, then there is a rush to get stuff out the door. Quality is seen as an expensive intangible. Managers are focused on time to market - the shorter the better and costs - the lower the better.

When software is created without a profit motive, then it is to coolness of the idea that motivates the creators. Focusing on quality would only slow down the "creative" process.

Did you ever hear: "I love to code", "Writing code is so much fun" ?

Software is not made by grownups. And for the most part the development is not managed by grownups. The problem is that so many can get away with childish behaviour.

A lot of views here are based around a capitalistic rational. Though true, I think there are many companies out there that value certain types of cultures, and some of those cultures include good quality software design.

But this is certainly not the majority.

Adding to other answers, I have noticed this behavior very common in startup scene, where many of them are not actually building a brand for lifetime, but to quickly add pleaothera of features so that they can be sold at a good price.

Clients don't care about quality, they care about features, so management doesn't care about delivering quality, they care about delivering features, so engineers aren't allocated enough time to care about quality, only features. And then it's still the engineers fault when everything explodes or takes 10x longer than it should to rework or expand a feature later.

Basically it comes down to management that is willing and able to tell a client no, or convince the client to budget to do things right, and not management like my current company, which has in the past threatened to disallow even unit test writing and code review as slowing the process down too much.

"Code quality is time and money you're saving your future self" is an argument that only makes sense to people who write code, apparently, until you actually lose a client to avoidable problems.

Companies do care about code quality, but it's not the same kind of quality. This is the purpose of QA. Every company that has a QA team cares about quality at least enough to hire a full-time person responsible for it.

When developers talk about "quality," they mean tech debt. Addressing tech debt is problematic for businesses because it's something that never ends. You allocate one month for tech debt and the devs will ask for two. Allocate two and they will ask for three. There is no agreed-upon standard at which devs will stop and say, "Now our code is clean."

Add to this the fact that there are many developers who just always seem to have an agenda about the code they're working on. They never work a project except they're dying to add some pattern or change some aspect of the code, even if it's something that they used to favor a year ago.

How do you define software quality? Just off the top of my head, I can think of:

* Defect rate (does it do what it's meant to do?)

* Does it do what the user wants? (not always the same as the above...)

* Is it pleasant and efficient to use (definitely not the same as either of the above).

* Is it developed in a way the management are comfortable with? (which often seems to lean towards sufficiently "under control", replaceable developers).

How do you balance these? The answer will be quite different depending on whether you're landing on Mars or writing a free-to-play game.

If you embrace the idea that software development is a process of figuring out what to do - there is just no place for quality at the start, only for throwaway prototypes. And you have to avoid any rigidity at that stage, as it only slows the development down. Quality should be introduced later, once you know for sure you would need a production quality implementation of something. Maybe check out whatever Fred Brooks wrote about this.

When it comes to controlling costs, reducing quality is one of the few levers we have. When it comes to developing software the trade-off we're making is usually not whether we make low or high-quality software, but whether we make low quality or no software.

Businesses* don't care about quality until it's too late.

They pay lip service to it, sure, but when it comes down to it most don't care enough until it actually starts to affect the bottom line. And longer, more expensive development processes are already affecting the bottom line, so come on, get it out the door!

Plus a lot of engineers see quality considerations as a drag. If they can find a home in a company that doesn't want all this "extra" stuff done then, well, this is what you get.

There are notable counter-examples in companies - Big Blue has a huge focus on quality, and their teams put a lot of effort into it (note I am saying nothing about usability here...) which is possible because a lot of stuff there moves slowly anyway. It's also because IBM are very, very good at measuring their cashflows and costs and have figured out just how much lack of quality can impact their bottom line.

There are also many individual engineers in smaller companies who put quality up front, and try their damnedest to push it through even where the business may not really care.

( * mostly SMEs are terrible for this, IMHO, though one or two large corporates I've worked with haven't been that great either)

If you think about it, software quality is not something that is ever visible or measurable from the outside.

Theoretically, you could write software by just having an incredibly long list of test cases and a random string generator.

The quality of that code would probably be terrible, but it would still work as long as your test cases are restrictive enough.

Quality has an extremely broad definition. Everyone cares about quality, just not perfection. At some point, your defect density is acceptable.

The difference in money, and perhaps more importantly, time, between great software and good-enough software is large enough that most companies will require good-enough.

There are two big trade-offs in time alone: missing the chance to be first to market (mongo vs rethink comes to mind, albeit not quite accurate), and the need to get feedback early and often enough to pivot if the idea isn't quite right.

Then the layers of lava come- not enough time to rewrite everything now that the domain is better understood, the prototype becomes the foundation, and cruft builds up.

Unfortunately most of the business people are in a hurry to release a new feature or version.

There is a misconception that code quality comes in a price of developing time but in my experience I have released much faster the final product when I use unit testing, incremental releases, use code reviews and other techniques that help maintain the code quality high.

By not using these techniques you get faster initial release but a much slower final, bug free, release.

Code Quality (CQ) is an ideal.

Your feeling about the magnitude of the issue (most companies) is wrong. Programmers discuss CQ principles among themselves. However, the discussion becomes more challenging with management.

Management is responsible for accomplishing business objectives. Development and testing timeframes are at odds with business objectives. Adopting CQ delays product. If you're going to delay product, but the product will be beautifully efficient, idiomatic, elegant and possibly a little faster than the first pre-CQ version, you're not going to win an argument in an organizational context where delivery timelines matter.

Time and effort are not a programmer's friend in a task-driven organizational setting. Fortunately, real-time linters tell programmers not only about material errors but present stylistic warnings (such as Python pep8 linters). Further, static analysis tools such as Quantified Code [1] conduct an in-depth analysis of code and suggest stylistic improvements. I suspect that this is an area where machine learning will advance Code Quality further. Maybe, just as there are language servers, there will be code quality servers.

It is worth noting that the QuantifiedCode entity shuttered in the Summer of 2017. It's not clear why the company closed-- did they fail to monetize automated code review? Were they acquired?

In conclusion, the more you can automate code quality-related improvements, the more likely you can promote your Code Quality ideals.

[1] https://github.com/quantifiedcode/quantifiedcode

Because _your_ code is fscked, and _your_ code is fscked, in fact all yours codez are facked!!

:points madly around the room: