There are dictionary definitions of the term sludge, but the introduction on its Wikipedia page is particularly (even entertainingly) descriptive. It is a great place to begin.
Sludge (possibly from Middle English slutch ‘mud, mire’, or some dialect related to slush) is a semi-solid slurry that can be produced from a range of industrial processes, from water treatment, wastewater treatment or on-site sanitation systems. It can be produced as a settled suspension obtained from conventional drinking water treatment, as sewage sludge from wastewater treatment processes or as fecal sludge from pit latrines and septic tanks. The term is also sometimes used as a generic term for solids separated from suspension in a liquid; this soupy material usually contains significant quantities of interstitial water (between the solid particles). Sludge can consist of a variety of particles, such as animal manure.
Wikipedia page on Sludge, retrieved September 19, 2026.
The description is a lot about the substance’s consistency and how it comes about, but as you are reading it, you are perhaps also forming an opinion about its smell and maybe, what it is like.
In their excellent book Nudge: Improving Decisions about Health, Wealth, and Happiness the authors Richard H. Thaler and Cass R. Sunstein also discuss the book’s namesake’s dark cousin (or evil twin): Sludge.
We use the term to mean this: any aspect of choice architecture consisting of friction that makes it harder for people to obtain an outcome that will make them better off (by their own lights).
Nudge, The Final Edition, by Richard H. Thaler and Cass R. Sunstein, page 153.
In that sense, sludge comes in degrees, i.e. some such choice architectures make it easier than others to navigate them to a successful end. Of course, the presence of sludge can have many causes. Sometimes the providers of the choices intentionally make it difficult (for a variety of reasons), other times the sludge accreted over time without that intent.
Sludge is costly for those, who have to deal with it. Consider the time people collectively spend on complicated tax forms every year, or the money lost on subscriptions, for which it was easy to start but very difficult to cancel.
Conceptually, this travels very well. Let’s take a look at software engineering, specifically the maintaining and evolving of software over time.
There are numerous reasons, why it can become more difficult to update a software project, as it grows and changes over time. At the outset its requirements were likely poorly understood. Over its lifetime, it will have to contend with ever new or changing requirements and environmental factors. There is a version of the code base that would be ideal to accommodate what is needed – and then there is the one actually in place.
Ward Cunningham introduced the concept of debt in software engineering in an experience report at OOPSLA ’92. It has received much attention since.
In software-intensive systems, technical debt consists of design or implementation constructs that are expedient in the short term but that set up a technical context that can make future change more costly or impossible. Technical debt is a contingent liability whose impact is limited to internal system qualities – primarily, but not only, maintainability and evolvability.
Managing Technical Debt, page 5, by Philippe Kruchten, Robert Nord and Ipek Ozkaya.
As a metaphor technical debt has become well established in the literature as well as in practice. Many aspects of debt (such as principal, interest, payoff, et cetera) transfer well in that context to the domain of software engineering. The terminology is useful in providing common language for facilitating communication between technical and non-technical stakeholders.
Experienced practitioners will at times speak of code smells, when referring to specific areas that do not seem right, spots that could use tidying or refactoring or otherwise probably should change.
Similarly, analogies using language from mechanical systems also make sense. Developers may speak of the friction they encounter, as they explore the work required to make a change to a code base.
Existing architecture, design and code artifacts – and especially the actual source code base and data that are in place – present a type of choice architecture for the people tasked with maintaining and evolving the system.
Some choices are easier to make than others. The very layout of a module or the precedent of specific variable naming may serve as effective nudging to suggest to developers how an area of the code is to be understood and updated.
Conversely, a code base may be not just difficult to understand; even pursuing the presumably right choice for a change might turn into a messy ordeal. It may then be full of viscous, resistant sludge – and the developers probably feel that, whenever they try to wade into it.
Sludge, especially in large amounts, can be demoralizing. When people would rather give up or knowingly select a worse choice, they may contribute to making the situation worse for themselves or their colleagues in the future.
The people who are building the code base act as choice architects, sludge and all.
When we speak of technical debt, we frame the problem in economic terms. There is a cost to be accounted for, in time and particularly in money.
When we frame it as sludge, we think of choices presented and what it is like to navigate them.