This book will help you drop the cost of building and maintaining software.
If you’re a software developer, you’ll learn a set of practices to help you build changeable code, because when code is used it often needs to be changed. For managers working with software developers, this book will show you how investing in nine essential practices will help your team work more efficiently to deliver software that doesn’t devolve into legacy code. And to do that, you need more than just a technical to-do list—you need a firm understanding of the principles that add the why to the how.
Every day, we lose time, money, and opportunities because of legacy code.
Different people have different definitions for “legacy code,” but put most simply, legacy code is code that, for a few different reasons, is particularly difficult to fix, enhance, and work with.
And there’s a lot of it out there. Virtually all software that I’ve seen in production is legacy code.
The software industry as a whole hasn’t put enough value on maintainability, so businesses wind up spending a great deal more to maintain code than they initially spent to write it. As we’ll see in Chapter 2, Out of CHAOS, inefficiencies in how software is built costs businesses at least tens of billions of dollars every year in the United States alone—and this is hardly just some abstract figure on a ledger sheet somewhere. We feel the effects of legacy code every day. Software is expensive, buggy, and hard to enhance.
People from inside and outside the industry have taken sides and argued for or against certain project management methodologies—a lot of which contain some truly brilliant ideas—but in order to effect lasting change for the better, we first have to come to a mutual understanding of the fundamental goals of software development.
This book isn’t just about creating better software; it’s about creating a better software industry. It includes the best of what I’ve learned in the last thirty years as a professional developer. The first two decades of my career were spent doing traditional Waterfall software development where systems were planned, built, and tested in distinct phases. The problem was, the way we planned to build software turned out to be fraught with many unforeseen issues that forced us to make serious compromises in both quality and budget.
But over the last decade things have been changing for me, and for other software developers I know, who have been practicing an Agile software development methodology called Extreme Programming (XP). Instead of trying to figure everything out up front, we figure things out as we go, designing, building, and testing little bits of software at a time.
XP practices such as test-driven development and refactoring have taught me valuable lessons for decreasing both the risks and the costs of building and extending software. Using these practices has shown me a range of different approaches for solving software problems. Can applying these practices reveal ways of building higher-quality, more maintainable software?
I say the answer is a resounding Yes!
Early in my career as a programmer, I was assigned to reconcile stock data from the Standard and Poor’s feed into my client’s proprietary database. Until then the process was done manually, which was error-prone and took, on average, fourteen hours each day to complete. I had to automate this process, but the best approach to accomplish this was not clear to me at first.
After a few weeks, and after writing over forty pages of code, I had a flash of insight that involved reorganizing how I processed the data. Within a few hours I had finished the project and slashed out all but five pages of code. What I thought would take me several more months when I came into work that morning turned out to be finished before I left that evening. Since then I have had many flashes of insight that have revealed underlying patterns in problems that, once recognized, showed me how to rapidly build highly maintainable solutions.
This is but one example of dramatic differences in productivity between alternate ways of approaching the same problem. I’ve heard many similar stories from other developers. Perhaps you have your own stories of when you had a flash of insight and suddenly a difficult problem became simple.
In my professional experience, the difference between highly productive developers and average developers can be profound. I’ve spent most of my career studying those rare individuals who are many times more productive than average software developers. What I’ve learned is that these people weren’t born that way. They’ve simply formed some different distinctions than the rest of us and perhaps follow some unusual practices. All of these things are learnable skills.
As a young industry we’re still figuring things out and learning to distinguish what’s important from what’s unimportant. Building software is very different from building physical things. Perhaps some of the challenges facing the software industry are rooted in a misconception of what software development actually is. In an effort to understand software development, to make it predictable, it has been compared to manufacturing and civil engineering. While there are similarities between software engineering and other fields of engineering, there are some fundamental differences that may not be obvious to someone who isn’t actually writing software on a daily basis.
The fact that software engineering is not like other forms of engineering should really come as no surprise. Medicine is not like the law. Carpentry is not like baking. Software development is like one thing, and one thing only: software development. We need practices that make what we do more efficient, more verifiable, and easier to change. If we can do this, we can slash the short-term cost of building software, and all but eliminate the crippling long-term cost of maintaining it.
To that end, I offer nine practices that come from the Agile methodologies of Extreme Programming, Scrum, and Lean. When not just adopted but fully understood, these nine practices can help prevent the code we write in the future from becoming legacy code.
And though there is a lot of code out there that’s either impossible to fix or already slipping into obsolescence, we can use these same practices to slowly dig our way out of the mountain of legacy code we’ve already accumulated.
These nine practices will help development teams build better software, and help the industry as a whole stop leaking money, time, and resources.
I’ve seen these nine practices work for my clients, who build some of the biggest and most complex software ever created. I know it’s possible to achieve extraordinary results using these practices, but just “using” them by no means guarantees success. We must understand the principles behind the practices in order to use them correctly.
These are interesting times, and we get to be part of them. And while we are pioneers venturing into uncharted territory, there are guiding lights. The nine practices in this book have been guiding lights for me in my career as a software developer and beyond. I hope they become guiding lights for you as well.