It’s not because I’m dumb (or not just because I’m dumb).
Readers of this blog will know that I have no shortage of opinions. I know what I think is the Right Way™ to develop software, but I have a hard time doing it when I’m a solo contributor. I’ve never written unit tests for a project where I’m the only (or primary) contributor. I’m sloppy with my git branching and commits. I leave myself fewer code comments and write less documentation. This is true even when I expect others may see it.
A few months ago, I was at the regular coffee meetup of my local tech group. We were talking about this phenomenon. I blurted out something that, upon further reflection, I’m particularly fond of.
Testing is a cultural thing and you can’t develop a culture with one person.
Okay, maybe you can develop a culture with one person, but I can’t. One could argue that a one-person culture is called a “habit”, and I’m open to that argument. But I would counter that they’re not the same thing. A habit is “a settled tendency or usual manner of behavior”, according to my friends at Merriam-Webster. In other words, it’s something you do. A culture, in my view, is a collective set of habits, but also mores. Culture defines not just what is done, but what is right.
Culture relies on peer pressure (and boss pressure, and customer pressure, etc) to enforce the norms of the group. Since much of the Right Way™ in software development (or any practice) is not the easy way, this cultural pressure helps group members to develop the habit. When left alone, it’s too easy to take the short term gains (e.g. not going to the effort of writing tests) even if that involves long term pain (yay regressions!).
If I wrote code regularly at work, or as a part of an open source project that has already developed a culture of testing, I’m sure I’d pick up the habit. Until then, I’ll focus on leading thoughts and let “mostly works” be my standard for code.
“Oh crap, I have to manage”
The logical extension of what I wrote above is that code testing and other excellent-but-also-no-fun practices will not spontaneously develop in a group. Once the culture includes the practice in question, it will be (to a large degree) self-perpetuating. Until then, someone has to apply pressure to the group. This often falls to a technical lead who is probably not particularly fond of putting on the boss hat to say “hey, you need to write tests or this patch doesn’t get accepted”.
Too bad. Do it anyway. That’s one of the key features of project leadership: developing the culture so that the Right Way™ becomes the way things are done.