Bob and Alice enter the restaurant and survey the scene. It is not their first time, and yet, they struggle to contain their excitement as their eyes dart across the mountains of food. Alice tests the elastic in her stretch pants and takes a moment to congratulate herself on her clothing choice. The waiter shows them to their table, and they order drinks. The eating games are about to begin.
We are all guilty of having had too many helpings at an all-you-can-eat restaurant. We upsize to the grande latte when the tall would have done, and we rationalize that the jumbo fries are better value. What we less often consider, however, is the impact of this “buffet effect” on the maintainability of software.
A few days after their buffet indulgence, Alice and Bob resume their normal lives as software engineers. Although they have both shed their stretch pants, they return to work with an unchanged psychology. The same subconscious thought processes that led Alice and Bob to overeat make them reluctant to retire old product features.
Microsoft Word, Google Docs, and even our own TinyMCE, all carry the scars of product maturity in the form of super-sized feature sets. Even products that are new and have minimalism as a core value are prone to suffer from the same affliction: Medium delivered a minimalist, paradigm-changing content creation interface. The initial release showed discipline in the feature set but is starting to bloat over time, with the introduction of more layout options and writing features. It appears that our human condition fools us into creating software that is less maintainable over time.
Our inability to let go of things, even things that we no longer need, is a fascinating topic explored by psychologist and behavioral economist Dan Ariely. According to Ariely, the buffet phenomenon occurs due to two patterns of human logic.
First, we fall in love with what we already have. This love manifests in software as a high rate of feature retention. Sadly, inside most software products, there is little correlation between a feature’s utility and its persistence.
Secondly, we focus on what we may lose, rather than what we may gain. When we include a feature in a product, the thought that we might cut it from a future release creates a sense of loss. Removing a capability represents a loss that is seldom weighed against the benefits of a smaller, more maintainable code base.
The trend in content creation is towards clean, well-designed and minimalistic interfaces. Stripping away extraneous features enables authors to focus on the task of content creation, freeing themselves from distraction and overhead. Minimal features and more maintainable code bases are significant benefits, yet, like well-fed humans at an all you can eat buffet, our attachment to features-past leads us to bloat our software in the name of flexibility.
This post was first published on the Ephox.com blog