Software entropy

Software entropy is the idea that software eventually rots as it is changed if sufficient care is not taken to maintain coherence with product design and established design principles. The common usage is only tangentially related to entropy as defined in classical thermodynamics and statistical physics.

Another aspect can be found in what is perceived to be a decay in the quality of otherwise static software that is the result of the inevitable changes to its environment, that often occur as operating systems and other components are upgraded or retired.

History

A work on software engineering by Ivar Jacobson et al, in 1992[1] describes software entropy as follows:

The second law of thermodynamics, in principle, states that a closed system's disorder cannot be reduced, it can only remain unchanged or increase. A measure of this disorder is entropy. This law also seems plausible for software systems; as a system is modified, its disorder, or entropy, tends to increase. This is known as software entropy.
Within software development, there are similar theories; see Lehman (1985),[2] who suggested a number of laws, of which two were, basically, as follows:
  1. A computer program that is used will be modified
  2. When a program is modified, its complexity will increase, provided that one does not actively work against this.

In 1999, Andrew Hunt and David Thomas use fixing broken windows as a metaphor for avoiding software entropy in software development.[3]

Relation to information theory

Software source code is information

The purpose of writing software is to encode domain and design knowledge, in source form(s) that can be translated to executable destination format(s). As such, to the extent that the source is a coherent, noise free encoding of the relevant knowledge sets, its entropy may be considered to be low. After initial development and acceptance, the code enters the maintenance phase of the software lifecycle, where it may be allowed to accumulate defects (noise), represented by divergence from those knowledge sets (domain and software design principles), and thereby increase the entropy of the software.

Relation to complexity

While there are known correlations (see software complexity), there is no direct relationship between software complexity and software entropy. Any two pieces of software, with equivalent complexity levels, can exist at different levels of entropy or rot. Even a very simple program, can suffer high levels of entropy as it passes through the hands of multiple developers.

Avoidance

The process of code refactoring can result in stepwise reductions in software entropy.

See also

References
  1. Jacobson, Ivar; Christerson, Magnus; Jonsson, Patrik; Övergaard, Gunnar (1992), Object-Oriented Software Engineering: A Use Case Driven Approach, ACM Press. Addison–Wesley, pp. 69–70, ISBN 0-201-54435-0
  2. Lehman, M. M.; Belady, L.A. (1985), Program evolution: processes of software change, Academic Press, ISBN 9780124424401
  3. Hunt, Andrew; Thomas, David (1999), The Pragmatic Programmer, Addison Wesley, ISBN 0-201-61622-X – Item 4 (of 22 tips) is Don't Live with Broken Windows.
  4. Wojnowicz, Michael; Chisholm, Glenn; Wolff, Matt; Zhao, Xuan (2016). "Wavelet decomposition of software entropy reveals symptoms of malicious code". Journal of Innovation in Digital Ecosystems. 3 (2): 130–140. doi:10.1016/j.jides.2016.10.009.


This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.