[...] After this bad experience, Ben began to categorize all work as either “offensive” or “defensive.” 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 sexiness of a product (e.g., improved UI, speed, or interoperability). Defensive work is effort aimed at the long-term health of a product (e.g., code refactoring, feature rewrites, schema changes, data migra- tion, 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.
- "Being Geek: The Software Developer's Career Handbook" https://www.amazon.com/Being-Geek-Software-Developers-Handbo...
- "Team Geek: A Software Developer's Guide to Working Well with Others" http://shop.oreilly.com/product/0636920018025.do -- Software engineering teamwork a-b-c. I'd love to work on teams where everyone has read this one.
[edit: 2nd edition of "Team Geek" is titled "Debugging Teams"; having read both, no difference which you get]