“...then it began...”
In his introduction to this book, Michael Feathers uses that phrase to describe the start of his passion for software.
“...then it began...”
Do you know that feeling? Can you point to a single moment in your life and say: “...then it began...”? Was there a single event that changed the course of your life and eventually led you to pick up this book and start reading this foreword?
I was in sixth grade when it happened to me. I was interested in science and space and all things technical. My mother found a plastic computer in a catalog and ordered it for me. It was called Digi-Comp I. Forty years later that little plastic computer holds a place of honor on my bookshelf. It was the catalyst that sparked my enduring passion for software. It gave me my first inkling of how joyful it is to write programs that solve problems for people. It was just three plastic S-R flip-flops and six plastic and-gates, but it was enough—it served. Then... for me... it began...
But the joy I felt soon became tempered by the realization that software systems almost always degrade into a mess. What starts as a clean crystalline design in the minds of the programmers rots, over time, like a piece of bad meat. The nice little system we built last year turns into a horrible morass of tangled functions and variables next year.
Why does this happen? Why do systems rot? Why can’t they stay clean?
Sometimes we blame our customers. Sometimes we accuse them of changing the requirements. We comfort ourselves with the belief that if the customers had just been happy with what they said they needed, the design would have been fine. It’s the customer’s fault for changing the requirements on us.
Well, here’s a news flash: Requirements change. Designs that cannot tolerate changing requirements are poor designs to begin with. It is the goal of every competent software developer to create designs that tolerate change.
This seems to be an intractably hard problem to solve. So hard, in fact, that nearly every system ever produced suffers from slow, debilitating rot. The rot is so pervasive that we’ve come up with a special name for rotten programs. We call them: Legacy Code.
Legacy code. The phrase strikes disgust in the hearts of programmers. It conjures images of slogging through a murky swamp of tangled undergrowth with leaches beneath and stinging flies above. It conjures odors of murk, slime, stagnancy, and offal. Although our first joy of programming may have been intense, the misery of dealing with legacy code is often sufficient to extinguish that flame.
Many of us have tried to discover ways to prevent code from becoming legacy. We’ve written books on principles, patterns, and practices that can help programmers keep their systems clean. But Michael Feathers had an insight that many of the rest of us missed. Prevention is imperfect. Even the most disciplined development team, knowing the best principles, using the best patterns, and following the best practices will create messes from time to time. The rot still accumulates. It’s not enough to try to prevent the rot—you have to be able to reverse it.
That’s what this book is about. It’s about reversing the rot. It’s about taking a tangled, opaque, convoluted system and slowly, gradually, piece by piece, step by step, turning it into a simple, nicely structured, well-designed system. It’s about reversing entropy.
Before you get too excited, I warn you; reversing rot is not easy, and it’s not quick. The techniques, patterns, and tools that Michael presents in this book are effective, but they take work, time, endurance, and care. This book is not a magic bullet. It won’t tell you how to eliminate all the accumulated rot in your systems overnight. Rather, this book describes a set of disciplines, concepts, and attitudes that you will carry with you for the rest of your career and that will help you to turn systems that gradually degrade into systems that gradually improve.
Robert C. Martin
29 June, 2004