app/notes/20180423-0458.md
Optimize the Develop-Test-Debug Cycle
develop-test-debug
1524459517
(This is essentially a rewrite of [core-metric-developer-productivity](https://www.albertyw.com/note/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.