{"id":11081,"date":"2017-12-25T19:38:08","date_gmt":"2017-12-26T03:38:08","guid":{"rendered":"https:\/\/www.seedcode.com\/?p=11081"},"modified":"2017-12-25T19:38:08","modified_gmt":"2017-12-26T03:38:08","slug":"works-recording-technical-debt","status":"publish","type":"post","link":"https:\/\/seedcode.com\/works-recording-technical-debt\/","title":{"rendered":"What Works – Recording Technical Debt"},"content":{"rendered":"

This is the fourth\u00a0post in a series<\/a> that formed the basis of my 2017 DevCon session on Increasing Code Quality While Staying Lean. Check out the first post for an introduction to the series<\/a>. These techniques have made a big impact at SeedCode and we hope you\u2019re inspired to incorporate some of these into your own work.<\/em><\/p>\n

We\u00a0Record our Debt<\/h2>\n

\"Recording<\/a>In Documenting our Decisions<\/a>, we talked about \u201ccreating a path<\/em> from the customer\u2019s cases (or feature specs) to the code that addresses them\u2014a path that our future selves can follow.\u201d<\/p>\n

Similarly, when we take shortcuts, we record the path not taken<\/strong> as a new case. Technical debt<\/a> taken on intentionally can help us get there faster, just like debt financing can help a company grow faster. Debt taken on invisibly is like a variable rate loan\u2014not good\u2014and in both cases it\u2019s the unknown that makes all the difference.<\/p>\n

What We Do<\/h2>\n
    \n
  • We know there is a better way to do something but we\u2019ll defer hardening until our work is validated by the customer. Instead of premature optimization we create a case for the optimized approach and ship what we\u2019ve got.<\/li>\n<\/ul>\n
      \n
    • We can\u2019t finish a feature, or can\u2019t get to the edge cases, so we create a case for what\u2019s undone. Sometimes the isn\u2019t debt, but just \u201cFriday\u201d\u2014I find myself making cases at the end of the week or end of the day for what I wanted to get done but couldn\u2019t. Come Monday, it takes less time to get back to work<\/em> because I know just where to pick up. This is a version of Hemingway\u2019s dictum to always stop when you know exactly what you\u2019re going to do next.<\/li>\n<\/ul>\n
        \n
      • When we\u2019re doing QA videos we create cases for any<\/strong> bugs we see that aren\u2019t going to be fixed IN the video. By creating a case for anything weird we see, we can deflect the hard work of deciding when to fix it, or who\u2019s going to fix it, or even to fix it at all. Without having to worry about that we can pay attention the nuances of the bug, and tag the case with any customers who\u2019ve been affected.<\/li>\n<\/ul>\n

        Why This Works<\/h2>\n

        Recording instead of coding<\/em> lets us observe our work without the pressure to fix it. I’m just capturing the bug, not also trying to determine how big a change it’s going to be. This means we see more–and see more consequences–than if we were just looking for how to fix something.<\/p>\n

        [bctt tweet=”Recording instead of coding lets us observe our work without the pressure to fix it.” username=”seedcode”]<\/p>\n

        This also works hand-in-hand with delivering small chunks. Think of a feature as hub with several spokes. The hub might be creating a new contact. The spokes might be checking to see if the contact already exists and then merging the new contact with that existing record. Would an existing contact count if they were archived? What constitutes a “duplicate” contact, is it an exact name match or a close name match at the same domain? And who is allowed to create new contact anyway? Who is allowed to merge?<\/p>\n

        It’s much easier for me to create cases for these “spokes” (to treat them as debt) than to account for them in my code. If my code is the only place to capture these spokes then I’ll capure very few of them. Further, the deferring part of technical debt means I embargo the spoke cases until the hub has been validated by our customer: and that’s key. Because if we get something wrong about the hub, I’d rather just rework the hub than rework the hub and all it’s spokes<\/strong>.<\/p>\n

        Recent Ideas<\/h2>\n

        Defering the spokes until the hub is validated is proving to be key. It mean we’re less resistant to chages suggested by the customer and, importantly, less resistant when the customer wants to pivot to a new problem: we’ve already got the landscape of this<\/em> problem documented.<\/p>\n","protected":false},"excerpt":{"rendered":"

        This is the fourth\u00a0post in a series that formed the basis of my 2017 DevCon session on Increasing Code Quality While Staying Lean. Check out the first post for an introduction to the series. These techniques have made a big impact at SeedCode and we hope you\u2019re inspired to incorporate some of these into your own work. We\u00a0Record our Debt In Documenting our Decisions, we talked about \u201ccreating a path from the customer\u2019s cases (or feature specs) to the code that addresses them\u2014a path that our future selves can follow.\u201d Similarly, when we take shortcuts, we record the path not taken as a new case. Technical debt taken on intentionally can help us get there faster, just like debt financing can help a company grow faster. Debt taken on invisibly is like a variable rate loan\u2014not good\u2014and in both cases it\u2019s the unknown that makes all the difference. What We Do We know there is a better way to do something but we\u2019ll defer hardening until our work is validated by the customer. Instead of premature optimization we create a case for the optimized approach and ship what we\u2019ve got. We can\u2019t finish a feature, or can\u2019t get to the edge cases, so we create a case for what\u2019s undone. Sometimes the isn\u2019t debt, but just \u201cFriday\u201d\u2014I find myself making cases at the end of the week or end of the day for what I wanted to get done but couldn\u2019t. Come Monday, it takes less time to get back to work because I know just where to pick up. This is a version of Hemingway\u2019s dictum to always stop when you know exactly what you\u2019re going to do next. When we\u2019re doing QA videos we create cases for any bugs we see that aren\u2019t going to be fixed IN the video. By creating a case for anything weird we see, we can deflect the hard work of deciding when to fix it, or who\u2019s going to fix it, or even to fix it at all. Without having to worry about that we can pay attention the nuances of the bug, and tag the case with any customers who\u2019ve been affected. Why This Works Recording instead of coding lets us observe our work without the pressure to fix it. I’m just capturing the bug, not also trying to determine how big a change it’s going to be. This means we see more–and see more consequences–than if we were just looking for how to fix something. [bctt tweet=”Recording instead of coding lets us observe our work without the pressure to fix it.” username=”seedcode”] This also works hand-in-hand with delivering small chunks. Think of a feature as hub with several spokes. The hub might be creating a new contact. The spokes might be checking to see if the contact already exists and then merging the new contact with that existing record. Would an existing contact count if they were archived? What constitutes a “duplicate” contact, is it an exact name match or a close name match at the same domain? And who is allowed to create new contact anyway? Who is allowed to merge? It’s much easier for me to create cases for these “spokes” (to treat them as debt) than to account for them in my code. If my code is the only place to capture these spokes then I’ll capure very few of them. Further, the deferring part of technical debt means I embargo the spoke cases until the hub has been validated by our customer: and that’s key. Because if we get something wrong about the hub, I’d rather just rework the hub than rework the hub and all it’s spokes. Recent Ideas Defering the spokes until the hub is validated is proving to be key. It mean we’re less resistant to chages suggested by the customer and, importantly, less resistant when the customer wants to pivot to a new problem: we’ve already got the landscape of this problem documented.<\/p>\n","protected":false},"author":1,"featured_media":11088,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[34],"class_list":["post-11081","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorized","tag-what-works"],"yoast_head":"\nWhat Works - Recording Technical Debt - SeedCode<\/title>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/seedcode.com\/works-recording-technical-debt\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"What Works - Recording Technical Debt - SeedCode\" \/>\n<meta property=\"og:description\" content=\"This is the fourth\u00a0post in a series that formed the basis of my 2017 DevCon session on Increasing Code Quality While Staying Lean. Check out the first post for an introduction to the series. These techniques have made a big impact at SeedCode and we hope you\u2019re inspired to incorporate some of these into your own work. We\u00a0Record our Debt In Documenting our Decisions, we talked about \u201ccreating a path from the customer\u2019s cases (or feature specs) to the code that addresses them\u2014a path that our future selves can follow.\u201d Similarly, when we take shortcuts, we record the path not taken as a new case. Technical debt taken on intentionally can help us get there faster, just like debt financing can help a company grow faster. Debt taken on invisibly is like a variable rate loan\u2014not good\u2014and in both cases it\u2019s the unknown that makes all the difference. What We Do We know there is a better way to do something but we\u2019ll defer hardening until our work is validated by the customer. Instead of premature optimization we create a case for the optimized approach and ship what we\u2019ve got. We can\u2019t finish a feature, or can\u2019t get to the edge cases, so we create a case for what\u2019s undone. Sometimes the isn\u2019t debt, but just \u201cFriday\u201d\u2014I find myself making cases at the end of the week or end of the day for what I wanted to get done but couldn\u2019t. Come Monday, it takes less time to get back to work because I know just where to pick up. This is a version of Hemingway\u2019s dictum to always stop when you know exactly what you\u2019re going to do next. When we\u2019re doing QA videos we create cases for any bugs we see that aren\u2019t going to be fixed IN the video. By creating a case for anything weird we see, we can deflect the hard work of deciding when to fix it, or who\u2019s going to fix it, or even to fix it at all. Without having to worry about that we can pay attention the nuances of the bug, and tag the case with any customers who\u2019ve been affected. Why This Works Recording instead of coding lets us observe our work without the pressure to fix it. I’m just capturing the bug, not also trying to determine how big a change it’s going to be. This means we see more–and see more consequences–than if we were just looking for how to fix something. [bctt tweet=”Recording instead of coding lets us observe our work without the pressure to fix it.” username=”seedcode”] This also works hand-in-hand with delivering small chunks. Think of a feature as hub with several spokes. The hub might be creating a new contact. The spokes might be checking to see if the contact already exists and then merging the new contact with that existing record. Would an existing contact count if they were archived? What constitutes a “duplicate” contact, is it an exact name match or a close name match at the same domain? And who is allowed to create new contact anyway? Who is allowed to merge? It’s much easier for me to create cases for these “spokes” (to treat them as debt) than to account for them in my code. If my code is the only place to capture these spokes then I’ll capure very few of them. Further, the deferring part of technical debt means I embargo the spoke cases until the hub has been validated by our customer: and that’s key. Because if we get something wrong about the hub, I’d rather just rework the hub than rework the hub and all it’s spokes. Recent Ideas Defering the spokes until the hub is validated is proving to be key. It mean we’re less resistant to chages suggested by the customer and, importantly, less resistant when the customer wants to pivot to a new problem: we’ve already got the landscape of this problem documented.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/seedcode.com\/works-recording-technical-debt\/\" \/>\n<meta property=\"og:site_name\" content=\"SeedCode\" \/>\n<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/seedcoder\" \/>\n<meta property=\"article:published_time\" content=\"2017-12-26T03:38:08+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/seedcode.com\/wp-content\/uploads\/2017\/12\/CreditCard.png\" \/>\n\t<meta property=\"og:image:width\" content=\"319\" \/>\n\t<meta property=\"og:image:height\" content=\"325\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/png\" \/>\n<meta name=\"author\" content=\"seedcode\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:creator\" content=\"@dayback\" \/>\n<meta name=\"twitter:site\" content=\"@dayback\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"seedcode\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"3 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\/\/seedcode.com\/works-recording-technical-debt\/#article\",\"isPartOf\":{\"@id\":\"https:\/\/seedcode.com\/works-recording-technical-debt\/\"},\"author\":{\"name\":\"seedcode\",\"@id\":\"https:\/\/seedcode.com\/#\/schema\/person\/af42f3f8cbfc8652fb0ffbb3f46f260f\"},\"headline\":\"What Works – Recording Technical Debt\",\"datePublished\":\"2017-12-26T03:38:08+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\/\/seedcode.com\/works-recording-technical-debt\/\"},\"wordCount\":699,\"commentCount\":0,\"publisher\":{\"@id\":\"https:\/\/seedcode.com\/#organization\"},\"image\":{\"@id\":\"https:\/\/seedcode.com\/works-recording-technical-debt\/#primaryimage\"},\"thumbnailUrl\":\"https:\/\/seedcode.com\/wp-content\/uploads\/2017\/12\/CreditCard.png\",\"keywords\":[\"What Works\"],\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\/\/seedcode.com\/works-recording-technical-debt\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\/\/seedcode.com\/works-recording-technical-debt\/\",\"url\":\"https:\/\/seedcode.com\/works-recording-technical-debt\/\",\"name\":\"What Works - Recording Technical Debt - SeedCode\",\"isPartOf\":{\"@id\":\"https:\/\/seedcode.com\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\/\/seedcode.com\/works-recording-technical-debt\/#primaryimage\"},\"image\":{\"@id\":\"https:\/\/seedcode.com\/works-recording-technical-debt\/#primaryimage\"},\"thumbnailUrl\":\"https:\/\/seedcode.com\/wp-content\/uploads\/2017\/12\/CreditCard.png\",\"datePublished\":\"2017-12-26T03:38:08+00:00\",\"breadcrumb\":{\"@id\":\"https:\/\/seedcode.com\/works-recording-technical-debt\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/seedcode.com\/works-recording-technical-debt\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/seedcode.com\/works-recording-technical-debt\/#primaryimage\",\"url\":\"https:\/\/seedcode.com\/wp-content\/uploads\/2017\/12\/CreditCard.png\",\"contentUrl\":\"https:\/\/seedcode.com\/wp-content\/uploads\/2017\/12\/CreditCard.png\",\"width\":319,\"height\":325},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/seedcode.com\/works-recording-technical-debt\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\/\/seedcode.com\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"What Works – Recording Technical Debt\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\/\/seedcode.com\/#website\",\"url\":\"https:\/\/seedcode.com\/\",\"name\":\"SeedCode\",\"description\":\"Build the Software You've Always Wanted\",\"publisher\":{\"@id\":\"https:\/\/seedcode.com\/#organization\"},\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\/\/seedcode.com\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-US\"},{\"@type\":\"Organization\",\"@id\":\"https:\/\/seedcode.com\/#organization\",\"name\":\"SeedCode\",\"url\":\"https:\/\/seedcode.com\/\",\"logo\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/seedcode.com\/#\/schema\/logo\/image\/\",\"url\":\"https:\/\/seedcode.com\/wp-content\/uploads\/2022\/12\/SeedCodeLogo.png\",\"contentUrl\":\"https:\/\/seedcode.com\/wp-content\/uploads\/2022\/12\/SeedCodeLogo.png\",\"width\":595,\"height\":189,\"caption\":\"SeedCode\"},\"image\":{\"@id\":\"https:\/\/seedcode.com\/#\/schema\/logo\/image\/\"},\"sameAs\":[\"https:\/\/www.facebook.com\/seedcoder\",\"https:\/\/x.com\/dayback\",\"https:\/\/www.linkedin.com\/company\/seedcode\/\"]},{\"@type\":\"Person\",\"@id\":\"https:\/\/seedcode.com\/#\/schema\/person\/af42f3f8cbfc8652fb0ffbb3f46f260f\",\"name\":\"seedcode\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/seedcode.com\/#\/schema\/person\/image\/\",\"url\":\"https:\/\/secure.gravatar.com\/avatar\/f0c386c5b845ee7fe111b36b2d87e983811f1f549682de9597a934b9dfd45469?s=96&d=mm&r=g\",\"contentUrl\":\"https:\/\/secure.gravatar.com\/avatar\/f0c386c5b845ee7fe111b36b2d87e983811f1f549682de9597a934b9dfd45469?s=96&d=mm&r=g\",\"caption\":\"seedcode\"},\"sameAs\":[\"https:\/\/seedcode.com\"],\"url\":\"https:\/\/seedcode.com\/author\/seedcode\/\"}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"What Works - Recording Technical Debt - SeedCode","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/seedcode.com\/works-recording-technical-debt\/","og_locale":"en_US","og_type":"article","og_title":"What Works - Recording Technical Debt - SeedCode","og_description":"This is the fourth\u00a0post in a series that formed the basis of my 2017 DevCon session on Increasing Code Quality While Staying Lean. Check out the first post for an introduction to the series. These techniques have made a big impact at SeedCode and we hope you\u2019re inspired to incorporate some of these into your own work. We\u00a0Record our Debt In Documenting our Decisions, we talked about \u201ccreating a path from the customer\u2019s cases (or feature specs) to the code that addresses them\u2014a path that our future selves can follow.\u201d Similarly, when we take shortcuts, we record the path not taken as a new case. Technical debt taken on intentionally can help us get there faster, just like debt financing can help a company grow faster. Debt taken on invisibly is like a variable rate loan\u2014not good\u2014and in both cases it\u2019s the unknown that makes all the difference. What We Do We know there is a better way to do something but we\u2019ll defer hardening until our work is validated by the customer. Instead of premature optimization we create a case for the optimized approach and ship what we\u2019ve got. We can\u2019t finish a feature, or can\u2019t get to the edge cases, so we create a case for what\u2019s undone. Sometimes the isn\u2019t debt, but just \u201cFriday\u201d\u2014I find myself making cases at the end of the week or end of the day for what I wanted to get done but couldn\u2019t. Come Monday, it takes less time to get back to work because I know just where to pick up. This is a version of Hemingway\u2019s dictum to always stop when you know exactly what you\u2019re going to do next. When we\u2019re doing QA videos we create cases for any bugs we see that aren\u2019t going to be fixed IN the video. By creating a case for anything weird we see, we can deflect the hard work of deciding when to fix it, or who\u2019s going to fix it, or even to fix it at all. Without having to worry about that we can pay attention the nuances of the bug, and tag the case with any customers who\u2019ve been affected. Why This Works Recording instead of coding lets us observe our work without the pressure to fix it. I’m just capturing the bug, not also trying to determine how big a change it’s going to be. This means we see more–and see more consequences–than if we were just looking for how to fix something. [bctt tweet=”Recording instead of coding lets us observe our work without the pressure to fix it.” username=”seedcode”] This also works hand-in-hand with delivering small chunks. Think of a feature as hub with several spokes. The hub might be creating a new contact. The spokes might be checking to see if the contact already exists and then merging the new contact with that existing record. Would an existing contact count if they were archived? What constitutes a “duplicate” contact, is it an exact name match or a close name match at the same domain? And who is allowed to create new contact anyway? Who is allowed to merge? It’s much easier for me to create cases for these “spokes” (to treat them as debt) than to account for them in my code. If my code is the only place to capture these spokes then I’ll capure very few of them. Further, the deferring part of technical debt means I embargo the spoke cases until the hub has been validated by our customer: and that’s key. Because if we get something wrong about the hub, I’d rather just rework the hub than rework the hub and all it’s spokes. Recent Ideas Defering the spokes until the hub is validated is proving to be key. It mean we’re less resistant to chages suggested by the customer and, importantly, less resistant when the customer wants to pivot to a new problem: we’ve already got the landscape of this problem documented.","og_url":"https:\/\/seedcode.com\/works-recording-technical-debt\/","og_site_name":"SeedCode","article_publisher":"https:\/\/www.facebook.com\/seedcoder","article_published_time":"2017-12-26T03:38:08+00:00","og_image":[{"width":319,"height":325,"url":"https:\/\/seedcode.com\/wp-content\/uploads\/2017\/12\/CreditCard.png","type":"image\/png"}],"author":"seedcode","twitter_card":"summary_large_image","twitter_creator":"@dayback","twitter_site":"@dayback","twitter_misc":{"Written by":"seedcode","Est. reading time":"3 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/seedcode.com\/works-recording-technical-debt\/#article","isPartOf":{"@id":"https:\/\/seedcode.com\/works-recording-technical-debt\/"},"author":{"name":"seedcode","@id":"https:\/\/seedcode.com\/#\/schema\/person\/af42f3f8cbfc8652fb0ffbb3f46f260f"},"headline":"What Works – Recording Technical Debt","datePublished":"2017-12-26T03:38:08+00:00","mainEntityOfPage":{"@id":"https:\/\/seedcode.com\/works-recording-technical-debt\/"},"wordCount":699,"commentCount":0,"publisher":{"@id":"https:\/\/seedcode.com\/#organization"},"image":{"@id":"https:\/\/seedcode.com\/works-recording-technical-debt\/#primaryimage"},"thumbnailUrl":"https:\/\/seedcode.com\/wp-content\/uploads\/2017\/12\/CreditCard.png","keywords":["What Works"],"inLanguage":"en-US","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/seedcode.com\/works-recording-technical-debt\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/seedcode.com\/works-recording-technical-debt\/","url":"https:\/\/seedcode.com\/works-recording-technical-debt\/","name":"What Works - Recording Technical Debt - SeedCode","isPartOf":{"@id":"https:\/\/seedcode.com\/#website"},"primaryImageOfPage":{"@id":"https:\/\/seedcode.com\/works-recording-technical-debt\/#primaryimage"},"image":{"@id":"https:\/\/seedcode.com\/works-recording-technical-debt\/#primaryimage"},"thumbnailUrl":"https:\/\/seedcode.com\/wp-content\/uploads\/2017\/12\/CreditCard.png","datePublished":"2017-12-26T03:38:08+00:00","breadcrumb":{"@id":"https:\/\/seedcode.com\/works-recording-technical-debt\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/seedcode.com\/works-recording-technical-debt\/"]}]},{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/seedcode.com\/works-recording-technical-debt\/#primaryimage","url":"https:\/\/seedcode.com\/wp-content\/uploads\/2017\/12\/CreditCard.png","contentUrl":"https:\/\/seedcode.com\/wp-content\/uploads\/2017\/12\/CreditCard.png","width":319,"height":325},{"@type":"BreadcrumbList","@id":"https:\/\/seedcode.com\/works-recording-technical-debt\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/seedcode.com\/"},{"@type":"ListItem","position":2,"name":"What Works – Recording Technical Debt"}]},{"@type":"WebSite","@id":"https:\/\/seedcode.com\/#website","url":"https:\/\/seedcode.com\/","name":"SeedCode","description":"Build the Software You've Always Wanted","publisher":{"@id":"https:\/\/seedcode.com\/#organization"},"potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/seedcode.com\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":"Organization","@id":"https:\/\/seedcode.com\/#organization","name":"SeedCode","url":"https:\/\/seedcode.com\/","logo":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/seedcode.com\/#\/schema\/logo\/image\/","url":"https:\/\/seedcode.com\/wp-content\/uploads\/2022\/12\/SeedCodeLogo.png","contentUrl":"https:\/\/seedcode.com\/wp-content\/uploads\/2022\/12\/SeedCodeLogo.png","width":595,"height":189,"caption":"SeedCode"},"image":{"@id":"https:\/\/seedcode.com\/#\/schema\/logo\/image\/"},"sameAs":["https:\/\/www.facebook.com\/seedcoder","https:\/\/x.com\/dayback","https:\/\/www.linkedin.com\/company\/seedcode\/"]},{"@type":"Person","@id":"https:\/\/seedcode.com\/#\/schema\/person\/af42f3f8cbfc8652fb0ffbb3f46f260f","name":"seedcode","image":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/seedcode.com\/#\/schema\/person\/image\/","url":"https:\/\/secure.gravatar.com\/avatar\/f0c386c5b845ee7fe111b36b2d87e983811f1f549682de9597a934b9dfd45469?s=96&d=mm&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/f0c386c5b845ee7fe111b36b2d87e983811f1f549682de9597a934b9dfd45469?s=96&d=mm&r=g","caption":"seedcode"},"sameAs":["https:\/\/seedcode.com"],"url":"https:\/\/seedcode.com\/author\/seedcode\/"}]}},"_links":{"self":[{"href":"https:\/\/seedcode.com\/wp-json\/wp\/v2\/posts\/11081","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/seedcode.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/seedcode.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/seedcode.com\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/seedcode.com\/wp-json\/wp\/v2\/comments?post=11081"}],"version-history":[{"count":0,"href":"https:\/\/seedcode.com\/wp-json\/wp\/v2\/posts\/11081\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/seedcode.com\/wp-json\/wp\/v2\/media\/11088"}],"wp:attachment":[{"href":"https:\/\/seedcode.com\/wp-json\/wp\/v2\/media?parent=11081"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/seedcode.com\/wp-json\/wp\/v2\/categories?post=11081"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/seedcode.com\/wp-json\/wp\/v2\/tags?post=11081"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}