Hacker News Reader

Comment by slily | Hacker News Reader

I was actually thought how to build quality software (which is not limited to "having no bugs") in college, but I do not have the time or resources to apply this knowledge consistently in a corporate setting because of the pressure to deliver.

View on HN

Because frankly, too much quality is not necessary, in many many cases. To know when you should or should not emphasize quality over quantity and speed, to meet a certain financial objective, is actually harder than writing quality software in the first place, I think.

I agree in principle, but in my experience quality is not nearly prioritized highly enough. There is not enough understanding of quality attributes beyond the most visible ones like compute performance and stability (i.e. lack of bugs). And even for those I work on projects where people complain about lack of proper test coverage constantly, but it is impossible to dedicate time to improve that.

> in my experience quality is not nearly prioritized highly enough

I agree with you on that one. IMHO it's because of that difficulty to know when to optimize for quality, but also because of sheer incompetence.

I'm pretty sure even those basic two, of performance and stability are extreemely undervalued, when you objectively look at how fast modern hardware is and yet how easy it is to find slowness simply in using devices in a day to day environments

This is false. Its just that the costs of low quality code are much less obvious and harder to measure then the dev time. But the ammount of bad code just piles on itself over and over and over and we end up in a world where hardwares becomes incrementally faster while software becomes slower and slower, and more bugier. I mean, in the strict sense of the world an individual company will not pay those costs, but on a societal scale, how much time (and thus money) is wasted daily by all the people who are waiting 30secconds for windows explorer to load? If your app have millions of users, literally every additional second your app wastes multiplies to tangential numbers.

It's akin to pollution, really: Individual company making 'dirty' things won't see the consequences. But scale this mindset out and suddenly we wake up in a world when trillions of dollars are spend to counteract those effects.

> This is false.

I wonder where you get the confidence to make such a strong statement, which is clearly not warranted. I want to challenge you to broaden your view a bit: Not a lot of software is like Windows explorer. Not a lot of software is performance critical. A lot of software can do with bugs, with many many bugs, to be honest. A lot of code is run fewer than 100 times, before it's retired. Also, not a lot of software written has many users. Or enough users to support maintaining it. "Pollution" often affects just the author of the software themself. Software is just a means to an end, and the end decides, how much effort was warranted in the first place.

>Not a lot of software is performance critical.

Not being performance critical doesn't mean it is justified to diss-respect users by wasting their time.

>A lot of code is run fewer than 100 times, before it's retired. Also, not a lot of software written has many users.

Obviously we aren't talking about some simple automation scripts here.

>"Pollution" often affects just the author of the software themself.

You are misunderstanding the pollution analogy. I'm not talking about polluting the codebase with code smell.

I am talking about costs of low quality being non obvious and only revealing themselves at global scale

> Obviously we aren't taking about some simple automation scripts here.

This is moving the goalpost, and also ignores the fact that software exists on a spectrum from "simple automation script" to "messaging app used by millions". It seems you have a very narrow view of what software is, or what it is used for, and the constrains that apply when building it.

This is not moving a goalpost. Running a program less then 100 times total, across all its user, is just very little for anything that could be considered commercial. That really isn't a controversial statement. So I am simply excluding this category as an extremum.

> Running a program less then 100 times total, across all its user, is just very little for anything that could be considered commercial

Running that kind of software for the central bank here. So kind of disputing your statement.

> So I am simply excluding this category as an extremum.

Which ignores the long tail. Great approach.

What software are you running that gets less then 100 usages before it gets retired?

>Great aproach

Unironically better, then trying to make prescriptions as broad and general as possible, because those usually are too generic to carry any actual value

Yearly reports. They can be buggy, can be off by millions, due to rounding errors. They can crash. They can run for days. Nobody cares enough to rewrite them, because regulation will change before that effort amortizes.

Also note that I wrote "code" originally, because there can be programs which are run very often, but certain code paths are not, so my statement applies even for some parts of popular software.

The image I think would be valuable for you to consider is a curve, where 20% of code has 80% of all executions, and 80% of code get's the rest. It makes sense to put in a lot of effort into writing the top 20%, but on any given day it is very likely you'll be working on the lower 80%.

Me too, Manchester uni was good.

I have written non-trivial systems deployed in 20 different sites that have never had a bug ever.

My best are usually second systems, focus on simplicity, standardisation and resist scope creep.

100% coverage with unit tests. 100% coverage with integration tests.

I've written a many things with zero bugs after delivery.

(and other that were never ending quality nightmares)

If I am under pressure to deliver I get strict with TDD, since no time for bug fixing.

Reply on news.ycombinator.com