Information Technology Reference
In-Depth Information
The primary issue comes from an argument to parsimony. The coder who can create
a small, fast and effective code sample in 200 lines where another programmer would
require 2,000 may have created a more productive function. The smaller number of
lines requires less upkeep and can be verified far easier than the larger counterpart.
Software maintenance introduces more bugs. Through an analysis of the debugging
progresses and the program fixes, it was clear that systems deteriorate over time.
What we see is that the first iteration of bug fixes leads to a second and subsequent
series of fixes. In each set of fixes, there is a 20-50% (mean of 34%
±
8%
1
) of the fix
creating another round of bugs. This drops on the second round of fixes, but starts to
rise on the 3rd and subsequent rounds. In a smaller set of code, the low overall vol-
ume of bugs limits the number of iterations, but the larger code samples led to up to 6
iterations. This would be expected to be even larger on extremely large programs
(such as an Operating System).
The ratio of software bugs in the patching process was less than that of the initial re-
lease, but over the life of a program that has been maintained for several years, the total
number of bugs introduced through patches can be larger than that of the initial release.
Fig. 1.
Each vulnerability costs more than
the last to mitigate
Fig. 2.
Program size against Coding time
Fig. 3.
Program size against Bugs
Fig. 4.
Box plot of the distribution of
Bugs/TLOC
1
95% Confidence Interval or
.
α =
5%
Search WWH ::
Custom Search