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.
You are never taught how to build quality software
31–40 of 500 posts
Re: You are never taught how to build quality software
#32What you read on the internet is mostly ... bullshits.
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
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
#34Earlier 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.
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
#35I 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.
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.
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
#37I 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.
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.
Re: You are never taught how to build quality software
#39Re: You are never taught how to build quality software
#40Earlier 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.