The least you can do
When on the hook to solve a new problem, I always try to answer the following question: “What is the least amount of output required to achieve the desired goal?”
There is a stigma in our world that the least is bad. It’s lazy. It’s not enough. To me, this is mainly due to a gross misinterpretation of what the least is. When answering this question truthfully, finding the least is a habit of the diligent, not the lazy. And, it quite often takes a whole lot of effort.
Answering both sides of the question
So, what is the least amount of output needed to achieve the desired goal? This question actually manifests as two parts.
First, how will we know we’ve achieved the goal? For a support team, it may mean providing fantastic customer service. But, how do we know we’ve done it? Is a 15-minute average support response time better than a 30-minute one? What if faster response times cause the quality of our support to go down? Where is the pivot point that gives us the optimal response time and quality?
For developers, it may mean making a software workflow as user friendly as possible. But, does that mean reducing the number of clicks to as close to zero as possible? Or, could it be that an extra click (or two) helps the user understand how the system is organized, and prevents them from getting lost?
Down in the details, figuring out what constitutes achieving the goal is hard, hard work. Often times, the metrics aren’t easily extractable yet to know for sure. So, we may have to guess at first, and plan out a system to monitor whether we’re achieving the goal once we’ve deployed the solution.
In software, we don’t ask ourselves this question frequently enough. Programmers, and even technical architects, often focus too narrowly on the technical details (for good reason) to clearly see whether the details and the goal actually match up. Business strategists and high-level thinkers might stop at “we need better customer service” rather than formulate how broad-stroke visions actually manifest into tangible tasks. The tedious work of bridging the idea-to-implementation divide is then left unattended. As Derek Sivers points out, ideas are just a multiplier of execution. But figuring out the correct execution? That’s difficult work. In the end, it requires everyone’s input to bridge that gap.
Then, there’s the second question. How do you achieve the goal with the least amount of implementation?
As a writer, I’m always thinking about what words I can remove. What’s not adding to, or even muddling, the point I’m trying to make? One of my favorite fables about removing words is the story that Benjamin Franklin recalled to Thomas Jefferson while editing the original draft of the Declaration of Independence.
Jefferson was very proud of his initial draft, and became very upset when the other members of the committee began to hack away at it with various revisions and amendments. So in attempt to make him feel better, Benjamin Franklin told him a story about a friend of his, a hatter, who planned to adorn his new hat shop with a sign bearing the words “John Thompson, hatter, makes and sells hats for ready money” above a picture of a hat.
Thompson showed the sign to a group of friends and asked them what they thought. The first remarked that the words “makes and sells hats” made the word “hatter” redundant. The second pointed out that “makes” could also be scratched as few customers would care who made them. The third observed that it was not the custom locally to sell on credit, rendering the words “for ready money” unnecessary.
These changes left a sign reading: “John Thompson sells hats.” Then the fourth friend said, “But no one would expect you to give them away, so what is the point of ‘sells’?” Finally, someone pointed out that, given the painted picture of a hat, even the word “hats” was unnecessary. So the final sign bore only the words “John Thompson” and the picture of a hat.
Courtesy: speaklikeapro.co.uk
As a software programmer, I obsess over the least. As a simple example, I ask myself whether a SQL query I’ve written contains any unnecessary JOINs. Or, I’ll analyze whether everything in the SELECT statement is needed from all calling methods.
/* Get the number of users in account with ID = 28 */SELECT COUNT(1) FROM Users u
INNER JOIN AccountMemberships am on u.ID = am.RelatedUserID
INNER JOIN Accounts acct on acct.ID = am.RelatedAccountID
WHERE acct.ID = 28/* Or, alternatively, less code and no joins... */SELECT COUNT(1) FROM AccountMemberships am WHERE am.RelatedAccountID = 28
And what do the well-worn development principles of KISS (Keep it simple, stupid), DRY (Don’t repeat yourself) and YAGNI (You ain’t gonna need it) have in common? All hint at providing the least amount of output to solve the problem.
The least as an overarching strategy
Almost always, the outcome of implementing the least to achieve the desired goal results in the following benefits:
- A crystal clear message. Less words or less code, the end result is as refined and concise a message as possible. It results in less confusion and misinterpretation.
- A maintainable result for the future. The less superfluousness we add to the message now, the less we need to maintain, worry, or wonder about in the future.
- The smallest amount of strain on resources. Less stuff means we have less to transport or explain. It means everything from smaller packets to send across a wire to quicker roundtable meetings. Using the least output strategy will never go out of fashion.
Why the least is hard work
Answering the initial question successfully requires diligence.
As doers and implementers, it’s easy to fall into the lazy habit of simply trying to do as little as possible — at the sacrifice of the original goal. As thinkers and dreamers, it’s easy to fall into the lazy habit of doing more. More words, more servers, more features! These are easily contrived when we’re simply thinking about the problem on the back of a napkin. Honing in on what you can remove to clarify your message is where the hard work comes in.
