Live data from Hacker News

You are never taught how to build quality software

florianbellmann.com

31–40 of 500 posts

Re: You are never taught how to build quality software

#31

Author needs to change shop Where I work is 50% qa effort at least, 50% by budgets, and devs do much >50% automated testing as part of what we call development. Anything less and projects take longer, because bugs found later cost so much more to fix.

When I first started in the 1990s I was told testing was 60% of the product budget and traditional writing code 20%. The remaining 20% was architecture and other design work. We didn't have unit test frameworks, but we did spend a lot of time writing throw away test fixtures (which was already generalizing into test frameworks by great developers and kicking off the unit test revolution)

Re: You are never taught how to build quality software

#33

> It will be necessary to deliver software without bugs in time. Seems like a pretty bad premise to start an article on quality software. If you believe you can ship bug free code, it's time to switch careers.

> If you believe you can ship bug free code, it's time to switch careers. Unfortunately, you are correct. Shipping in time and bug free are inversely proportional, and in a world were usually it's hard to argue with PMs for more time to have better testing, or paying tech debt... it's just a reality

An infinite amount of time would not necessarily yield zero bugs.

But more importantly, once you've fixed the "show-stopping bugs," putting the software in front of customers is probably the best next step, as even if it's bug-free, that doesn't mean it solves the problem well.

Re: You are never taught how to build quality software

#34
post #8
post #4

Earlier quoted context omitted.

This is what I came here for. There's an obvious comprehensibility complexity to code to anyone who has spent almost any time what so ever trying to make something happen in software. However, we've got zero academics or theory around it. Just 'best practices' (ie a thing other people are known to do so if things go wrong we can deflect blame). And code smells (ie the code makes your tummy feel bad. yay objective mea…

There is plenty of academics on it, as real engineers, those that studied Software Engineering or Informatics Engineering, instead of fake engineering titles from bootcamps, should be aware. Usually available as optional lectures during the degree, or later as Msc and PhD subjects.

I'm all ears.

Although, so far I've only bumped into cyclomatic complexity (with some studies showing that it has worse predicting power than lines of code) and lines of code.

Re: You are never taught how to build quality software

#35
post #30
post #7

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.

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.

Re: You are never taught how to build quality software

#36

> It will be necessary to deliver software without bugs in time. Seems like a pretty bad premise to start an article on quality software. If you believe you can ship bug free code, it's time to switch careers.

This kind of wisdom only comes from experience I think. Either that or higher order think. Like the article says, most of the time testing/tdd/qa is bolt on after-the-fact. Or a big push at the end with "QA Sprints" (are you sprinting or are you examining? what exactly is a QA sprint? I know what it is).

Once you get beyond "I wrote a function" and "I tested a function" and even still "I tested a function that was called by a function over the wire", you will come to a realization that no matter how edgy your edge cases, no matter how thorough your QA, there will always - ALWAYS be 0-day "undefined behavior" in certain configurations. On certain hardware. On certain kernels. It's an assurance that I guarantee that I'm almost positive it's bug free, since it passed tests, it passed human eyes, and it passed review - fingers crossed.

Re: You are never taught how to build quality software

#37
post #7

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.

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.

Re: You are never taught how to build quality software

#38

> It will be necessary to deliver software without bugs in time. Seems like a pretty bad premise to start an article on quality software. If you believe you can ship bug free code, it's time to switch careers.

You might be correct today but that’s a pretty sad state of affairs, don’t you think we can do better? Most other engineering domains can deliver projects without bugs, with various definitions of “bug” of course

Re: You are never taught how to build quality software

#40

Earlier quoted context omitted.

> If you believe you can ship bug free code, it's time to switch careers. Unfortunately, you are correct. Shipping in time and bug free are inversely proportional, and in a world were usually it's hard to argue with PMs for more time to have better testing, or paying tech debt... it's just a reality

An infinite amount of time would not necessarily yield zero bugs. But more importantly, once you've fixed the "show-stopping bugs," putting the software in front of customers is probably the best next step, as even if it's bug-free, that doesn't mean it solves the problem well.

there is no such thing as zero bugs. There is only a marker in time for a suite of tests that show no bugs. Doesn't mean larva aren't living under the wood. You can't control all the bits (unless you built your own hardware/software stack).
Post reply on HN