Software bloat

Software bloat describes the tendency of software to become unnecessarily large, slow, or complex over time, relative to the value it delivers to users. It manifests as excessive memory and CPU consumption, slow startup and response times, large installation footprints, and user interfaces cluttered with rarely-used features.

The phenomenon is closely associated with scope creep. As software matures and successive teams add features to satisfy an ever-broader set of use cases, the product accumulates weight without a corresponding increase in usefulness for any individual user.

Dependency bloat is a related concern in modern software, where applications transitively pull in far more third-party library code than they actively use.

Niklaus Wirth observed the broader pattern as early as 1995 in what became known as [Wirth’s Law]: that software grows slower faster than hardware grows faster — meaning that gains in hardware performance are routinely absorbed by the increasing demands of new software rather than producing a faster user experience.

Bloat can also originate from legitimate technical constraints: maintaining backwards compatibility, supporting a wide range of platforms and configurations, and preserving deprecated code paths all add bulk without adding visible value.

The historical trajectory of many major software products — word processors, web browsers, operating systems — illustrates how ambitious, well-engineered systems gradually become unwieldy under the accumulating weight of requirements.

Countermeasures include deliberate feature pruning, enforcing architectural modularity so that users can choose to include only the components they need, and establishing clear deprecation policies that allow legacy code to be removed rather than retained indefinitely.

In [agile] development, the practice of maintaining a prioritized and curated backlog — and being willing to say no to new feature requests — is a primary defense against bloat before it takes hold.