I can tell you how much I enjoy being a geek. I can tell you how fascinated I was with the punch-cards my dad showed me back in 1985. I can tell you how I got my first computer when I was seven. And I can tell you that I’ve loved programming since 1989. I can tell you a great many things about all that, but I’m not sure how interesting they’d be.

Instead, let me tell you about my quest for an answer of sorts. There’s been one issue about our industry that has continued to puzzle me over the years: why is it that no software project is ever as simple as it seems? Why is it that no project ever comes out on time and on budget? Why are there always bugs? Why doesn’t it ever quite do what was intended? And why is it always so hard to make changes to the software? No matter how clean the slate is when a project starts, why does it always become a big ball of mud?

Almost everyone acknowledges the problem, and they seem to accept the status quo. Most of our industry deals with it by adding buffers to schedules and budgets, and by accepting mediocre software. Isn’t there a better way?

This book is not the answer, not by a long shot. But it is part of my exploration of the way forward. It is my notion that better tools can help us create better software.