Roy Schestowitz wrote:
> Why we all sell code with bugs
>
> ,----[ Quote ]
> | Every time Microsoft releases a version of Windows, stories are
> | written about how the open bug count is a five-digit number.
> `----
>
> http://technology.guardian.co.uk/weekly/story/0,,1781895,00.html
There are two types of software. There is well architected software and
there is poorly architected software.
Well architected software is created is small modules each with a well
documented interface. The initial cost of developing this software is quite
high, but maintenance is considerably because errors are easily isolated
and fixed. Any change to the interface contract is easily detected in
module test and the creation of new errors is avoided. All external
interface have a single point of access. Where new external interfaces need
to be supported it is only necessary to change the interface module.
The other sort of software starts by programmers throwing something together
and then expanding on it. This sort of software needs to be restructured
after three to four iterations or it becomes unmaintainable. External
interfaces are accessed indiscriminantly from within the application. Any
change in the interface introduces a great cost. This sort of code is
cheaper to begin with but unless it is to be one use throw away code, the
overall cost is orders of magnitude greater than a well structured program.
It appears that the product referred to in the newspaper article belongs to
the second group. That is not to say that software in the first group does
not get delivered with bugs. Unfortunately, the way that the world has
become, there is an economic advantage in delivering code with errors.
Firstly, deadlines and budgets need to be met. If the money runs out and the
testing department believes that the customers will accept the product as
is, it is difficult to get extra funds to fix up the remaining errors.
Repairs that are done after delivery, come out of a different budget. Very
often it is necessary for there to be a few bugs so that the company can
sell maintenance agreements. This pays for the bug fixes and also for
improvements to the product so that more money can be made from sales.
If a company were to produce a perfect product, then they would sell it once
and then go out of business. This is the reason why the core infrastructure
on which all other systems are based should never be produced by a company.
There is no incentive to produce a perfect product as a company. Where as
in the open source movement, there is a great incentive to produce a
perfect product because this is effectively a job application. If the code
written by an open source programmer is perfect (if such a thing exists)
then he can be assured of more work. It is possible for every one to see
the quality, or lack there of, of the product
If the structure on which all other projects is based is stable then it is
possible to produce stable products running on top of them. For economic
reasons, some programs may have some errors, but it is not necessary for
all programs to have errors. If reliable infrastructure is available at a
reasonable cost, then projects where reliability is critical are able to be
produced at a reasonable cost. This will have a flow on effect for society
as a whole.
Ian
|
|
