In my last assignment, I was asked to mentor a software development team as part of the Dojo program. I am not a big believer in Training initiatives, but because Dojo program has a different format I decided to take up the assignment. The Dojo program involves working on a real project with the team, helping them embrace good software development practices, solving team’s real problems, and finally delivering a quality software. In this post, I want to talk about a lesson that I had shared with the team — the lesson which I named it as Validate your assumptions.
The foremost lesson is each time you make an assumption, write a simple unit test to prove that your assumption is correct. I know it is obvious, but over the last few years, I have seen many developers with whom I have been working with, build such wrong assumptions that they end up hurting the software they build. I am using unit test in a generic form. Here, unit testing refers to any mechanism that makes you question your assumption. It could as simple as a Google search.
One thing that I have learned in last 12 years as a Software Developer is — software development is full of uncertainties and unknowns. We work with technologies that we don’t completely understand, APIs we are not completely familiar with, business domains that we don’t fully comprehend. So, this is something which is bound to happen — we will build assumptions, each time. I don’t consider making assumptions are a trait of a bad Software Developer. Assumptions in some sense are like abstractions. They help us work at a higher level so that we don’t have to understand the internals. This is useful when you have to understand a piece of software.
The time the assumptions go wrong is when we face a problem and instead of understanding the cause of the problem, we make an assumption. Then, we use a dirty hack to solve the problem so that we can proceed forward. I noticed this pattern in my last assignment with multiple team members.
For example, a Junior Developer asked me a question, “Shekhar, why can’t we use a String key with . like abc.txt as the Map key?” For the first few minutes, I was in a state of shock. How can someone ask such a stupid question? We can use String with any text as the Map key. So, I asked him how come he made this assumption. He told me that he got an exception sometime back when he had used abc.txt as the key. As such, he made that assumption.
One way we might approach such situation could be tagging him as a bad developer who lacks the basic software development skills. Well, you can’t help if someone doesn’t know such a basic thing. The other way that we can approach could be — to try to understand the root cause of the issue.
The problem is not that he had made a bad assumption. We all make bad assumptions! The problem is that he didn’t take a minute out to write a simple unit test to validate his assumption. A two liner test could have told him that his assumption is wrong.
I keep a REPL or playground project running to test my assumptions. For me, the biggest benefit of unit testing is to validate my assumptions. I don’t care whether we do the test first or last. Using unit testing as a quick feedback loop to validate my assumptions helps me improve the quality of the software I write.
Shekhar Gulati 