{"id":11240,"date":"2022-01-18T19:09:34","date_gmt":"2022-01-19T01:09:34","guid":{"rendered":"https:\/\/threecloud.wpengine.com\/?p=11240"},"modified":"2024-02-28T07:46:01","modified_gmt":"2024-02-28T15:46:01","slug":"drowning-in-technical-debt-start-understanding-it-better","status":"publish","type":"post","link":"https:\/\/3cloudsolutions.com\/resources\/drowning-in-technical-debt-start-understanding-it-better\/","title":{"rendered":"Drowning in Technical Debt:\u00a0Start\u00a0Understanding It\u00a0Better"},"content":{"rendered":"

In our series,\u00a0<\/span>Drowning in Technical Debt<\/span><\/i>, we\u2019re digging into\u00a0<\/span>the<\/span>\u00a0commonly used but\u00a0<\/span>often misunderstood phrase \u201ctechnical debt\u201d<\/span>, with a mission to help more organizations identify it and\u00a0<\/span>work toward a\u00a0<\/span>more\u00a0<\/span>manageable amount of it.<\/span>\u00a0<\/span>For this first post, we\u2019re defining technical debt and looking at how it can creep into organizations.\u00a0<\/span>\u00a0<\/span><\/p>\n

Do you see your development team working hard, but still not delivering the value they\u2019re capable of? Do you find yourself saying, \u201cThings weren\u2019t always like this,\u201d implying the problem has grown worse over time? Do you regularly hear, \u201cWe can\u2019t do that yet, because that part of the system will break if we change it\u201d? Your organization\u2019s total technical debt could be the culprit of\u00a0all of\u00a0these pain points, and\u00a0<\/span>others that you\u2019re not even aware of yet.\u00a0\u00a0<\/span>\u00a0<\/span>\u00a0<\/span><\/p>\n

What\u00a0<\/span>Is Technical Debt?<\/span>\u202f<\/span>\u202f<\/span>\u00a0<\/span><\/h2>\n

Technical debt is a metaphor designed to help\u00a0<\/span>us<\/span>\u00a0understand where\u00a0<\/span>we\u2019r<\/span>e borrowing development time today, only to repay it in the future. Ward Cunningham, one of the co-authors of the\u00a0<\/span>Manifest<\/span><\/i>o<\/span><\/i>\u00a0for Agile Software Development<\/span><\/i>,<\/span>\u00a0<\/span>first c<\/span>o<\/span>ined the phrase<\/span><\/a>\u00a0i<\/span>n 1992:<\/span>\u00a0<\/span><\/p>\n

“Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite… The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as\u202finterest\u202fon that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation,\u202fobject-oriented\u202for otherwise.\u201d<\/span>\u00a0<\/span>\u00a0<\/span><\/p>\n

In 2009, Cunningham went\u00a0<\/span>even further\u00a0<\/span>to\u00a0<\/span>address a common mis<\/span>i<\/span>nterpretation<\/span><\/a>\u00a0of technical debt as motivation for refactoring.\u00a0<\/span>\u201cThe ability to pay back debt,\u201d he sa<\/span>id<\/span>, \u201c\u2026depends upon you writing code that is clean enough to be able to refactor as you come to understand your problem.\u201d<\/span>\u00a0<\/span>\u202f<\/span>\u00a0<\/span><\/p>\n

How Our Organizations Accrue Technical Debt<\/span>\u00a0<\/span><\/h2>\n

Among the\u00a0<\/span>experienced\u00a0<\/span>Agilists<\/span>\u00a0<\/span>at 3Cloud<\/span>, we\u2019ve see<\/span>n<\/span>\u00a0<\/span>the full spectrum<\/span>\u00a0of technical debt\u00a0<\/span>across<\/span>\u00a0<\/span>healthcare<\/span>,<\/span>\u00a0insurance<\/span>,<\/span>\u00a0financial services<\/span>, and more<\/span>.\u00a0<\/span>Even across these diverse sectors, we\u00a0<\/span>often<\/span>\u00a0see companies building up their technical debt\u00a0<\/span>in three ways<\/span>.<\/span>\u00a0<\/span><\/p>\n

1. A<\/span>\u00a0<\/span><\/strong>S<\/span>trategic<\/span>\u00a0<\/span><\/strong>Decision<\/span><\/h3>\n

As with financial debt, sometimes you need to borrow from the future to realize a benefit today. Used strategically, technical debt is a tool that can help you get to market fast. For example, say your development team gives you two options:\u00a0<\/span>one that gets value out the door in two weeks with a solution that\u00a0<\/span>the<\/span>y know will likely cause performance issues down the road, and one that delivers the same value in two\u00a0<\/span>months<\/span><\/i>\u00a0but also introduces new architecture to support long<\/span>–<\/span>term scalability throughout the system<\/span>.<\/span>\u00a0Choosing the two-week option could allow you to deliver a small scope quickly, while\u00a0<\/span>still\u00a0<\/span><\/i>creating a good end user experience<\/span>.\u00a0<\/span>However, it also means you\u2019ll consciously bake a known performance problem into the product, which your team will have to eventually deal with.<\/span>\u00a0<\/span><\/p>\n

You also<\/span>\u00a0might decide to accept technical debt when you\u2019re sunsetting an application. You don\u2019t need to invest in the long term when you know you\u2019ll be migrating to a new platform.\u00a0<\/span>\u00a0<\/span><\/p>\n

2. L<\/span>earning\u00a0<\/span>E<\/span>xploration<\/span><\/h3>\n

For example, imagine your team\u00a0<\/span>has been tasked with creating a single<\/span>\u00a0<\/span>sign<\/span>–<\/span>on experience for users<\/span>. S<\/span>ince no<\/span>\u00a0one<\/span>\u00a0on the team has expertise in this area, they decide to roll their own provider rather than using an off-the-shelf solution. Later, the team learns\u00a0<\/span>about\u00a0<\/span>existing solutions, but the hand-rolled solution is now baked into the core of\u00a0<\/span>your<\/span>\u00a0application.<\/span>\u00a0<\/span><\/p>\n

3. P<\/span>rocess-Induced Debt<\/span>\u00a0<\/span><\/h3>\n

The process-induced variant of development debt is not strategic, resulting instead from a culture that doesn\u2019t enable your team to deliver quality code. Author and engineer\u00a0<\/span>Robert \u2018Uncle Bob\u2019 Martin<\/span><\/a>\u00a0<\/span>goes so far as to define this separately, saying\u00a0<\/span>\u201ca mess is not a technical debt.\u201d While strategic tech debt decisions \u201care made based on real project constraints\u201d\u2013meaning \u201cthey are\u00a0risky, but\u00a0can be beneficial\u201d\u2013unreasoned\u00a0<\/span>tech\u00a0<\/span>debt is not based on project constraints<\/span>\u00a0and is solely based on what your culture allows (or most importantly doesn\u2019t allow) your team to accomplish.\u00a0<\/span>\u00a0<\/span><\/p>\n

Say your team is working nights and weekends to hit a deadline, and you skimp on testing because \u201cwe have to hit this date\u201d and \u201cour scope can\u2019t change.\u201d\u00a0<\/span>Unrealistic timelines without the option to vary scope will create this most insidious form of technical debt.\u00a0<\/span>\u00a0<\/span>\u00a0<\/span><\/p>\n

\u00a0<\/span>Where It All Leads<\/span>\u00a0<\/span><\/h2>\n

If you don\u2019t keep track of how much technical debt you\u2019re accruing, it\u00a0<\/span>will<\/span><\/i>\u00a0<\/span><\/i>impact your business\u00a0<\/span>because you won’t know how bad things are until you<\/span>\u2019re\u00a0<\/span>overwhelmed with<\/span>\u00a0<\/span>disappointed customers and\u00a0<\/span>non-scalable solutions<\/span>. There are plenty of cases where once-dominant\u00a0<\/span>organizations<\/span>\u00a0in this situation, including the\u00a0<\/span>Unites States Postal Service<\/span>,\u00a0<\/span>have\u00a0<\/span>had to watch competitors charge past them<\/span>.\u00a0<\/span>According to an\u00a0<\/span>Accenture study<\/span><\/a>, 80 perce<\/span>nt of federal IT managers said technical debt was limiting their ability to\u00a0<\/span>improve<\/span>\u00a0<\/span>legacy systems and\/or move to the cloud.<\/span>\u00a0For the USPS,\u00a0<\/span>it has all resulted<\/span>\u00a0<\/span>in<\/span>\u00a0FedEx, UP<\/span>S, and\u00a0<\/span>most recently Amazon<\/span><\/a>\u00a0driv<\/span>ing<\/span>\u00a0innovation and\u00a0<\/span>winning customers in the space.\u00a0<\/span>\u00a0<\/span><\/p>\n

If your team c<\/span>ontinues to acquire technical deb<\/span>t<\/span>\u00a0without\u00a0<\/span>hav<\/span>ing<\/span>\u00a0<\/span>a clear strategy<\/span>, at a certain point your velocity will just\u00a0<\/span>be\u00a0<\/span>spent\u00a0<\/span>paying interest on your debt. You<\/span>\u2019ll<\/span>\u00a0no longer have extra funds to give to delivering new features or innovat<\/span>ive<\/span>\u00a0solutions.<\/span>\u00a0In my next post, we\u2019ll dig even deeper into why\u00a0<\/span>technical debt is so bad for your company.\u00a0<\/span>In the meantime, use this as a primer on what technical debt really is, and\u00a0<\/span>reach out<\/span><\/a>\u00a0if you could use some help evolving\u00a0<\/span>your approach to\u00a0<\/span>paying it down.<\/span>\u00a0<\/span><\/p>\n","protected":false},"excerpt":{"rendered":"

In our series,\u00a0Drowning in Technical Debt, we\u2019re digging into\u00a0the\u00a0commonly used but\u00a0often misunderstood phrase \u201ctechnical debt\u201d,…<\/p>\n","protected":false},"author":63,"featured_media":11450,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"content-type":"","footnotes":""},"categories":[262],"tags":[],"class_list":["post-11240","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-azure-strategy-management","topics-blog"],"acf":[],"_links":{"self":[{"href":"https:\/\/3cloudsolutions.com\/wp-json\/wp\/v2\/posts\/11240","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/3cloudsolutions.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/3cloudsolutions.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/3cloudsolutions.com\/wp-json\/wp\/v2\/users\/63"}],"replies":[{"embeddable":true,"href":"https:\/\/3cloudsolutions.com\/wp-json\/wp\/v2\/comments?post=11240"}],"version-history":[{"count":0,"href":"https:\/\/3cloudsolutions.com\/wp-json\/wp\/v2\/posts\/11240\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/3cloudsolutions.com\/wp-json\/wp\/v2\/media\/11450"}],"wp:attachment":[{"href":"https:\/\/3cloudsolutions.com\/wp-json\/wp\/v2\/media?parent=11240"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/3cloudsolutions.com\/wp-json\/wp\/v2\/categories?post=11240"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/3cloudsolutions.com\/wp-json\/wp\/v2\/tags?post=11240"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}

When technical debt is accrued as part of learning exploration, the objective is to learn how\u00a0<\/span>not\u00a0<\/span><\/i>to deliver and forget. This happens when a team doesn\u2019t know enough to make a technically excellent decision, because they\u2019re creating something innovative and are working in a new space. Sometimes, a\u00a0<\/span>spike<\/span><\/a>\u00a0<\/span>turns into production code.\u00a0<\/span>\u00a0<\/span><\/p>\n