<story><title>Technical Debt</title><url>https://martinfowler.com/bliki/TechnicalDebt.html</url></story><parent_chain><item><author>kashyapc</author><text>[I recall posting this here in the past, but worth re-posting.]&lt;p&gt;The &amp;quot;handy rule&amp;quot; from the book &lt;i&gt;Team Geek&lt;/i&gt; -- the newer edition is called &lt;i&gt;Debugging Teams&lt;/i&gt;[1]. It&amp;#x27;s from chapter &amp;quot;Offensive versus Defensive work&amp;quot;:&lt;p&gt;&lt;i&gt;[...] 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.”&lt;/i&gt;&lt;p&gt;&lt;i&gt;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.&lt;/i&gt;&lt;p&gt;[1] &lt;a href=&quot;http:&amp;#x2F;&amp;#x2F;shop.oreilly.com&amp;#x2F;product&amp;#x2F;0636920042372.do&quot; rel=&quot;nofollow&quot;&gt;http:&amp;#x2F;&amp;#x2F;shop.oreilly.com&amp;#x2F;product&amp;#x2F;0636920042372.do&lt;/a&gt;</text></item></parent_chain><comment><author>CodeMage</author><text>&lt;i&gt;&amp;gt; If you spend all your time on them, people perceive your product as holding still.&lt;/i&gt;&lt;p&gt;This is precisely what bothers me about the vast majority of software out there. It&amp;#x27;s hard to find software that doesn&amp;#x27;t suffer from what I call, for lack of a better name, &amp;quot;forced evolution&amp;quot;: the devs keep fiddling with the UI and adding new features of dubious usefulness. Meanwhile, the quality slowly, but surely deteriorates: the software gets bloated, runs slower, becomes harder to use, etc.</text></comment>
<story><title>Technical Debt</title><url>https://martinfowler.com/bliki/TechnicalDebt.html</url></story><parent_chain><item><author>kashyapc</author><text>[I recall posting this here in the past, but worth re-posting.]&lt;p&gt;The &amp;quot;handy rule&amp;quot; from the book &lt;i&gt;Team Geek&lt;/i&gt; -- the newer edition is called &lt;i&gt;Debugging Teams&lt;/i&gt;[1]. It&amp;#x27;s from chapter &amp;quot;Offensive versus Defensive work&amp;quot;:&lt;p&gt;&lt;i&gt;[...] 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.”&lt;/i&gt;&lt;p&gt;&lt;i&gt;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.&lt;/i&gt;&lt;p&gt;[1] &lt;a href=&quot;http:&amp;#x2F;&amp;#x2F;shop.oreilly.com&amp;#x2F;product&amp;#x2F;0636920042372.do&quot; rel=&quot;nofollow&quot;&gt;http:&amp;#x2F;&amp;#x2F;shop.oreilly.com&amp;#x2F;product&amp;#x2F;0636920042372.do&lt;/a&gt;</text></item></parent_chain><comment><author>WrtCdEvrydy</author><text>&amp;gt;  If you spend all your time on them, people perceive your product as holding still&lt;p&gt;I&amp;#x27;ve always found this hilarious... we spend thousands on hiring developers and one of the primary goals is to find a well rounded person who is okay doing maintenance tasks and ensuring proper code quality and knows how to write effective tests. A short time later, I come on to a project just for a status update and find the developers cutting tests and maintenance tasks at the orders of the PO who then complains that tickets are getting larger and larger.</text></comment>