Debugging Teams: Better Productivity through Collaboration

by Brian W. Fitzpatrick

Offensive work is typically effort toward new user-visible features — shiny things that are easy to show outsiders and get them excited about, or things that noticeably advance the appeal of a product (e.g., improved UI, faster response times). Defensive work is effort aimed at the long-term health of a product (e.g., code refactoring, feature rewrites, schema changes, data migration, or improved emergency monitoring). Defensive activities make the product more maintainable, stable, and reliable. And yet, despite the fact that they’re absolutely critical, you get no political credit for doing them. If you spend all your time on them, people perceive your product as holding still. And to make wordplay on an old maxim: “Perception is nine-tenths of the law.” We now have a handy rule we live by: a team should never spend more than one-third to one-half of its time and energy on defensive work, no matter how much technical debt there is. Any more time spent is a recipe for political suicide.