2 added 33 characters in body
source | link

In a sense, your boss is right. It is possible to write software that approaches zero bugs. But

But the problem is that the cost of doing thiswriting (almost) zero-bug programs is prohibitively high. You need to do things like:

  • Use formal specifications of your requirements. Formal, as in use of Z or VDM or some other mathematically sound notation.

  • Use theorem proving techniques to formally prove that your program implements the specification.

  • Create extensive unit, regression and system test suites and harnesses to test every which way for bugs. (And this is not sufficient in itself.)

  • Have many people review the requirements (formal and informal), software (and proofs). tests, and deployments.

It is extremely unlikely that your boss is prepared to pay for all of this ... or put up with the time it takes to do it all.

In a sense, your boss is right. It is possible to write software that approaches zero bugs. But the problem is that the cost of doing this is prohibitively high. You need to do things like:

  • Use formal specifications of your requirements. Formal, as in use of Z or VDM or some other mathematically sound notation.

  • Use theorem proving techniques to formally prove that your program implements the specification.

  • Create extensive unit, regression and system test suites and harnesses to test every which way for bugs. (And this is not sufficient in itself.)

  • Have many people review the requirements (formal and informal), software (and proofs). tests, and deployments.

It is extremely unlikely that your boss is prepared to pay for all of this ... or put up with the time it takes to do it all.

In a sense, your boss is right. It is possible to write software that approaches zero bugs.

But the problem is that the cost of doing writing (almost) zero-bug programs is prohibitively high. You need to do things like:

  • Use formal specifications of your requirements. Formal, as in use of Z or VDM or some other mathematically sound notation.

  • Use theorem proving techniques to formally prove that your program implements the specification.

  • Create extensive unit, regression and system test suites and harnesses to test every which way for bugs. (And this is not sufficient in itself.)

  • Have many people review the requirements (formal and informal), software (and proofs). tests, and deployments.

It is extremely unlikely that your boss is prepared to pay for all of this ... or put up with the time it takes to do it all.

1
source | link

In a sense, your boss is right. It is possible to write software that approaches zero bugs. But the problem is that the cost of doing this is prohibitively high. You need to do things like:

  • Use formal specifications of your requirements. Formal, as in use of Z or VDM or some other mathematically sound notation.

  • Use theorem proving techniques to formally prove that your program implements the specification.

  • Create extensive unit, regression and system test suites and harnesses to test every which way for bugs. (And this is not sufficient in itself.)

  • Have many people review the requirements (formal and informal), software (and proofs). tests, and deployments.

It is extremely unlikely that your boss is prepared to pay for all of this ... or put up with the time it takes to do it all.