Managing complexities in complex domains

One of the main reasons software development is difficult is because we deal with complexity. Let's see how we can use pair programming in complex, difficult situations, when it helps us, and when we should use other tools instead.

Managing complex domains

The more complex the business domain, the more you need pair programming. And let's face it: even the simplest business domain is complex nowadays.

In areas such as banking, trade, or travel, you can expect from the start that you will have a lot of complexity on your hands. Typically, code written in complex areas tends to be worse in the beginning. It's the "first half-baked draft" that writers so often refer to. This is because writing code is not that different from writing an article, a novel, or a series of novels if you work in a very large organization.

Writers say that it's a good idea to quickly write what's on your mind. No matter how much you struggle to write the perfect first version of your text, there is only one conclusion: it will be horrible. The first draft should be like a lump of clay that you shape after several iterations of reading and improvement. The only problem is that we have a blind spot for errors we've created ourselves. That is why, especially in a complex domain, code review is always a good idea. Or even better, we can speed up the code review with pair programming.

Iterative development happens even in the smallest of programming tasks. We create the simplest form of solution, and then we ask for feedback. The beauty of pair programming is that this feedback comes almost instantly from our pair. Because of this, we feel that we can tackle complex problems easier if we work in a pair.

Difficult tasks

Sometimes, we might feel overwhelmed by looking at a complex task. And we might even procrastinate, just fearing that the task is too difficult, or thinking that we need to prepare more in order to face the new task. This usually happens with tasks that are in a new area for us, something that just attacks our self-perceived competencies. Working in a pair will reduce that fear. It's not just me who's fighting the dragon; I have a pair and if something bad happens, we can think about what to do together. Often, that thought makes me feel like we can get through it.

Pair programming on difficult tasks needs to be done between programmers who have the same level of experience. It doesn't make any sense to have a senior-junior pair, as the junior will be completely lost. The only good solution is to have a senior-senior pair, with the focus on getting things done, rather than a learning focus.

There is this misconception that all pair programming sessions are about learning. In fact, especially in complex domains, we have many more pair programming sessions focused on solving tasks and getting things done.

Context is important. If you have more time at hand, it's a good practice to do pair programming both with highly experienced programmers to advance the task, and with less experienced programmers with the purpose of them learning what the most experienced pair is doing. But if we don't have the time at hand and we need to deliver, we should focus on getting things done. Then, after the delivery or deployment, we need to plan some learning sessions for the less experienced programmers.

The fastest feedback code review

A good coding practice is code review. It has been around since the beginning of programming as a format for formally inspecting code. It can be used to improve the code's format and logic, or as a way to distribute coding or domain knowledge. Typically, the code is written and then there are one or more programmers who will formally review the code. The programmer who wrote the code reads the reviewer's comments and improves the code. Then, the code is passed through the code review once more. This keeps happening until the reviewers accept the code as it is. Because the subsequent code reviews can take a long time, the code can only be said to be done after many days. It can even take a few weeks for the initial code to pass the cycle of reviews and changes.

Let's think about how the code review can be done while the code is written. We have a driver, the person who writes the code, and the navigator, the person who observes mistakes, incorrect names, logical errors, domain mistakes, performance issues, and so on.

If we go by the classical code review format, we have a few weeks to get from the initial form to the final form, but with pair programming, you only have a few hours. Also, by using pair programming, we remove the overhead of writing improvements, reading improvements, and having meetings to understand the given feedback. Also, the overhead of learning how to use a tool for code review disappears.

Since it is a good practice to have more points of view when we're doing code reviews, we could do the same with pair programming. We can change the pairs often, so that more programmers can look over the same code while working on the feature.

Minimizing the defect rate

One direct outcome you would expect is to have less defects in the code that was written by using pair programming. The reason for this is simple: two heads are better than one.

The cost of fixing a defect becomes higher and higher as time passes. The classical approach of fixing bugs, analysis - coding - testing - analysis - coding - … - done, can take a long time for a new feature. And the defects that were not caught in this very long cycle will be even more difficult to catch later, after the code is in production. The more time passes by, the more difficult it will be for anyone involved in that task to remember what is going on. That is why we need to find ways to minimize the defect rate right from the beginning. We can maximize the feedback loops in order to minimize the defect rate.

Besides having a cross-functional team that uses practices such as continuous integration, unit testing, or test-driven development, a very good practice that's used to minimize defects is pair programming. With pair programming, you can catch simple logical mistakes in a second, just because you have a navigator who is always watching and trying to understand the code the driver writes. You cannot have a shorter feedback loop than a few seconds when you're fixing a defect!

Complexity is a hard thing to grasp, especially when you are in the middle of the action. It's like wanting to count how many trees are in a forest, while you are in the forest. The first thing you must do is go back a few steps and get a bigger picture of everything. Apparently, obvious things can help us: fast feedback, transparency, openness, and close collaboration.

Next, we'll discuss how we can make our future selves' lives more comfortable!