On Fearless Development and Pair Programming

As a developer, it is easy to get lonely. You may work in a team, that you go to lunch with, do code reviews with and share out of office activities. But you are still working alone. In the sense that you are solving problems on your own. I wish teamwork was more like doing stuff together than putting stuff together you did on your own.

It is easy to get into some real time waste when solving problems on your own. It has often been said that one of the most important skills to have as a programmer is to know when to take a break from a problem. I have so many times sat in front of my computer and being unable to let go of a problem for hours, just to come up with the solution on my way home from work or while having breakfast the next morning.

I can sometimes feel a bit nostalgic, and even some kind of pride of my perseverance. But honestly, I think this is cognitive dissonance. I defend it because I did it. Because seriously, it is not fun. Does programming really have to be like this? I think not.

During recent years I have become more and more passionate about having fun at work and not feel stress. Two concepts comes to mind here; Fearless Development and Compassionate Coding.

I’m going to loosely define these concepts according to my own understanding.

Fearless Development

What is fearless development. Let me tell you a story from when I was younger and worked for a fairly big company. We were redoing the company web site from scratch. Don’t do that by the way. We had been working for at least half a year and were getting ready to launch. We were doing manual testing to build confidence for days before deploy and I’m sure we delayed the launch several times because of discrepancies we found. Then came the day when we finally launched.

We launched at night to minimize interruptions to the business. Today I would laugh in the face of this decision. It’s such a bad idea. When launching we had to migrate a bunch of data into a new database structure. We didn’t have a script to migrate back, so once we had migrated and started taking traffic there was no way to really go back so this was pretty much point of no return. And after that we started finding small bugs that kept us up all night.

It was so difficult to sleep that night. After we patched the bugs we had found, and when trying to sleep that night I couldn’t relax and just felt like I was waiting for a call to arrive telling me a serious flaw had been detected. Next morning I just remember being in the office, cranky as a toddler, almost breaking down crying for having to answer some basic questions.

I’m not joking if I’m saying I was pretty much working 36 hours in a row around that time. The sleep I got was almost wasted to anxiety. You think I would learn a lesson from this but I did similar things two more times. One night we sat awake in a server hall when we had moved our hardware to a new location and while I did feel pride once we were done; now I just feel like I was an idiot and nobody should have to go thru that. I slowly evolved anxiety towards making code changes because it often forced me to work while I wasn’t able.

What I just explained is the epitome of fearful development — being scared of your work. Fearless development is the idea that you never get into such a state. Today I have more knowledge, and as a community we have more tools to avoid this.

We have great version control systems like Git. And version control systems help us keep track of changes we do to our code. Because of it we can do Continous Integration which means we don’t have changes to code lying around that aren’t in use.

When we do Continous Integration it becomes natural to do Continous Deployment which means we should update what is run in production as often as possible in small increments. Continous Deployment helps us pinpoint a problem when something breaks.

Thanks to Virtual Machines and Containers it has become trivial to test changes with very high confidence. All these tools are awesome but there is something that I think is more important than tools when it comes to Fearless Development, and that is Shared Responsibility.

As a programmer it is easy to accidentally become the sole expert in a system. If you are the one the created a feature, even though it went thru review and many people have seen the code the person that wrote it alone will always be the expert and the goto guy when it runs into problems. This will never change until You change it and you change it with Pair Programming.

I think Pair Programming is so damn fun and important. When I worked at Spotify pair programming was highly encourage but in reality it was quite rare and at my last employer I don’t think I did pair programming more than once in 9 months.

I think that intuitively it feels like wasting time. Worst case scenario your boss don’t get it either. After all, two programmers working on two problems should get double the amount of work done. I think this is a myth. There are so many reasons team productivity can go up when pair programming.

• You are less likely to waste time going down a dead end. When pursuing a bad solution two persons are more likely to realize earlier.
• You also get autonomous knowledge sharing in the team. This can benefit hugely if the team gets a bug report which is hard to track down. If 10 people have a rough map of how their software works you are much more likely to hit the nail on the head when making an educated guess. This effect is know as the Wisdom of Crowds. You get this for free when you pair program a lot.
• When you code you often have these elusive bugs that make you think there is something wrong with your computer just to realize some ironic mistake was made. When you run into these alone, it can feel like you’re an idiot and you may be so enveloped in your ideas that you can’t even begin to explain it to someone. Being in this situation alone feels awful but being two idiots typing on the same keyboard and getting this, is like a festival of laughter.

It’s hard to quantify how valuable it is in the long run to do Pair Programming. But I found a study that tried to do that and their conclusion was

The development cost for these benefits is not the 100% that might be expected, but is approximately 15%. This is repaid in shorter and less expensive testing, quality assurance, and field support.[1]

If you start Pair Programming with your team today for the first time, it is likely there is no immediate return on investment. The benefits come later when you have shared a lot of knowledge and everyone is better aligned with how the teams software is built and what makes it tick.

And more importantly, never again does the responsibility of a feature burden one poor developer. Some people call this job security. I call it being reckless to yourself and your team. And I’ve been reckless like that a lot unfortunately. Don’t be like me.

References

The costs and benefits of Pair Programming

This is actually not a blog post, it is a script for a video I made.