Distraction Driven Development (DDD)

Imagine this: You’re working a critical new feature, one your team anticipates will not only be really popular with your existing users, but which will organically drive growth by attracting a large number of new users. While you’ve been working on this over the last couple of weeks, you’ve noticed a couple dozen minor issues that you fixed as you encountered them. Now your development work is complete, you’ve created a pull request to merge the completed feature into your main branch, ready for release – but almost all of the code changes relate to minor fixes, not the feature itself.

Worse, two of those minor fixes would cause data loss if they got into production, so now you need to carefully reverse those fixes without introducing additional problems.

Distraction Driven Development happens when you include in a lot of unrelated minor changes as you work on a feature, resulting in a branch (or pull request) that addresses many different goals.

Let me be truly clear: the problem here is not that you fixed the minor issues that you saw. You should absolutely fix these issues as you identify them. This kind of ongoing code gardening is an important way to maintain, and even improve, the quality of your code over time.

The problem comes when the fixes become comingled with feature work and each other, making it an all or nothing proposition when it comes to accepting or rejecting the change.

Instead, commit the fixes to separate branches and create multiple pull requests, each specific to changes that affect a single area of your product – a single layer, a single assembly, a single service. This is the single responsibility principle of object-oriented development as applied to change.

Splitting up the fixes also serves to share the load of reviewing. A single large pull request is exponentially more difficult to review than a set of much smaller pull requests, each with a separate intent and purpose. As a side effect, small pull requests are easier and quicker to understand, with reviewers more likely to spot subtle errors and mistakes.