#Technical-Debt
13 notas · última:
How to Make Technical Debt Your Friend
The article argues that technical debt can be a useful trade-off for MVPs and Minimum Viable Architecture, because it lowers the cost of learning and helps teams avoid overinvesting before the product’s value is proven.
Opportunistic Refactoring
Refactoring should happen continuously and opportunistically, whenever code needs cleanup, while tests are green. Small changes done now keep the codebase healthier and reduce slower progress later.
I hate "Quick Wins"
The text argues that quick wins tend to generate technical debt, misalignment of goals, a worse user experience, and compromised architecture, and it defends a long-term vision and incremental delivery.
Architecture Is a Game of Constraint Satisfaction
Gregor Hohpe argues architects keep designing around constraints (procurement lead times, hardware size, coupling costs) long after the constraint that justified them has quietly disappeared.
We Need to Talk About Technical Debt
Argues technical debt and bad code are not the same thing: debt is a deliberate, repayable trade-off, bad code is a skills gap. Unpaid debt compounds into a rewrite.
Estimates – a necessary evil? - Erik Thorsell
The post argues that estimates help product owners balance priorities, release dates, and technical debt, but become harmful when treated as deadlines. Continuous updates are presented as the better practice.
Knowledge creates technical debt
Technical debt can arise when new knowledge makes an older code path look inferior. The post frames fixing it as using that knowledge well, not just paying off a liability.
Wiping the tech debt out with immutable code
The post argues that technical debt keeps growing and proposes immutable code as a way to reset it by rewriting isolated components instead of incrementally patching them.
Managing your Software Debt
The page groups software debt into technical, competence, and quality debt, and says maintenance costs, developer morale, and defect fixing get worse as debt grows. It points to pairing, refactoring, and agile practices as ways to reduce it.
Yagni
Yagni says not to build a capability now if you will not need it yet. Fowler frames it as a simple-design practice, weighing build cost, delay, carry, and repair costs against future uncertainty.
Three Reasons Why Your Software Is So Far Behind Schedule
The article says delayed software projects often share three signs of technical debt: new developers take too long to onboard, test suites grow unwieldy or break down, and teams keep running their own servers instead of moving to the cloud.
Technical debt 101
The article argues that technical debt is a conscious design trade-off, not simply bad code, and that neglecting quality creates long-term costs, legacy code, and cultural damage.
Effective Steps to reduce technical debt: An agile approach
The post outlines a pragmatic agile way to reduce technical debt: involve the product owner, map known issues, estimate them relatively, and fold repayment into daily development.