{"id":3923,"date":"2018-10-04T20:15:14","date_gmt":"2018-10-04T20:15:14","guid":{"rendered":"https:\/\/leap.staging.ribbitt.com\/insights\/avoiding-technical-debt\/"},"modified":"2018-10-04T20:15:14","modified_gmt":"2018-10-04T20:15:14","slug":"avoiding-technical-debt","status":"publish","type":"insights","link":"https:\/\/leap.staging.ribbitt.com\/insights\/avoiding-technical-debt\/","title":{"rendered":"Avoiding Technical Debt"},"content":{"rendered":"

Technical debt is a concept that explains the added cost that quick or hacked-together code incurs in a project over a long period. <\/p>\n

 When you write code that is “easy” without ever going back to test, you are adding to the overall debt in which interest accumulates over time. <\/p>\n

Now, technical debt can be addressed if properly tackled using refactoring – a process of optimizing, re-writing or organizing your code. In their book, ”Object-Oriented Software Engineering: A Use Case Driven Approach,” Ivar Jacobson, Magnus Christerson and Gunnar Övergaard, <\/em>warn eventually your software may fall victim to software entropy, a principle that states a systems disorder can only ever be increased or maintained, never reduced.<\/p>\n

Show Me an Example<\/h2>\n

As a contrived example, consider the following scenario…<\/p>\n

    \n
  1. Liz Lemon creates an app like YouTube that allows users to upload videos, create channels and leave comments.<\/li>\n
  2. As the launch day nears, Lemon finds several bugs that prevent videos from being uploaded under certain conditions.<\/li>\n
  3. Since this is an app breaking error, it must be patched before the launch date.<\/li>\n
  4. Lemon finds a way to patch it, but it’s not the most elegant solution. She decides to patch it now and then come back to it later to “clean it up.”<\/li>\n
  5. After the app launches, more bugs, of the highest priority, are reported.<\/li>\n
  6. Lemon spends the next few weeks patching bugs, completely forgetting about the patch she made prior to launch.<\/li>\n
  7. Months later, suddenly most users can’t upload videos. It turns out that early patch inadvertently created another bug that remained dormant until certain conditions were met<\/li>\n
  8. Now Lemon is having to revisit and repair that early patch with another patch<\/li>\n<\/ol>\n

    This example demonstrates that the app began to incur technical debt early on. The “interest” was never paid off, so it sat and accumulated until the “bank” hired a debt collector to come claim what was owed. Sometimes they will call you at home, sometimes at work, they’ll even call your family members or boss. Don’t let debt collectors be hired by your application.<\/p>\n

    There are many other ways technical debt can incurred. Some other factors include: <\/p>\n

      \n
    • Business pressure – It’s like barometric pressure, except it’s not.<\/li>\n
    • No processes – There are no clear and defined processes to updating\/adding code.<\/li>\n
    • Tightly-coupled components – Pieces of code that are tied to each other.<\/li>\n
    • No tests – Code that tests other code. Self-fulfilling prophecies.<\/li>\n
    • No documentation – “”<\/li>\n
    • Low adherence to standards – Twitter<\/li>\n<\/ul>\n

      OK, But What Can I Do?<\/h2>\n

      What could Lemon have done differently in the scenario to prevent the debt? Take the list of factors and invert each of them.<\/p>\n

        \n
      • Reduce business pressure (usually not in your control)<\/li>\n
      • Create a process that you follow rigidly<\/li>\n
      • Modularize your code into smaller isolated chunks<\/li>\n
      • Install a test suite <\/li>\n
      • Document everything<\/li>\n
      • Create standards and hold everyone to them consistently<\/li>\n<\/ul>\n

        If you work in a team, most of these should already be in place. If they are and you are still incurring debt, you will want to take a step back and review each of them and find where you are failing. <\/p>\n

        Working in a very small team, or even alone, can present its own challenges such as lack of code reviews and quality assurance. In my experience, the only way you will achieve limited technical debt is being extremely proactive. You must<\/strong> be your own manager and set yourself to the highest standard you can.<\/p>\n

        Takeaway<\/h2>\n

        The three biggest takeaways from this article should be to:<\/p>\n

          \n
        • Be proactive.<\/li>\n
        • Avoid the “I’ll go back and fix it later” by being honest with yourself. If you historically don’t go back and refactor, then do it right the first time.<\/li>\n
        • Create processes, and document everything for next time.<\/li>\n
        • If you use “TODO” comments (notes you make in your code to remind yourself to “come back and finish this later”), ensure part of your process is using an automated tool to find and flag any that are found in production code.<\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"

          Technical debt is a concept that explains the added cost that quick or hacked-together code incurs in a project over a long period.  When you write code that is “easy” without ever going back to test, you are adding to the overall debt in which interest accumulates over time. Now, technical debt can be addressed […]<\/p>\n","protected":false},"featured_media":3924,"menu_order":63,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[],"class_list":["post-3923","insights","type-insights","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorized"],"acf":[],"_links":{"self":[{"href":"https:\/\/leap.staging.ribbitt.com\/wp-json\/wp\/v2\/insights\/3923","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/leap.staging.ribbitt.com\/wp-json\/wp\/v2\/insights"}],"about":[{"href":"https:\/\/leap.staging.ribbitt.com\/wp-json\/wp\/v2\/types\/insights"}],"version-history":[{"count":0,"href":"https:\/\/leap.staging.ribbitt.com\/wp-json\/wp\/v2\/insights\/3923\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/leap.staging.ribbitt.com\/wp-json\/wp\/v2\/media\/3924"}],"wp:attachment":[{"href":"https:\/\/leap.staging.ribbitt.com\/wp-json\/wp\/v2\/media?parent=3923"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/leap.staging.ribbitt.com\/wp-json\/wp\/v2\/categories?post=3923"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/leap.staging.ribbitt.com\/wp-json\/wp\/v2\/tags?post=3923"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}