Over the last few years, Michael Niessner and I have spent a lot of time looking at patterns that predict the success and failure of both software products and software engineers. Weâve done this both to improve our success rate at HubTran, but also to help us understand how to hire better software developers. While weâre still working on finding the secret to success and better hiring, weâve found at least one combination of traits that is a sure sign that failure is around the corner. If we see Assumptions and Confidence, we know weâre looking at trouble.
Now, that might be surprising to those that know me. Iâm pretty sure Iâve never been accused of lacking confidence. While I may be very (over)confident in my day to day life, I try hard to make sure that doesnât bleed through into my software and product life. As a person who is quite confident, I take special care to think about my assumptions. For example, letâs say Iâm building a system that allows you to create and process invoices for truckload shipments. To store the invoice, I can add an
invoice_id column to my
Load model. At this point, I try to ask myself what assumptions am I making and what is the impact if these assumptions are incorrect. In this case, Iâm assuming that there can only be one invoice on each truckload. Is that a good assumption? It turns out it isnât. If you never stopped to call out this assumption and do the work to learn if it is valid, you wouldnât know that. Instead, you would keep building software that wouldnât work once it was faced with real world scenarios.
Weâve seen quite a few developers make this mistake. When asked what happened, we often hear âThe requirements didnât specify there wouldnât a single invoice on each truckload.â While thatâs true, the requirements also didnât specify there would be exactly a single invoice on each truckload either. To me, knowing what assumptions you are making in translating your view of the world into code is a critical skill to have.
Knowing what assumptions youâre making isnât sufficient to do things right. You also need to verify that your assumptions are valid. This could mean talking to a domain expert. It could instead mean looking through data for counterexamples. The best developers we know are experts at understanding their assumptions and knowing which assumptions are likely to cause problems down the road. They then spend time worrying about high risk or high cost assumptions and worry less about non-critical or easy to change assumptions.
These same developers are experts at finding cheap and easy ways to test their assumptions.
Kent Back has made a career in thinking about the assumptions that underlie the status quo and asking what happens if they are wrong. He discusses this in the Unlearn podcast by Barry OâReilly. By using thought experiments to decide what the outcome of an assumption being incorrect would be, Kent can quickly test ideas to decide if they are interesting enough to experiment with.
We will often do something similar at HubTran. We want to perform sensitivity analysis around our assumptions. Recently, we had a member of our team mention that a certain step in our process was time consuming. He was thinking about whether we could make it faster and had spent several days working through some ideas for enhancements. Before we spent developer time on these changes, however, we wanted to test the assumption that this issue was causing our customers real pain. When looking at real world usage, it turned out that this flow was hit only a few percent of the time. Our team member was often tasked with training new accounts before HubTran had finished learning. In his experience, this was a real problem. Looking at data, it turns out to not be much of an issue. If we hadnât checked that assumption, we would have spent weeks optimizing a very minor issue.
I hope itâs clear that Iâm not saying you shouldnât be confident, or that you shouldnât make assumptions. Both are critical to building software. Instead, I hope you will consider when it makes sense to validate the assumptions you are confident in. As weâve seen, the best developers have mastered this skill. With practice, we believe you can too.