Question 1

What is technical debt and when is it worth taking on?

Accepted Answer

**Technical debt** is the accumulated cost of choosing an expedient implementation over a better one. The metaphor, coined by Ward Cunningham, is precise and worth taking seriously: you borrow time now and pay **interest** in the form of slower future work, until you repay the **principal** by refactoring.

**The interest is the important part.** Debt is not simply "bad code". It is code whose shortcomings impose an ongoing tax on every subsequent change — more time to understand, more places to update, more bugs, more testing. Code that is ugly but never touched again costs nothing.

**Cunningham's original meaning** was narrower than common usage. He described shipping to learn, with the explicit intent of revising once you understood the problem better. Deliberately incurring debt to gain knowledge is a strategy; accidentally incurring it through carelessness is not the same thing, though both are now called technical debt.

**A useful classification** distinguishes **deliberate versus inadvertent** and **prudent versus reckless**:

**Deliberate and prudent** — "we ship now and deal with the abstraction after launch." This is legitimate and often correct.

**Deliberate and reckless** — "we don't have time for design."

**Inadvertent and prudent** — "now we know how we should have built it." This is unavoidable and arguably the most common kind.

**Inadvertent and reckless** — the team did not know better.

**When taking it on is right:** validating an unproven idea, a genuine deadline with real consequences, code in a part of the system unlikely to change, or where you do not yet understand the domain well enough to design properly. Building the wrong abstraction early is more expensive than building none.

**When it is not:** in core abstractions everything depends on, in security and data integrity, and when you have no intention of repaying it.

**Track it explicitly** — untracked debt compounds silently until velocity collapses.

Question 2

What is test-driven development, and does the evidence support it?

Accepted Answer

A practice of writing a failing test before the code that satisfies it, in a short cycle — red, green, refactor. The evidence for its claimed benefits is mixed and weaker than advocates suggest,

Question 3

What is refactoring, and how is it different from rewriting?

Accepted Answer

Refactoring is changing the internal structure of code without changing its external behaviour. That definition, from Martin Fowler, is precise and the constraint is what makes it refactoring rather

Question 4

What is a code review actually for?

Accepted Answer

Not primarily for catching bugs — which is the assumption most reviewers bring and the reason so many reviews are unsatisfying for everyone involved. What the evidence and practice suggest reviews

Question 5

Why are null references called a billion-dollar mistake?

Accepted Answer

Because Tony Hoare, who introduced the null reference into ALGOL W in 1965, later described it exactly that way — apologising publicly for a design decision that has produced an enormous quantity of

Question 6

Why is software estimation so unreliable?

Accepted Answer

Because estimating software means estimating work that has never been done before — if it had, you would copy it — and human judgement about novel work is systematically biased in a direction that is

Question 7

Why does documentation always go out of date?

Accepted Answer

Because documentation and the code it describes are coupled in meaning but decoupled in enforcement — nothing breaks when they diverge, so they diverge. The core mechanism. Code has a merciless

Related Questions