Bug free certification coming to a theater near you

2 points by moogoo ↗ HN
While "innovation" seems to be the keyword in software today, code quality is slipping massively due to uninformed processes, and hurried, inexperienced developers.

As an industry we have sworn off expert systems, because we don't believe in experts anymore. We don't believe that there are people who can (as individuals) build large systems which are virtually if not completely bug free.

I am one of those people. Surrounded by folks who are just trying to pay mortgages and write code fast and create a bug count for every method/function they write, its hard to imagine that the next phase in software wont be interviewing people about coding up algorithms that are well known and constant.

The next phase of credibility is going to be writing bug free software. This will scare many of you, because you don't believe you are capable of it. And you probably aren't.

But it's going to happen. Im going to make it happen. So for all you speed coders, brogrammers, and technical entrepreneurs, know that your day is coming.

You will be put out of business because of your lack of code quality regardless of the "value" of your "service".

2 comments

[ 2.5 ms ] story [ 16.6 ms ] thread
You will be put out of business when someone finds a bug, and your credibility balloon bursts.

There can be no "bug free certification", because some bugs are a matter of opinion: instances in which the system behaves exactly according to how the engineers interpreted some requirements, but not how the customer intended the requirement. So, buggy according to the user; not buggy according to the developers.

Many users all over the world use software to whose requirement specification have no access, and so are not even able to judge whether some behavior is or is not a bug, other than obviously broken or nonworking functionality and crashes. They just explore the software to learn what it does, or rely on very scanty user documentation that lacks details. Even if something that used to work in a prior version does not work any more, that is not necessarily a regression: not if it was never specified in any documentation as a feature.

You will also crumble due to the overwhelming expense of proving that whatever you're making is bug-free, and the crippling effects of "cheating" to make it simpler to do.

Failing that, you will crumble due to having to specify every single aspect of your software formally, and publish that to everyone who needs proof that it's bug-free because part of what bug-free means is: "implements every aspect of a detailed, rigorous specification". That specification is a treasure to a competitor who wants to clone your system's features, so you will have to enforce NDA's for anyone viewing this documentation, which requires armies of expensive lawyers.

Another issue: say you develop bug free software for some platform. That is well and good and certainly better than a buggy app, but to have a bug-free system (platform plus YourApp), the third-party platform has to be bug free: bug free kernel, bug free middleware, bug free drivers, bug free chips and circuit boards. Also, don't forget that whatever language you're working in has to have a bug-free compiler and run-time support.