There are developers who argue against modifying code, some managers fail to see the benefit. Why should one spend time modifying working code? In this excerpt, from my report “Developing Robust Software”, I point out some of the dangers faced by those who adhere to such stance.

Good enough software

Consider a factory which produces LEDs. A defect rate for a production line in such a factory could be the ratio of LEDs which do not perform in accordance to some specification. The expected defect rate could be established to indicate the number of LEDs, within a production batch, which are expected not to emit light.

The production of software differs from traditional factory production. Once software has been compiled, an exact replica is shipped to each customer. Defects stem from the source code (and in rare cases from the compilation process or the media used to carry the product). As such, if a defect is present in the source, it will be present in every customer’s copy. A defect detected by a customer, will likely be rediscovered by a different customer.

Bugs

In software engineering, defects can be managed in order to drive down the defect rate. Bugs per line of code is a common metric of defects. The number of bugs per line of code is established over time as bugs are identified.

Finding and reporting bugs should be a crucial part in the development process of robust systems. The resources used to identify and to fix bugs must be balanced against the production budget if the project is not to fail. As such, the amount of resources dedicated to finding and fixing bugs must correlate with their risk exposure. The risk exposure is computed based on the expected defect rate.

Bugs, if not spotted by developers, are often reported by end users. Depending on the environment in which the software is to operate, the software’s requirements, the amount of resources spent on finding and preventing bugs, as well as mitigating the risk of damage caused by unidentified bugs, must be controlled. The expected cost of mitigation, in terms of nominal effort, can be estimated using software cost estimation models.

One such model is the Constructive Cost Model (COCOMO) [1], in which the value of cost drivers (such as correctness & quality analysis) can be set based on each project’s requirements. After the value of each cost driver has been established, COCOMO shows an estimation of their collective influence on the nominal effort required to develop the software.

Preventing and identifying bugs during the development process increases the nominal effort, and thus the cost [4]. This cost is reflected as an increase in the time to market as well as in the price the end users must pay for the product [8]. Together, if left unbalanced, these can contribute to a project’s fall. On the other hand, releasing potentially buggy software does not necessarily drive towards failure as some users are on the market for good enough software — software which is currently available at an attractive price and does not notably decrease the end-user’s productivity despite occasional hiccups. Ideally, all bugs would be phased out as software updates are made available in reaction to bugs reported by end-users. This seems not to be the case as updates often contain new features and new bugs.

Software entropy

Entropy is a measure of distortion within an isolated thermodynamic system. By the second law of thermodynamics we have that the entropy of any isolated system will never decrease, but always seek to move towards its maximum over time. Software systems, although not as tangible as physical systems, appear to be affected by a similar law.

Software entropy is a term used to indicate that the complexity of software systems seeks to increase as the system changes [5]. The first law of software evolution states:

an E-type system must continually by adapted, or it becomes progressively less satisfactory [6].

By this law, we have that software systems must change if they are to be of use within their operational environment. Most software systems are not self adaptive which suggest that their evolution is driven by programmers [8]. There is a causal relationship between programmers and software entropy, which can in part be attributed to a poor maintenance process [2]. The second law of software evolution states:

as an E-type software system evolves, its complexity increases, unless work is done to maintain or reduce it [6].

This law suggests that programmers can manage the causal effect of their changes. One way in which this can be done is to introduce refactoring to the maintenance process. Such an introduction can significantly lower the average (future) change entropy [2, 3].

By lowering change entropy, the probability of shipping unidentified bugs can be lowered through utilization of quality assurance techniques such as code reviewing. A programmer’s comprehension of the software, does not degrade due to an increase in complexity as long as software entropy is managed.

Software complexity, a cost driver in the COCOMO, can be managed (and ideally lowered) through refactoring. The decrease in nominal effort, introduced by managing the software entropy, can wage up against the increased nominal effort brought about by adding quality assurance techniques into the maintenance process.

Bibliography

[1] B W Boehm. Software Engineering Economics. Software Engineering, IEEE Trans- actions on, SE-10(1):4–21, 1984.

[2] Gerardo Canfora, Luigi Cerulo, Marta Cimitile, and Massimiliano Di Penta. How changes affect software entropy: An empirical study, volume 19. 2014.

[3] Martin Fowler, Kent Beck, John Brant, William Opdyke, and Don Roberts. Refac- toring: Improving the Design of Existing Code. Xtemp01, pages 1–337, 1999.

[4] F.J. Heemstra. Software cost estimation. Information and Software Technology, 34(10):627–639, October 1992.

[5] I. Jacobson, M. Christerson, P. Jonsson, and G. Övergaard. Object-oriented software engineering. A use case driven approach. Addison-Wesley Publ, 1992.

[6] M.M. Lehman. On understanding laws, evolution, and conservation in the large- program life cycle. Journal of Systems and Software, 1:213–221, 1979.

[7] M.M. Lehman. Program evolution. Information Processing & Management, 20:19– 36, 1984.

[8] E. Yourdon. When good enough software is best. IEEE Software, 12:79–81, 1995.