Embracing Uncertainty

Living In Uncertainty

There’s a fascinating aspect of regular life that shows up in the development profession. It is something that normal people have an aversion towards yet the exceptional embrace. It is uncertainty.

Uncertainty can be defined as the state of not knowing or lacking definition (derived definition from the Oxford dictionary and Google search results). It is commonly caused by lacking relevant, accurate information in a present situation or by looking forward into the future, unrealized events.

The experience of uncertainty is something that people have a natural revulsion towards. It relates to other unpleasant life aspects like chaos and danger because when uncertainty is present there is also a perceived lack of order and potential danger. This bothers normal people. We don’t enjoy not knowing, we don’t appreciate chaos, and we don’t dig danger. Our comforts are certainty, order, and safety – something society is constantly striving towards with varying degrees of success.

As uncomfortable as it may seem, it must be obvious that not all things are known, certainly not by every single person. It is also obvious that not everything is in order – things are constantly put out of place. Danger is very present and real. It has not been and probably will never be fully brought under the umbrella of safety.

Thus, uncertainty itself is a certain element of life to one degree or another. This is as hard to accept as it is undeniable. But, like other uncomfortable elements of life – once it can be accepted, it can be managed. This post is, in part, an invitation to managing uncertainty.

Uncertain Development

There are a number of uncertainties we often face in the development profession.

How many times has a software bug derailed the progression of a project? How many hours have been poured into such a bug to bring its behavior into alignment with the rest of the project’s flow or a customer’s particular needs? Bugs are a bane to productivity and reputation alike as they reveal uncertainty and deficiency within a project.

How often has a new or unknown technology been incorporated into a project? When has an existing, dependable technology been altered into a newer version? Both new and updated technology demand attention as they introduce mystery into a project. For new technology, that mystery is coupled with the promise of improvement or adventure. For existing technology, the change demands reason and validity as existing software prefers to stay the same.

Business requirements are a hotbed of uncertainty as they are typically borne as a dream-like notion that slowly comes into focus until they can be defined as actual work. This dream-to-definition transformation is the arduous process of understanding the nature of both company and customer until a technological solution is clearly defined that merges the two together. Sometimes that process is not fully completed. The better companies are those that understand themselves and their clients innately and are able to mold a dream into definition efficiently. There are some features and even entire technologies lacking clear definition through their entire lifespan, much to their detriment. No one wants their hard work to invoke a response of “What is this thing?”, a reaction that exposes the kind of uncertainty that leads to mild revulsion.

Bugs, emerging technologies, and business requirements can each individually bring a measure of uncertainty, generating dis-ease in our workflow. When they are combined, they intensify that sense of uncertainty. When you add in pressure of performance and efficiency, the job of a developer can become quite stressful.

Managing Uncertainty

How does one avoid such a perfect storm of pressure over a stressful project or career? By reducing uncertainty to a manageable state. This is done in part by knowing our own limitations and also by doing what we can to control our exposure to uncertainty.

Software bugs can be exposed and discovered by testing the software. The user base is the most effective discovery method for software bugs, but there are safer means that the developer can use before exposing users to that software. Live tests reveal the intention of a feature. Programmable tests, both isolated and integrated, reveal the context the feature is currently in and can expose it to various possibilities that it may encounter. Stress tests push the software’s limits. Regression tests consider iterations of change. In my personal experience, it is much easier to discover the nature and the cause of a software bug if one has a testable setup to subject the conditions of the bug to. This type of tooling gets the bug to a reproducible and diagnosable state efficiently so that I can take time to consider responsible solutions with less pressure (lowering the chances of new bugs in the same area). Without a testable setup, bug hunting can be very frustrating and time consuming.

Technology itself is a progressing, evolving ecosystem. Given time, anyone can become disconnected from what is relevant or mainstream (except fads – those are ridiculous). Proactive research produces awareness (and can also identify fads to ignore). I have found that if I spend small moments of time in my week seeking out proposed changes or new versions of technology that I depend on, I reduce surprise and confusion when the time comes to either consider actually incorporating new technology. This is, of course, as imperfect as testing code, but also reduces the uncertainty of progressing technology significantly.

Business requirements are possibly the most difficult of the uncertain aspects. Solutions geared towards bringing dreams to definition is primarily a human one. There are many tools to assist with the process. For example flow diagrams, mocking tools, prototypes, and sandbox environments; but the actual process of getting from a dream to definition requires people to bring that dream into focus. Using any or all available actualization tools aid in that, but one cannot pass off the vision to another without communicating a clear understanding of both the essence and nature of the dream itself. A thing must be realized to be communicated and constructed effectively. The science and art of doing this is what separates the novice from the wildly successful in our field of work. Too many people have attempted to construct something with a high degree of uncertainty and found themselves either frustrated or regretting the journey itself. That brand of regret is dangerous, as it is one reason (among many) that we see burnout in our field.

Remaining Uncertain

Uncertainty is a certain element of not only life itself, but also our jobs as developers. It can be reduced and managed by identifying tools that nurture definition and reduce danger, but it cannot be eliminated entirely. Certainly there will always be a certain measure of uncertainty in development. Those that accept this, account for it, engage with it, and ultimately embrace this truth become much more equipped to succeed as things move forward.

Don’t avoid uncertainty. Embrace it.