The old new thing

About the book

The Old New Thing grew out of Raymond Chen's long-running writing about the Windows development team, where he worked on compatibility. The book is about the gap between how software looks from outside and why it was built that way inside. Chen takes familiar annoyances, legacy behaviors and design choices and reconstructs the pressures that produced them: shipped applications that depended on undocumented behavior, hardware and memory limits of earlier eras, and the cost of breaking programs already in use.

The result is less a manual than a collection of explanations. Chen writes as an engineer accounting for decisions, often showing how a sensible fix in one place would break something elsewhere. Backward compatibility comes across as an active engineering burden, not a passive setting. Programs that seem badly designed may be responding to constraints that vanished from view but not from the installed base.

The book draws on Chen's familiarity with Microsoft's internal history, so it speaks with authority about Windows specifically. Read it as a case study in maintaining a large, widely used system rather than a general theory of software design.

How to read it

Approach the book as a set of connected essays. Each piece tends to start from a concrete behavior or complaint and work backward to a cause. Read for the reasoning pattern: what did the team know, what could they change, and what would break if they did. The anecdotes reward attention to detail more than speed.

The prose is plain and often dry, with technical references that assume some familiarity with Windows and programming. Readers without that background can still follow the logic but may skim specific API and version details. Keep the historical context in mind, since the book reflects the state of Windows and its ecosystem at the time it was written, and some specifics have aged.

Who it suits

This suits programmers who maintain code they did not write, especially those working with Windows or long-lived systems. It also helps anyone curious about why established software keeps strange behavior, and it gives product and support staff a vocabulary for compatibility costs. Readers who enjoy engineering history told through small decisions will find plenty here.

Reading considerations

The book is closely tied to Microsoft's platform and perspective, so its lessons transfer best as analogy rather than direct guidance for other systems. Some technical details reflect the mid-2000s Windows landscape and may not match current versions. Readers wanting a structured tutorial or a neutral survey of operating system design should look elsewhere.