Like quite a few people, to me the word "debt" doesn't naturally fit the problem of building code that will be harder to build on later.
For me, "technical debt" would be shipping a product that immediately starts consuming technical resources not associated with value production. Like a rickety distributed database that needs manual labor to fix regular corruptions.
That would seem analogous to debt. Not fully paying for what you have, resulting in continuous expense until the full payment is made.
Writing code without care for future work is a different problem. It is the "bad foundation" problem shared by design, engineering, construction, book stacking, ...
It has 1000 names: "Building on Sand", "Ticking Timebombs", "Bandaid Solutions", "Cutting Corners", "Short Term Fixes", "Playing Jenga", "Putting Lipstick on a Pig", "Haste Makes Waste", "Disaster Waiting to Happen", etc.
Living code is a foundation. Shoddy foundations are dangerous to build on & costly to fix. Don't build shoddy foundations.
No new terminology. You don't need a special strategy to explain this.
Tell your CEO they can get their enormous features yesterday, they just need to sign off on a "shoddy foundation" exception. Informally by email is fine. You are ready to unleashed the troops from responsibility for future mishaps! All you need is that little written record! Then presto. The coders are standing by, breathless, ready to party! (And preparing their resumes.)
___
I love the essay's point that each feature adds assumptions, and assumptions add complexity. The rub of remodeling.
For me, "technical debt" would be shipping a product that immediately starts consuming technical resources not associated with value production. Like a rickety distributed database that needs manual labor to fix regular corruptions.
That would seem analogous to debt. Not fully paying for what you have, resulting in continuous expense until the full payment is made.
Writing code without care for future work is a different problem. It is the "bad foundation" problem shared by design, engineering, construction, book stacking, ...
It has 1000 names: "Building on Sand", "Ticking Timebombs", "Bandaid Solutions", "Cutting Corners", "Short Term Fixes", "Playing Jenga", "Putting Lipstick on a Pig", "Haste Makes Waste", "Disaster Waiting to Happen", etc.
Living code is a foundation. Shoddy foundations are dangerous to build on & costly to fix. Don't build shoddy foundations.
No new terminology. You don't need a special strategy to explain this.
Tell your CEO they can get their enormous features yesterday, they just need to sign off on a "shoddy foundation" exception. Informally by email is fine. You are ready to unleashed the troops from responsibility for future mishaps! All you need is that little written record! Then presto. The coders are standing by, breathless, ready to party! (And preparing their resumes.)
___
I love the essay's point that each feature adds assumptions, and assumptions add complexity. The rub of remodeling.