<story><title>We invested 10% to pay back tech debt</title><url>https://blog.alexewerlof.com/p/tech-debt-day</url></story><parent_chain><item><author>hooande</author><text>&amp;gt; &amp;quot;You see, the leadership did not care about the code quality as long as the stories were delivered on time.&amp;quot;&lt;p&gt;My problem with the concept of technical debt is that &amp;quot;code quality&amp;quot; is subjective, and more often than not it translates to &amp;quot;I don&amp;#x27;t like the structure of this code because I didn&amp;#x27;t write it&amp;quot;. What matters to the business is that the code works. The owners of the business do not care if the developers enjoy working with the code or if they find it to be well written.&lt;p&gt;I hear all the time that bad code slows down development, increases bugs, etc. And that can be true in a number of cases. But most of the time it&amp;#x27;s just complaining. If a developer takes the time to re-factor the code base, it&amp;#x27;s very likely that whoever takes over from them in a few years will have the same complaints about technical debt and want to re-factor all over again.&lt;p&gt;The best way to ensure everyone&amp;#x27;s job and increase compensation is to deliver features that customers really want. Doesn&amp;#x27;t matter what the code looks like, as long as the customers are happy. Re-factoring is important to developers and to maintaining an organization. But it can wait until there aren&amp;#x27;t pressing feature demands.</text></item></parent_chain><comment><author>iopq</author><text>Not really. When each PHP page was copy pasted and slightly modified, I had to manually search to fix each bug and fix it in EVERY instance.&lt;p&gt;Are you going to tell me that this kind of tech debt doesn&amp;#x27;t affect my time to fix the bug? I could have done it once, now I have to hunt for 5+ instances of it. Am I just complaining or did doing the original development in a lazy way directly impact my time to complete the task?&lt;p&gt;I could have recorded the exact amount between the original bug fix and finally fixing the last instance of the bug to quantify how much time lazy coding cost me. It may have taken the same amount of time to write the original pages with an extendable component that only has one copy and takes arguments to create all the variations we need. But in the end we&amp;#x27;d have fewer lines of code to maintain in the future and that&amp;#x27;s also an objective metric.</text></comment>
<story><title>We invested 10% to pay back tech debt</title><url>https://blog.alexewerlof.com/p/tech-debt-day</url></story><parent_chain><item><author>hooande</author><text>&amp;gt; &amp;quot;You see, the leadership did not care about the code quality as long as the stories were delivered on time.&amp;quot;&lt;p&gt;My problem with the concept of technical debt is that &amp;quot;code quality&amp;quot; is subjective, and more often than not it translates to &amp;quot;I don&amp;#x27;t like the structure of this code because I didn&amp;#x27;t write it&amp;quot;. What matters to the business is that the code works. The owners of the business do not care if the developers enjoy working with the code or if they find it to be well written.&lt;p&gt;I hear all the time that bad code slows down development, increases bugs, etc. And that can be true in a number of cases. But most of the time it&amp;#x27;s just complaining. If a developer takes the time to re-factor the code base, it&amp;#x27;s very likely that whoever takes over from them in a few years will have the same complaints about technical debt and want to re-factor all over again.&lt;p&gt;The best way to ensure everyone&amp;#x27;s job and increase compensation is to deliver features that customers really want. Doesn&amp;#x27;t matter what the code looks like, as long as the customers are happy. Re-factoring is important to developers and to maintaining an organization. But it can wait until there aren&amp;#x27;t pressing feature demands.</text></item></parent_chain><comment><author>bcrosby95</author><text>I heavily disagree.&lt;p&gt;At the time of change, its obvious you&amp;#x27;re making the code shittier.  That function? It doesn&amp;#x27;t do what it says anymore.  That other function?  Just a few more boolean variables.  Hey, we don&amp;#x27;t need to refactor, we can just make negative numbers mean one thing, and positive ones mean another!  Death by a thousand cuts.&lt;p&gt;This is also the best time to refactor.  You skip the whole &amp;quot;I don&amp;#x27;t like the way the code looks&amp;quot; bullshit.  The codebase doesn&amp;#x27;t support your feature?  Make it support your feature, then code your feature.&lt;p&gt;And you know what else?  You are only changing code you&amp;#x27;re touching.  Refactoring code you don&amp;#x27;t need to otherwise touch is a waste of time.&lt;p&gt;But yeah, if you parachute in 6 months later to look for a refactor, its gonna be all gravy.  How much shittier your code is just a distant memory.  Get on that next feature - just another flag, just another lying variable - in &lt;i&gt;hindsight&lt;/i&gt;, it&amp;#x27;s all subjective anyways.</text></comment>