Investigating Higher Quality Software
blrice.net
Investigating Higher Quality Software
1–10 of 16 posts
Re: Investigating Higher Quality Software
#2Well, it seems like a relatively surprise-free article...
Write explicit code, write tests, have QA staff and procedures, build what the stakeholders what.
I guess the biggest problem with software quality is not that we don't know how to do it, but that it's expensive.
Re: Investigating Higher Quality Software
#3Deploying 100% bug-free code is the Holy Grail of software development.
Is this really true? Judging by their decisions, most people's Holy Grail is more like something reasonably good and shipped on time. 100% bug-free code is already possible, but few are willing to pay for it.
Re: Investigating Higher Quality Software
#4Well, it seems like a relatively surprise-free article... Write explicit code, write tests, have QA staff and procedures, build what the stakeholders what. I guess the biggest problem with software quality is not that we don't know how to do it, but that it's expensive.
Poor software quality is also expensive. I would like to see a study about the balance points and how to achieve them.
Re: Investigating Higher Quality Software
#5Deploying 100% bug-free code is the Holy Grail of software development. Is this really true? Judging by their decisions, most people's Holy Grail is more like something reasonably good and shipped on time. 100% bug-free code is already possible, but few are willing to pay for it.
Absolutely.
University ideals, versus the real world.
Re: Investigating Higher Quality Software
#6Well, it seems like a relatively surprise-free article... Write explicit code, write tests, have QA staff and procedures, build what the stakeholders what. I guess the biggest problem with software quality is not that we don't know how to do it, but that it's expensive.
Poor software quality is also expensive. I would like to see a study about the balance points and how to achieve them.
Not always.
Re: Investigating Higher Quality Software
#7Deploying 100% bug-free code is the Holy Grail of software development. Is this really true? Judging by their decisions, most people's Holy Grail is more like something reasonably good and shipped on time. 100% bug-free code is already possible, but few are willing to pay for it.
Is anyone willing to pay for it? Is there any non-trivial code that's been deployed that has been bug free?
I mean, supposedly NASA paid $1,000 per line of code and still got 0.11 defects per 1,000 lines. By that metric, windows would cost $40 billion to develop, but it would still have 4,400 defects in it.
Re: Investigating Higher Quality Software
#8The non-negotiable part is that there should be tests, regardless of when they were written. Those tests will be the record of truth for future development. They are proof that the proper specification was implemented, regardless of methodology.
I really disagree with this. Asides from the fact that tests can't prove the absence of bugs, it's very easy to write a test suite that avoids the unhandled edge-cases; most people do without thinking about it. Your test suite is the tool you have created to search for bugs and should be written in that adversarial mindset rather than as a certification that you actually did your job.
Re: Investigating Higher Quality Software
#9Deploying 100% bug-free code is the Holy Grail of software development. Is this really true? Judging by their decisions, most people's Holy Grail is more like something reasonably good and shipped on time. 100% bug-free code is already possible, but few are willing to pay for it.
Is anyone willing to pay for it? Is there any non-trivial code that's been deployed that has been bug free? I mean, supposedly NASA paid $1,000 per line of code and still got 0.11 defects per 1,000 lines. By that metric, windows would cost $40 billion to develop, but it would still have 4,400 defects in it.
compcert, sel4, etc.
Re: Investigating Higher Quality Software
#10The non-negotiable part is that there should be tests, regardless of when they were written. Those tests will be the record of truth for future development. They are proof that the proper specification was implemented, regardless of methodology. I really disagree with this. Asides from the fact that tests can't prove the absence of bugs, it's very easy to write a test suite that avoids the unhandled edge-cases; most…
Formal verification can prove the absence of bugs.