This post is part of a series on amplifying value delivery through project strategy and technical dynamics. See the previous entries on the compounding value of developer time and systematically exploiting opportunities for background.
My last post articulated how, with a stellar development team, the value of developer time compounds, much like a financial investment. A team that's working well and optimizing accordingly approaches work in a way that makes future work easier, not merely delivering one feature after another. Even middle-of-the-road teams are likely to have the opposite effect: an accumulation of technical debt that slows down over time. One tricky element of this, though, is that those teams may be doing the same things and getting different results.
Creating Conditions for Compounding Developer Time
Creating the conditions for compounding value is a subtle business and requires a detail-oriented approach to the work. You must make continual and careful trade-offs. Something that provides tailwinds to one time might provide headwinds to another. The devil is in the details!
Take, for example, continuous integration (CI). Setting up services to automatically build and run automated tests as project code changes is an industry-wide best practice. Done well, it gets faster feedback to teams when something breaks. It also helps developers stay focused on the task or story in a productive flow state instead of frequently having to pause as your computer runs those processes. The faster feedback cycle and reduced disruption provides an acceleration effect on the team's value delivery. Ideally, at least.
Complications
But the acceleration effect isn't guaranteed. A whole host of issues can dampen or even reverse the effect:
- Test suites and CI infrastructure can be flakey or unreliable. CI that fails intermittently with false positives introduces a distraction rather than alleviating one. Rerunning tests and investigating chronic issues creates drag that slows down the team rather than speeding it up.
- Merging code into the main development branch is often gated on tests passing. Slow test suites create a barrier to getting work merged. This breaks the developer or pair out of flow state and forces them to wait. Delays in merging code can impact other team members as well if they end up having to retroactively merge in changes held up by the test suite.
- Testing methodologies that are not careful can have little value for catching regressions and can make it harder to change the system since the tests are coupled to internal implementation details. (For example, tests that make too heavy use of mocking can have this problem.) These test suites create busy work for the team and may provide less value at a higher cost than tests implemented differently.
Details Matter
The details matter when it comes to development team effectiveness. Checking the box of, e.g., having CI isn't enough. It can even be counterproductive. Exploiting any opportunity has associated risks. A big one when it comes to team productivity is the consequences of poor execution. This is true not just of CI and test suites, but just about any tool, process, or abstraction. Any of these might bend the cost curve in the wrong direction if you're not careful.
To help avoid these risks, here are a few tips:
- Think carefully about how to exploit opportunities and adjust your strategy if the wins don't materialize.
- Foster a team culture of critical thinking and continual reevaluation of practices and detailed critique of how they are playing out in practice.
- Focus on the specifics of your project and actual situation instead of reasoning in abstractions. Maybe a particular practice is generally good but your specific implementation of it is not. Don't defend counterproductive specifics with appeals to the values of the thing in general. In your case, you may better off rethinking it from the ground up or abandoning it altogether if you're in negative value territory
The Benefits of Attention to Detail
Pay attention to the details and specifics. Don't fall into the trap of categorical thinking. And, don’t fall for the illusion that having an X is by definition good instead of making sure your specific X is actually good for your project, your client, and your team.