I doubt I'm the only one who spots that "bloat" is highly subjective, thus defining and categorizing bloat depends on who is doing it. As a developer, I freque

I doubt I'm the only one who spots that "bloat" is highly subjective, thus defining and categorizing bloat depends on who is doing it. As a developer, I frequently categorize and define bloat as large amounts of extraneous code from libraries and other tools that are not directly used by any part of a given application, but are nonetheless imported or installed by a project. Here, I typically go pointing the finger at requirements files, sloppy imports, and other dependency-related smells. As a manager, I may define bloat as anything in the above dependency realm when I'm working with developers. Alternatively, anything in the realm of features and functionality that do not have a defensible position as being built for and used by a majority of users is sure to get some dirty and suspicious looks from me as bloat. This is typically triggered when a client or other project stakeholder suggests Feature X be added so Person Y (or Customer Z) doesn't have to use some other Tool B. I push back hard on such suggestions until there's a demonstrative case to be made that this kind of bloat won't become a major liability in the code from a long view, or a stumbling block for the majority of users. As a user, I often define bloat as any number of features I don't personally use and, through various interactions and use-cases, feel get in my way, clutter up my UI, whatever. Everyone involved (except users) is responsible for the bloat in their own domain.