uuid:
  - value: fa7b57ee-9af5-49ce-9522-66d54642e219
langcode:
  - value: en
type:
  - target_id: daily_email
    target_type: node_type
    target_uuid: 8bde1f2f-eef9-4f2d-ae9c-96921f8193d7
revision_timestamp:
  - value: '2025-05-11T09:00:06+00:00'
revision_uid:
  - target_type: user
    target_uuid: b8966985-d4b2-42a7-a319-2e94ccfbb849
revision_log: {  }
status:
  - value: true
uid:
  - target_type: user
    target_uuid: b8966985-d4b2-42a7-a319-2e94ccfbb849
title:
  - value: "Technical debt isn't always bad"
created:
  - value: '2024-10-02T00:00:00+00:00'
changed:
  - value: '2025-05-11T09:00:06+00:00'
promote:
  - value: false
sticky:
  - value: false
default_langcode:
  - value: true
revision_translation_affected:
  - value: true
path:
  - alias: /daily/2024/10/02/technical-debt-isn-t-always-bad
    langcode: en
body:
  - value: |
      <p><a href="/daily/2024/10/01/not-all-legacy-code-is-technical-debt">Technical debt is usually referred to negatively</a>, but technical debt isn't always bad.</p>

      <p>The key thing is to know when and why you're taking on technical debt and when it will be addressed.</p>

      <p>If you have a goal or deadline to meet, you may decide to take on technical debt to release a feature sooner or a simpler version is released now and a more complex version will come later.</p>

      <p>I've done this on multi-site Drupal projects before, where I've hard-coded a background image URL as part of a minimum-viable version and made it changeable only when it needed to be - i.e. when the second website was introduced.</p>

      <p>For the initial version, that approach was good enough and meant we could move forward.</p>

      <p>The client and I decided to take on this technical debit in advance so we could release it sooner, and we knew when and how we were going to address it and pay it back.</p>

      <p>This was a good situation, not a bad one.</p>

              
    format: full_html
    processed: |
      <p><a href="/daily/2024/10/01/not-all-legacy-code-is-technical-debt">Technical debt is usually referred to negatively</a>, but technical debt isn't always bad.</p>

      <p>The key thing is to know when and why you're taking on technical debt and when it will be addressed.</p>

      <p>If you have a goal or deadline to meet, you may decide to take on technical debt to release a feature sooner or a simpler version is released now and a more complex version will come later.</p>

      <p>I've done this on multi-site Drupal projects before, where I've hard-coded a background image URL as part of a minimum-viable version and made it changeable only when it needed to be - i.e. when the second website was introduced.</p>

      <p>For the initial version, that approach was good enough and meant we could move forward.</p>

      <p>The client and I decided to take on this technical debit in advance so we could release it sooner, and we knew when and how we were going to address it and pay it back.</p>

      <p>This was a good situation, not a bad one.</p>

              
    summary: null
field_daily_email_cta: {  }