xKCD

Sharing is Caring

I am a software engineer by trade and, as a journeyman in this profession, I’ve experienced many small successes and numerous “failures.” I have witnessed and made many mistakes. While reflecting on how to improve the overall endeavor systemically, I came up with some rules of thumb. In time, I had reason to share these with others so that they might benefit from my experience.

Rules of Thumb

Software product development, like most things that provide value, often necessitates trade-offs between competing needs. There is a well-known project management concept involving Time, Scope, and Cost, where optimizing for one will impact the others. They are interdependent. There is an inherent mathematical relationship between them. Similarly, I assert that the following concepts form a sort of triple constraint that must be balanced to provide for the greatest likelihood of overall success. They are intended to provide a way to anticipate future problems and avoid repeating past mistakes.

x - Lessons from Failure

What better way to introduce a solution than to first define the problem in a way that others can appreciate. Individuals learn by building upon existing knowledge. New ideas must be attached to existing personal context for them to become useful knowledge. Therefore, there are two scenarios I use to introduce the ideas of KCD in order to make them effective.

Sometimes I have the good fortune to encounter a teachable moment. That is, a time in which something is perceived to have gone wrong and the involved parties are reflecting on how to avoid future occurrences. Alternatively, I introduce the ideas by asking members of a team to brainstorm past misfortunes experienced in the course of their career related to negative project outcomes.

Having these negative experiences in mind often provides a willingness to take advice. Not in the moment, mind you. You don’t want to distract from resolving a crisis. Rather, soon enough thereafter that the pain is still fresh enough to remember, but the panic has subsided.

These painful experiences provide examples for what “not” to do under future similar circumstances. To represent this, the obvious letter for “negation” or “not” is x.

K - Keep it Stupid Simple

KISS as many know it is often described as “keep it simple, stupid” but that can come across as derogatory or insulting. By transposing the SS in this acronym, I am placing emphasis on just how simple something should be by erring on extremely simple. Simplicity in software often means considering what is not strictly necessary to get to a viable solution.

It means avoiding speculative generalities (i.e., prematurely building features or introducing unnecessary abstractions) that might never be needed or only needed at a later stage. And, it can mean many other things… but hopefully you get the idea for now. Perhaps we’ll explore this more deeply in a follow up post. See what I did there…

C - Communicate, Collaborate, & Cooperate

The third letter in the English alphabet deserved three words to describe this idea of working with others. Building software is rarely a solo endeavor and is benefited by synthesizing the ideas and feedback of multiple contributors. Diversity of opinion increases the competition of ideas while strengthening team trust. Sharing knowledge promotes humility and increases confidence. Collaborating prevents institutional knowledge from becoming a barrier to organizational scaling and succession planning.

D - Do No Harm

Ultimately, developing software products is an act of problem solving, and in so doing it is important to minimize the likelihood of creating a different or even more severe concern. Addressing risks can be costly in a number of different ways, so choices need to be deliberate and agreed upon. It is important to anticipate as many possible adverse impacts as is reasonable, but then deliberately decide which will get attention and which are tolerable—at least for now.

Put it together and what does it spell?

Sorry, I couldn’t help myself. More seriously, the idea is that one must consider all three of these areas in order to make the most judicious and responsible decisions about what to build and how to build it. It will rarely be possible to completely satisfy all three simultaneously. Try to find balance by mitigating risks, sharing decision-making, and keeping things maintainable. Each situation may require a different balance, with one concern demanding more effort and emphasis. Just be sure to always consider how each affects the other to make the most informed decision.

Yet Another … blah, blah, blah

I know, I know, many people like to believe that they’re unique and inventive. It’s human nature. But most ideas are recycled and this is no different. This is more a reminder and food for thought than invention. And, putting it down “on paper” enables me to share these ideas more broadly, rather than keep them to myself, for better or worse. 😉

The ideas expressed above are obviously not novel. Heck, even the acronym was liberally borrowed from someone else and I attached previously nonexistent meanings to the individual letters of the word^٭. XKCD inspired me to marry humor-triggered “aha” moments (aka, epiphanies) with my high-level strategy for software development. Hopefully, it’s memorable and injects a little levity into moments of stress.

^٭ What does XKCD stand for? Sincerest apologies to Randall Munroe if this offends his sensibilities. I wanted an easy way for others to remember these rules of thumb.