Oft-misused adjectives: Bloated and Lightweight

Friday, April 18 2014

In software development, we like to re-purpose everyday adjectives. We’ll call a project "unstable", or "mature". Maybe we give a nod where it’s due and say a piece of software is "elegant". For the most part, this works pretty well. However, I’m going to take a moment to rant about two that I see constantly misused:

  • Bloated
  • Lightweight

Every time I see either of these used, I ignore what follows. There are cases where these two adjectives make sense, but I argue that these are few and far between. Some of my hangups may be completely irrational, so take this mostly as a rant, because who doesn’t like a good rant?

Let’s started with "bloated".


The Dictionary.com definition:

bloat·ed [bloh-tid] adjective

  1. swollen; puffed up; overlarge.
  2. excessively vain; conceited.
  3. excessively fat; obese.

Applied in the context of software, this is often used to describe a project that is larger than it needs to be. It is almost always used as a derogatory term, used to describe something overly complex. However, in most cases this term is a too vague and non-specific to be of any use. How "large" should the project be? What defines "large"? If it were stripped down, would it still be useful to the same audience? Is it really a problem that you aren’t using all of the bells and whistles in a module?

When you find yourself considering using "bloated", ask yourself to more specifically define your grievances. If the software/library/module is a sprawling, badly organized mess, you probably want something like "sloppy" or "tangled". If you are having a hard time wrapping your head around the basic usage of said software, maybe you’re looking for "complex" or "ergonomically challenged". These point to more specific issues.

"Bloated" can often appear when a developer is having a hard time understanding a piece of software. Perhaps the real problem is bad documentation, but the dev may instead just call said software "bloated" and move on. I also see it used as justification to re-invent the wheel or justify NIH Syndrome due to a lack of understanding for the original library.

Now that I’ve ranted for a bit, here’s a summary:

  • Find a better way to describe your objection. Be more specific!
  • Understand that a general-purpose library/module/software product has to cover more than just your usage case. If your usage case is specific and narrow, you’re more likely to toss around the "B word".
  • It’s OK if you don’t use all of a software product’s features. Disk space is cheap.
  • If a software product is hard to understand, it may not be "bloated". It may have ergonomic or documentation issues. It could just be messy code. Mention these issues instead of referring to the more vague "bloat".

There are legitimate usage cases for this term, but there is almost always a better, more specific way to describe why you dislike a piece of software.


A library being described as "bloated" is almost always followed up with a recommendation for a more "lightweight" alternative. The Dictionary.com definition:

light·weight [lahyt-weyt] adjective

  1. light in weight.
  2. being lighter in weight, texture, etc., than another item or object of identical use, quality, or function: a lightweight topcoat; a lightweight alloy for ship construction.

This is probably the more obnoxious of the two terms for me. The intent is to describe a module as being smaller and more simple than an alternative. The amusing thing is that the supposed more "lightweight" alternative is of similar size and complexity to the "bloated" bit. "lightweight" is used to paint a module in a positive light, opposite of "bloated"’s negative connotation.

As is the case with "bloated", lightweight is a cop out for justifying why something is better. When you find yourself considering the use of "lightweight":

  • Re-visit and re-define your objection to the first library you were considering. Is it sloppy? Does the documentation suck? Does the API have ergonomic issues? Does it use too much of your system’s resources? If so, pick a more descriptive adjective.
  • Once you have a concise reason for not liking your first candidate library, see if your alternative does things better. If so, specifically mention what it does better. Does it have better documentation? Alternative is "better documented". Is the API easier to use? Alternative is subjectively "easier to use". Is the code better organized and of higher quality? Alternative is "more elegantly designed".

"Lightweight" doesn’t tell us much. Amusingly, it is often used by developers who were looking to re-invent a more "bloated" piece of software by stripping a ton of features out, pooping out some documentation, then calling it a day. Said alternative often lacks the community to see much maintenance, and it often lacks widely used features that its predecessor had.

There are legitimate usage cases for this term, but there is almost always a better, more specific way to describe why an alternative to something is better.


In closing, it’s important to remember that open source software is created and developed by other real humans. They tend to take some amount of pride in their work. It’s OK to criticize software, it often motivates positive change. However, it’s important to be specific and fair with criticism. Don’t cop out when describing what makes you dislike a certain library/module/software product. Get specific, be fair, and maybe everyone will benefit.

When (and when not) to use EC2

Tuesday, December 03 2013

A brief overview on when using EC2 is and isn’t appropriate.

read more

Linode NextGen

Tuesday, April 09 2013

A look into the now complete Linode NextGen and how it changes things.

read more

Amazon Route 53 DNS failover

Tuesday, April 02 2013

A quick review of my experience with Route 53’s DNS failover service.

read more

namecheap.com EssentialSSL and Amazon ELB

Friday, March 29 2013

How to generate the Certificate Chain for namecheap.com EssentialSSL and Amazon ELB.

read more

Ansible first impressions

Friday, February 08 2013

After brief visits with Puppet and Chef for config management, I’ve set my sights on Ansible. It’s late and I’ve been staring at this stuff for way too long today, but here are some early observations:

  • I really like that it is written in Python. Puppet and ...
read more

Amazon Elastic Transcoder Review

Wednesday, January 30 2013

Amazon Elastic Transcoder was released just a few short days ago. Given that we do a lot of encoding at Pathwright, this was of high interest to us. A year or two ago, we wrote media-nommer which is similar to Amazon’s Transcoder, and it has worked well for us ...

read more

python-route53 released!

Wednesday, November 14 2012

After some more time in the cooker, python-route53 1.0 has landed on PyPi. This is a stand-alone Route 53 package, independent from the one in boto. The major hilights are:

  • Python 2.7 and 3.x compatibility.
  • Extremely simple API
  • Powered by requests

Read the documentation, see the source ...

read more

seacucumber 1.5 released

Monday, July 16 2012

seacucumber 1.5 was released, and is a pretty important (albeit minor) update to correct our unicode handling. The minimum boto version was raised to 2.3, so we can make use of the more specific SES exceptions seen in later releases.

Grab it from PyPi or pip/easy_install away.

read more

django-dynamodb-sessions 0.5 released

Tuesday, May 01 2012

I have released django-dynamodb-sessions 0.5 today, addressing an issue with session keys. All users of previous versions are encouraged to upgrade. Thanks goes to Adam Nelson for pointing this out.

read more