Plan Productivity into the Product

As of this writing, my current title is “Developer Productivity Engineer”. It’s the first time I’ve had this title; and, frankly, I don’t think the title itself has been around for very long. Now, I’m not particularly keen on buzzwords… I’ve had a lot of titles over the years, but from my perspective the overall objective of what I do has changed very little (although the way I do it certainly has). I do rather like this one, however, because it’s the first title I’ve ever had that I feel best encapsulates my role, which is to engineer tools, processes, workflows, and interactions across teams with a view towards helping developers be more effective.

The simple fact is that every software project has (and has always had) one or more Developer Productivity Engineers, whether or not they have the title. They are simply the people who make the decisions which most affect developer productivity; the real question is whether or not they realize that’s what they’re doing. Every software project has to take multiple goals into account: performance, scalability, cost to operate, etc. I think that developer productivity needs to be one of those goals; otherwise the project risks running into bottlenecks, friction, and delays that all impose hidden costs – often late in the development cycle.

Some examples of decisions which can have a high impact on productivity:

• Choosing a release plan that minimizes version control hassles. For instance, using a trunk-based, continuous-delivery workflow instead of long-lived release branches will reduce issues from merges, cherry-picking fixes, etc. (This may not be optimal for a given product’s release cadence, of course – but that needs to be taken into consideration early on.)
• Optimizing for development and testing by making it easy to create ephemeral deployment environments. These allow devs to have a local, private, near-complete environment to experiment with and test on before merging changes. Complex, hand-crafted “DEV” and “STAGE” shared environments inevitably cause bottlenecks when they get broken by changes under test. It’s a lot easier to design a deployment environment with support for this baked in from the beginning than it is to figure out how to retroactively do it.
• Iteratively working on all the last mile problems from the beginning, like how to deploy, update, and monitor the application. When coupled with the use of ephemeral environments, this allows a team to basically “dogfood” the entire release/update/support process before the product is in the hands of customers. Not only does this improve development speed, but it also provides valuable debugging of the release process.
• Encouraging high collaboration to avoid bottlenecks and silos. It is both risky and expensive to have knowledge locked up in a single team (or developer!). Clear and early communication of design decisions and directions across teams provides “continuous integration” at a level above code and reduces the chance of surprises later on.

Decisions like these, once made, often influence the design and architecture of the product itself. When following a “test-driven development” approach, before writing any code a developer asks the question “How am I going to test this?” Writing code specifically to be tested often changes the design of the code being written. Similarly, asking questions early on like “How am I going to deploy this?” or “How am I going to monitor this?” can affect how the application or its deployment environment evolve. At every step of the development process, someone should be asking “How can we do this in such a way as to maximize developer productivity?” Ideally, everyone on the team should be thinking this way; but if they aren’t (yet), maybe you might want to invest in a Developer Productivity Engineer.