Building software is hard. We struggle with asynchronous operations, distributed systems, and concurrency. When we are trying to figure out how to solve a given problem, we take an approach that is guided by a set of assumptions. These assumptions are critical tidbits of info that help blaze our trail toward making our plans a reality…
Until they don’t…’cause sometimes, they won’t. Sometimes, they guide us down the wrong path due to a flawed assumption along the way.
The Role of Assumptions
An assumption is a statement which is believed to be true and from which a conclusion can be drawn. We can’t avoid making assumptions, and they can be very helpful. But it’s essential to remember that assumptions are not facts.
We come to assumptions based on other findings, or even our gut instinct. With each assumption we make, we are increasing the risk that we are heading down an incorrect path.
When you are troubleshooting a problem, you make an assumption. You then perform some type of experiment to prove whether or not the assumption is true. While one can be quick to jump to a conclusion, it’s best to go at least one step further to validate that assumption from a different angle.
Stuck? Review Your Assumptions
It is important to review our assumptions when we hit a sticking point. One measly incorrect assumption can head us down a incorrect path that will waste a lot of our time. The more often we list and question our assumptions, the easier it will be to avoid heading down the wrong path. Reviewing our assumptions can help minimize the disruption caused by misdirections.
Apply the transitive property
The Transitive Property of Equality states:
If A = B and B = C, then A must equal C.
If we have made an assumption that A = B, we can cross-examine that assumption if we know, or can prove, that B = C. Once we can prove the second equation, we also know that A = C, an equation that allows us to perform additional sanity checks.
Being able to test assumptions from another perspective can either disprove or support our original assumption. This can either lead us down a new path, or simply give us confidence that our current path is sound. Both are valuable outcomes.
Find where you went wrong
At Atomic Object, we practice Test-Driven Development to help validate assumptions along the way. When tests are run in automation, they can catch unexpected changes in the behavior of a system.
However, in reality, some things are difficult to test and automate. In situations like that, we lose our safety net, taking hits to our productivity, creativity, and of course…our sanity.
One particular situation that can be problematic is doing spikes.
A spike solution is a very simple program to explore potential solutions.
Spikes are supposed to be quick, focused stabs at various solutions, arming us with more knowledge and confidence in our direction when we attempt the real thing.
Unfortunately, the line between spikes (and other experiments) and the real thing is not always as clear-cut as desired. We are human. We make mistakes. We cut corners when under pressure to deliver.
If you have to circumvent the proper protocol, make notes of the corners you cut along the way, or the things that made you skeptical before you decided to move on. It’s all too easy to lose track of these things and never come back. Then, eventually, you realize that one little thing you dismissed or failed to invest in has come back to haunt you. It’s a terrible sinking feeling…
Bottom line, software development is hard. We use more and more third-party libraries and frameworks than ever, since we don’t have the time to write everything from scratch. We assume, or at least give these third-party pieces the benefit of the doubt that they just work.
We also tend to assume that things we have proven to ourselves in the past will continue to hold true. We must maintain our skepticism of all the things to return to and/or stay on the path of success.