Optimize the Develop-Test-Debug Cycle

April 22, 2018

(This is essentially a rewrite of core-metric-developer-productivity).

Increasing developer efficiency is oftentimes one of the highest priority goals of engineering orgs at companies ranging from startups to megacorps. With the high price of developers and notoriously bad adherence to deadlines, it’s quite normal for a company to want to speed up development time. Many organizations try various process tricks that read like it was written by an MBA student - agile, scrum, kanban, lean, to name a few. While many of those processes are good ideas, I feel many people lose focus on engineering issues that cause bad developer productivity.

I think that a core principle for optimizing and scaling developer efficiency is that many companies operate on a loose form of test driven development, and that most programming work is spinning within a cycle of “development” (writing production code to satisfy some business problem), “testing” (asserting the correctness of “development"), and “debugging” (making fixes to “development” given the feedback from “testing"). Many developments in computer science and software engineering have been aimed at speeding up (e.g. usage of IDEs) or short-circuiting (e.g. strongly typed languages) this cycle. I would recommend that any company which relies on an effective engineering department pay attention to the speed at which developers can move through this develop-test-debug cycle.