Great Developers Never Say “Bloated”
At Sanctuary, we make a point of hiring from various backgrounds — be it design, art fashion or music, people with an inherent sense of style tend to make the best products.
There’s a downside however — we don’t always speak fluent computer science, so often we lack the vocabulary to talk about our craft with precision, and sometimes find ourselves using looser terms to describe a general feeling.
One such term is “Bloated”.
To call something “bloated” is to say a lot and a little at the same time: it’s become an overused platitude that shuts down intelligent, detail oriented conversation.
When someone implies a framework/codebase/system is “bloated”, they probably mean one or more of the following:
1. Poorly Written or Maintained
Code that was written quickly, or designed poorly often bloats in the absence of scalable architecture, and over time features and methods are bolted on wherever they fit. The code is quickly unreadable.
This is probably the most dangerous form of bloat, but doesn’t necessarily mean the code runs slowly or is “broken”. In cases where one can not ever imagine touching the source code, the software can be treated as a “black box” (think of it like your unix kernel).
Avoid at all cost, but should using a legacy codebase be the only (or most impactful) option, there’s a case to be made that it’s potentially acceptable in a black box scenario.
2. Depth of Abstraction & Learning Curve
Magic code. DSLs. Meta Programming. Frameworks. The conversation-stopping “law of leaky abstractions” mean most developers conflate abstraction & bloat.
However! Regardless of our chosen stack, we’re already balancing on a mountain of abstractions that we’ve been working on for 40+ years — and they’ve only gotten better over time. You’re not going to rewrite an ngnix clone to deploy your blog; so avoiding abstraction on the app-code level can seem almost futile.
Abstractions also take some time to learn. Compared to writing a solution from scratch, learning to use a foreign system can feel like a bigger cognitive load. In a collaborative setting however, the payoff is huge: everyone is “speaking the same language” through that shared solution, bringing greater consistency to the codebase (and therefore reducing bloat from point #1).
Plus, if that abstraction has tests written against it, it’s less tests for you to write!
Embrace “the sharp tools of abstraction” guilt free when they are proven by community popularity, long term maintenance (and thus flexibility), robust test coverage and low to no computational cost / performance hit.
3. Size & Surface Area of Bundled Libs
In the world of tiny NPM modules, we’ve become accustomed to assume that a framework or library that has a lot of code, classes and utilities is obviously bloated.
What’s not often praised is the awesome interoperability of a popular large scale ecosystem. In big web frameworks, there is zero time spent bolting essential parts together, and furthermore, zero time spent upgrading each manually, and untangling the dependency hell that comes along with those upgrades.
If it’s likely you’ll use a majority percentage of the code paths in a “majestic monolith”, and the ones you don’t use come at low to no performance cost (through tree shaking or optimized eager loading) you’ll likely save time both now and in the future with no discernible downside.
Bloat is Bad, but so is saying “Bloated”
The point of this article is not about embracing bloated systems, but instead dissecting approaches that are usually grouped under that umbrella, and asking better questions like:
- Is this “perceived” bloat acceptable and even beneficial for our use case?
- Does it bring major wins to the project timeline?
- Is the client able to easily recruit an inhouse team?
- Does it make maintenance trivial?
- Does it fatally inhibit scaling?
Don’t shut down conversations with “Bloated”. Embrace the details.
Sanctuary Computer builds compelling User Interfaces in NYC for large companies like General Electric, restaurant groups like Dig Inn, hardware companies like The Light Phone, and startups like Dame Products. Reach out at hello@sanctuary.computer !
