One (is) more than four
Osman /The adage “less is more” is an oft-repeated motto found in numerous personnel training manuals. It’s a concept so frequently discussed that my eyes practically bleed when I encounter it in yet another TED Talk. The meaning behind these words seems to have been diluted over time.
Let’s re-examine what “meaning” could look like from a fresh perspective. Consider the numbers one and four – four chosen deliberately because it isn’t excessively large like one thousand, nor is it as insubstantial as two.
Now, think about “one” being more than “four” – not in the sense that 1 > 4 mathematically, but that there exists a “one” that transcends the sum of “four.” This isn’t about size, but significance. To illustrate, imagine this visually:
Picture four buckets on right, with balls raining down from the sky. The buckets are fitted with small holders, yet they fail to catch every ball. Why do they miss? Projecting the buckets’ coverage over a given area, we notice that scattering them creates numerous gaps – grey areas where balls can slip through uncaught.
Conversely, a single, yet more efficient, solution can cover a broader range without leaving these grey spaces. This means-catching more balls and crucially, preventing any from falling outside the targeted area.
A police officer was in hot pursuit of a thief. The thief, seeking refuge, dashed into a mosque. When the police finally caught up to him, the thief claimed he had been in the middle of prayer. The officers, skeptical, decided to test his story and asked, “How many movements are in the morning prayer?” After a moment’s thought, the thief blurted out, “40!” His lie was immediately obvious. Later, the thief ran into a friend who had heard about the chase. Curious, the friend asked what had happened. The thief recounted the story, ending with the tricky question the police had asked. The friend replied with concern, “I hope you said 2.” The thief, with a wry smile, said, “They didn’t even believe me when I said 40! They would never accept 2.”
Offering users a plethora of choices breeds confusion. Addressing a problem by multiplying the available options is akin to fueling a fire. If a user cannot find an appropriate solution among five options, increasing the count often just compounds the perplexity. When it comes to software development, having too many possible statuses for a task or an overabundance of types only serves to muddle the process and baffle those involved. This principle applies broadly: less complexity in processes, fewer tools. Piling on more processes does not expedite operations, and having more tools at one’s disposal does not a skilled developer make.
Bombarding users with options doesn’t clarify matters; it necessitates explanations, additional documentation, extra processes, and a steeper learning curve. Our objective should be to reduce the surface area—or the attack area, to use a security term—by eliminating these grey zones. We need to diminish friction between components by reducing the number of parts.
With this in mind, a holistic approach typically prevails; the whole is indeed greater than the sum of its parts.