The Devil of Deltas

The degree of diabolical a given delta can be classified as is directly proportional to the size of the delta. The larger the delta, the more diabolical it is.

Deltas in Testing

You’re writing some code. Presumably that code has some tests. You make some edits to your code and your run your tests to confirm the hypothesis of your edit. If the tests pass, you continue writing code. If the tests fail, you stop writing code and get the tests to pass. If you encounter a test failure, your ability to diagnose the failure goes down as the amount of code you’ve written since the last successful test execution goes up. The more code you write in between test executions, the harder it’s going to be to diagnose failures.

The larger the delta between test executions, the harder it is to diagnose failures. This is why I prefer to use continuous test runners whenever I can.

Deltas in Branching

You’ve got a new feature to write. You check out master, create your feature branch and get to coding. After a few days, some bug fixes get made in master. After a week, some other feature gets merged back into master. Two weeks go by and your feature is complete. You pull down master and attempt to merge – or so you thought. There is a substantial delta between your branch and what master has turned into since you created your branch. The merge is horrific, takes a few hours and in the end you stomp one of the bug fixes. After some integration test failures you find the bug fix that you squashed and reimplement it. You then drive home, yelling at everyone on the freeway as you commute because merging branches with a large delta sucks.

Big branch merges take lots of time and lower morale. No branch merging mitigates these problems. This is why I prefer trunk based development.

Deltas in Shipping a Product

You’ve got a completed project plan in hand. The user stories have all been carved out, the appropriate tshirt sizes have been assigned. You spend the next 4 months working on the first deliverable. The sanctioned day of release arrives and you ship the product. Sitting back in your chair, you await the accolades that are bound to come. But they don’t come. You never verified that what you were building was what your customer actually wanted, you never bothered to let your customer assess your progress and correct course as necessary.

Big projects don’t work. Constantly adding value and receiving feedback from your customers avoids the big project failure. This is why I prefer to integrate early and often.

Close the Feedback Loop

I believe that it is paramount to shorten feedback loops in our industry. Build a little, confirm that you got it right. Build a little more, confirm that you got that right. Doing so mitigates risk and helps to maximize the investment in your project. What do you think?

500 Words

2017-10-12 06:00 +0000