My Real Life NullPointerException
Sometimes, it’s easy to see parallels* to software engineering in my daily life.
While biking, I hit a pretty big pothole on Hosea Williams the other day. I didn’t know if that was the Primum Movens of my flat tire, but the next day it was completely flat. I took it into a shop for a number of reasons: it was the first time I had a flat tire, I didn’t have the tool to remove the tire from the rim, I didn’t have a spare tube or a patch kit, and I didn’t have a lot of time.
The repair guy quickly took the tire and tube out, replaced the tube, and sent me on my way. I went up to Silver Comet for an 18mi ride, then went home.
The next morning my back tire was completely flat again. I searched the tire on the outside but couldn’t find the problem. I brought it back today and this other repair guy searched the tire, and found a small piece of metal (less than 0.5cm). Metal gone, new tube, I’m on my way again.
There’s a few points here. First, I need to spend the time to learn how to fix my bike. Second, I also need to put together a kit to keep in my bag with some basic tools, patches, pump, etc. Third, the next time I get a flat I know I have to search the tire for the problem. Fourth, I don’t really fault the first repair guy for not finding the piece of metal. It was also partly my fault for not thinking about it and asking him.
In software engineering, we need to have the right tools and the knowledge to fix problems that come up. There’s a pervasive RTFM culture out there, but mentors that filter all the possible ways to solve basic problems are rare. It simply takes time up-front to collect the right tools and learn how to use them. Software developers that don’t spend this time suffer over the long term.
The first repair guy is a typical software developer, coding for the optimistic case and overlooking an obvious problem. The piece of metal was his error to check for null and my NullPointerException. I also passed the buck onto him because I didn’t have my house in order. In the software world, this happens all the time and it’s unproductive to cast blame. When we work in teams, every developer is at a different level. Some know some tools better than others. Some use defensive programming techniques to avoid NPEs.
The ideal team dynamic here is that the rock star developers need to avoid laziness, and the other developers on the team should be willing to put in the time to improve. In the real world, things rarely line up this way. So, the challenge for managers and leads is in how to create the incentives to try and attain this dynamic. It’s an effort that I can’t really recall ever seeing in action.
* One can draw a degree of insight from observing similarities between software development other fields, as long as such observations are limited in scope. There’s a drawn out post I’ve been working on about the fallacy of analogies when applied to software development.