# Software Rot, Entropy and the Broken Window Theory

DevFeed: [Software Rot, Entropy and the Broken Window Theory](<https://devfeed.tech/articles/software-rot-entropy-and-the-broken-window-theory-24939.md>)

Original publisher: [Read original article](<https://codeahoy.com/2016/05/02/software-rot-entropy-and-the-broken-window-theory/>)

Author: umer

Published: 2016-05-02T00:00:00Z

Content type: article

Language: rll

Sources: [Code Ahoy - Articles](<https://devfeed.tech/sources/code-ahoy-articles.md>)

Topics: [Software](<https://devfeed.tech/topics/software.md>), [Code quality](<https://devfeed.tech/topics/code-quality.md>), [Refactoring](<https://devfeed.tech/topics/refactoring.md>)

Tags: [code-quality](<https://devfeed.tech/tags/code-quality.md>), [complexity](<https://devfeed.tech/tags/complexity.md>), [defects](<https://devfeed.tech/tags/defects.md>), [developers](<https://devfeed.tech/tags/developers.md>), [projects](<https://devfeed.tech/tags/projects.md>), [refactoring](<https://devfeed.tech/tags/refactoring.md>), [software](<https://devfeed.tech/tags/software.md>)

## AI overview

The article explains how software projects accumulate complexity and defects when teams take shortcuts, causing software entropy or code rot. It argues that refactoring or rewriting may provide only short-term relief unless teams adopt practices to control future complexity, with psychology and team culture identified as important contributing factors.

## Source excerpt

"Complexity is the business we are in and complexity is what limits us." - Fred Brooks, The Mythical Man-Month Software projects go through many modifications over their lifetime. As they evolve, the code grows in size and complexity creeps in. Software developers spend a large portion of their time maintaining existing software either by adding new functionality or fixing bugs. Often times, they are forced to take shortcuts to meet deadlines. Developers add new functionality in a 'quick and dirty' manner and apply duct-tape to defects. While the organization meets its short-term goal of getting the software out of the door quickly, the code quality suffers and deteriorates. After a while, things start to get really bad. The software becomes so complex and buggy, that it is virtually impossible to maintain. Fixing a bug would introduces more bugs and modifying one part of the software would break several others. Let's look at a related concept called software entropy. Entropy is the amount of disorder in a system. It is a physical phenomenon but Ivar Jacobson et al used it to describe the disorder in a software system: The second law of thermodynamics, in principle, states that a closed system's disorder cannot be reduced, it can only remain unchanged or increased. A measure of this disorder is entropy. This law also seems plausible for software systems; as a system is modified, its disorder, or [software] entropy, always increases. This is called Software Entropy. When the 'disorder' or the software entropy increases, it leads to software or code rot. The system ends up becoming so complex and disorganized that it is too costly or impossible to maintain. People get frustrated and consider major refactoring or, in some cases, rewriting from scratch. These arduous solutions fix the problem in the short-term but the software will rot again if the team doesn't adopt a plan for keeping future complexity under control. While there are many factors that lead to software r