Testing your assumptions

If I were to list some of the most dangerous habits observed in the way programmers work, I would definitely put making assumptions on this list. Let me explain. Recently, I have been debugging this one unit test that was showing signs of being a false positive. Turns out I was right about that and the reason was really simple – someone made an assumption that turned out to be false. Let’s face it – we have all been there at least once in our career (even once sounds too good to be true 🙂 ). We assumed that certain situation, outcome or combination of several factors is simply not going to occur only to receive a bug report confirming that this assumption was wrong. This often unconscious practice is really common and causes trouble all over the world.

What is the story so far?

We, as programmers, try to model and interpret the complex world around us which is error prone by default. By employing abstraction we try to reduce the amount of detail and low level knowledge we need to be aware of. This endeavor is easier now more that ever since there is a large number of libraries that provide tools for solving standard set of problems within one narrow domain. Date and time APIs are great example of this. Consider the amount of work necessary to implement at least half-decent in-house library to handle system as complex as Date and time API.

Having libraries like these to help us work with systems like time is incredibly helpful. But there are other systems of almost equal complexity that are not being covered in a same way. One of the reasons why, is that business might want to enforce certain level of conformity to the universal standards while omitting stuff they deem irrelevant for given product. The lack of understanding of the product or the target market and implications that it brings are also a good candidate. Names are good example of this in particular.

This type of assumptions stem from our fundamental lack of knowledge of given system so the expertise packaged in the libraries like these has immense value for us in our day-to-day development. This only goes to prove that seemingly trivial things can grow to unforeseen complexity with scale.

What is the solution?

In my honest opinion, there is only one sustainable solution to this problem – continuous education in this area. However it is unlikely one would go out and study the vast amount of resources required to understand each of these systems. Lucky for us there is a series of posts created by independent bloggers and software professionals sharing their knowledge about just how complex some of these systems can get. I highly recommend reading each of them since there is certainly something that you assume is not true or not gonna happen in your app. All of these posts share several common characteristics:

The title starts with ‘Falsehoods programmers believe about’

The content takes form of a short list of assumptions

The information presented is really helpful and valuable

Here are some systems that are heavily influenced by this – Falsehoods programmers believe about …