Software entropy

Last updated

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.

Contents

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

Related Research Articles

<span class="mw-page-title-main">Computer program</span> Instructions to be executed by a computer

A computer program is a sequence or set of instructions in a programming language for a computer to execute. It is one component of software, which also includes documentation and other intangible components.

<span class="mw-page-title-main">Entropy</span> Property of a thermodynamic system

Entropy is a scientific concept that is most commonly associated with a state of disorder, randomness, or uncertainty. The term and the concept are used in diverse fields, from classical thermodynamics, where it was first recognized, to the microscopic description of nature in statistical physics, and to the principles of information theory. It has found far-ranging applications in chemistry and physics, in biological systems and their relation to life, in cosmology, economics, sociology, weather science, climate change, and information systems including the transmission of information in telecommunication.

In computer programming and software design, code refactoring is the process of restructuring existing computer code—changing the factoring—without changing its external behavior. Refactoring is intended to improve the design, structure, and/or implementation of the software, while preserving its functionality. Potential advantages of refactoring may include improved code readability and reduced complexity; these can improve the source code's maintainability and create a simpler, cleaner, or more expressive internal architecture or object model to improve extensibility. Another potential goal for refactoring is improved performance; software engineers face an ongoing challenge to write programs that perform faster or use less memory.

<i>The Mythical Man-Month</i> 1975 software engineering book by Fred Brooks

The Mythical Man-Month: Essays on Software Engineering is a book on software engineering and project management by Fred Brooks first published in 1975, with subsequent editions in 1982 and 1995. Its central theme is that adding manpower to a software project that is behind schedule delays it even longer. This idea is known as Brooks's law, and is presented along with the second-system effect and advocacy of prototyping.

In software engineering, a software design pattern is a general, reusable solution to a commonly occurring problem within a given context in software design. It is not a finished design that can be transformed directly into source or machine code. Rather, it is a description or template for how to solve a problem that can be used in many different situations. Design patterns are formalized best practices that the programmer can use to solve common problems when designing an application or system.

The Law of Demeter (LoD) or principle of least knowledge is a design guideline for developing software, particularly object-oriented programs. In its general form, the LoD is a specific case of loose coupling. The guideline was proposed by Ian Holland at Northeastern University towards the end of 1987, and the following three recommendations serve as a succinct summary:

In computer programming, a code smell is any characteristic in the source code of a program that possibly indicates a deeper problem. Determining what is and is not a code smell is subjective, and varies by language, developer, and development methodology.

In software and systems engineering, the phrase use case is a polyseme with two senses:

  1. A usage scenario for a piece of software; often used in the plural to suggest situations where a piece of software may be useful.
  2. A potential scenario in which a system receives an external request and responds to it.

"No Silver Bullet—Essence and Accident in Software Engineering" is a widely discussed paper on software engineering written by Turing Award winner Fred Brooks in 1986. Brooks argues that "there is no single development, in either technology or management technique, which by itself promises even one order of magnitude [tenfold] improvement within a decade in productivity, in reliability, in simplicity." He also states that "we cannot expect ever to see two-fold gains every two years" in software development, as there is in hardware development.

<span class="mw-page-title-main">Grady Booch</span> American software engineer

Grady Booch is an American software engineer, best known for developing the Unified Modeling Language (UML) with Ivar Jacobson and James Rumbaugh. He is recognized internationally for his innovative work in software architecture, software engineering, and collaborative development environments.

In software engineering, creational design patterns are design patterns that deal with object creation mechanisms, trying to create objects in a manner suitable to the situation. The basic form of object creation could result in design problems or in added complexity to the design. Creational design patterns solve this problem by somehow controlling this object creation.

<span class="mw-page-title-main">Ivar Jacobson</span>

Ivar Hjalmar Jacobson is a Swedish computer scientist and software engineer, known as major contributor to UML, Objectory, Rational Unified Process (RUP), aspect-oriented software development and Essence.

Software rot is either a slow deterioration of software quality over time or its diminishing responsiveness that will eventually lead to software becoming faulty, unusable, or in need of upgrade. This is not a physical phenomenon; the software does not actually decay, but rather suffers from a lack of being responsive and updated with respect to the changing environment in which it resides.

Object-oriented analysis and design (OOAD) is a technical approach for analyzing and designing an application, system, or business by applying object-oriented programming, as well as using visual modeling throughout the software development process to guide stakeholder communication and product quality.

Research concerning the relationship between the thermodynamic quantity entropy and both the origin and evolution of life began around the turn of the 20th century. In 1910, American historian Henry Adams printed and distributed to university libraries and history professors the small volume A Letter to American Teachers of History proposing a theory of history based on the second law of thermodynamics and on the principle of entropy.

Software evolution is the continual development of a piece of software after its initial release to address changing stakeholder and/or market requirements. Software evolution is important because organizations invest large amounts of money in their software and are completely dependent on this software. Software evolution helps software adapt to changing businesses requirements, fix defects, and integrate with other changing systems in a software system environment.

In software development, or any other IT field technical debt is the implied cost of future reworking required when choosing an easy but limited solution instead of a better approach that could take more time.

<span class="mw-page-title-main">Extreme programming</span> Software development methodology

Extreme programming (XP) is a software development methodology intended to improve software quality and responsiveness to changing customer requirements. As a type of agile software development, it advocates frequent releases in short development cycles, intended to improve productivity and introduce checkpoints at which new customer requirements can be adopted.

In computer programming, a design smell is a structure in a design that indicates a violation of fundamental design principles, and which can negatively impact the project's quality. The origin of the term can be traced to the term "code smell" which was featured in the book Refactoring: Improving the Design of Existing Code by Martin Fowler.

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 page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.