From 7d92d739fcfe534e10ab5a6cad1d79023c645e3f Mon Sep 17 00:00:00 2001 From: sing1179 <143670921+sing1179@users.noreply.github.com> Date: Wed, 16 Sep 2026 20:54:51 -0400 Subject: [PATCH 1/3] Add reflection on Martin Fowler's technical debt article --- README.md | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index 1621800..ab6d42e 100644 --- a/README.md +++ b/README.md @@ -1,2 +1,9 @@ -# Git Practice -A simple project to practice a few git/github workflows. Replace the contents of this file with the contents indicated in the [instructions](./instructions.md). \ No newline at end of file +# Technical Debt and the Cost of Changing Software + +**Article:** [Technical Debt](https://martinfowler.com/bliki/TechnicalDebt.html) by Martin Fowler + +## What I Find Interesting + +What I find interesting about this article is that code quality affects how quickly a team can deliver future changes, even when the software already works. Fowler describes the extra effort caused by confusing code as interest on technical debt. That makes the tradeoff between shipping a feature and cleaning up its implementation easier to understand. A shortcut might save time today, but if every later change requires working around it, the team keeps paying for that decision. I think this is a useful way to discuss maintainability because it connects code structure to the actual work needed to develop a project. + +I also like the idea of improving code gradually in the areas that change most often. An awkward module that rarely changes may be less urgent than one that slows down every new feature. For a team project, this suggests making small, focused improvements as part of regular development instead of waiting for a complete rewrite. I would want those improvements to be easy for teammates to review, with clear commits and pull requests explaining why the changes help. From d9b82777280da4b9bbf831e345f0b4ce7084e5a4 Mon Sep 17 00:00:00 2001 From: krishivseth Date: Wed, 16 Sep 2026 22:25:30 -0400 Subject: [PATCH 2/3] Add comment from Krishiv Seth on technical debt article --- README.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/README.md b/README.md index ab6d42e..7e6e057 100644 --- a/README.md +++ b/README.md @@ -7,3 +7,7 @@ What I find interesting about this article is that code quality affects how quickly a team can deliver future changes, even when the software already works. Fowler describes the extra effort caused by confusing code as interest on technical debt. That makes the tradeoff between shipping a feature and cleaning up its implementation easier to understand. A shortcut might save time today, but if every later change requires working around it, the team keeps paying for that decision. I think this is a useful way to discuss maintainability because it connects code structure to the actual work needed to develop a project. I also like the idea of improving code gradually in the areas that change most often. An awkward module that rarely changes may be less urgent than one that slows down every new feature. For a team project, this suggests making small, focused improvements as part of regular development instead of waiting for a complete rewrite. I would want those improvements to be easy for teammates to review, with clear commits and pull requests explaining why the changes help. + +## Comment from Krishiv Seth + +I think the interest metaphor is the strongest part of Fowler's article, and it pairs well with his point that not all debt is equal. Debt on a module that changes every week compounds quickly, while debt on a stable module barely costs anything, so paying it down is only worth it where the payments are actually high. That framing also gives teams a practical answer to the question "should we refactor this?" Rather than treating cleanliness as a goal on its own, you can ask whether the mess is slowing down the work you are about to do. In a team project I would want that decision to show up in the pull request itself, with a short note about which upcoming change the cleanup makes easier. From 79a8d29b2dcf2578f689a603f560c8fa0c5e159c Mon Sep 17 00:00:00 2001 From: krishivseth Date: Wed, 16 Sep 2026 22:28:32 -0400 Subject: [PATCH 3/3] Reword comment from Krishiv Seth --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 7e6e057..1f0c51b 100644 --- a/README.md +++ b/README.md @@ -10,4 +10,4 @@ I also like the idea of improving code gradually in the areas that change most o ## Comment from Krishiv Seth -I think the interest metaphor is the strongest part of Fowler's article, and it pairs well with his point that not all debt is equal. Debt on a module that changes every week compounds quickly, while debt on a stable module barely costs anything, so paying it down is only worth it where the payments are actually high. That framing also gives teams a practical answer to the question "should we refactor this?" Rather than treating cleanliness as a goal on its own, you can ask whether the mess is slowing down the work you are about to do. In a team project I would want that decision to show up in the pull request itself, with a short note about which upcoming change the cleanup makes easier. +The interest metaphor is the part of Fowler's article I keep coming back to. Debt on a file that changes every week costs a lot. Debt on a file nobody has opened since 2019 costs close to nothing, so cleaning that file up is wasted work even though the code is ugly. That gives a team a real answer to the question "should we refactor this?" Ask whether the mess slows down the change you are about to make this sprint. If the answer is no, leave the mess alone. In a team project I would put that reasoning in the pull request itself, with one line naming which upcoming feature the cleanup makes easier.