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.