I wrote Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software because I noticed two major disconnects in my experience as a developer. First, the more challenging technical practices such as test driven development and refactoring, were not being as quickly assimilated by teams as some of the simpler Agile practices like standup meetings and iterations.
This is understandable because many of the technical practices are more advanced and although they represent the highest value practices in Agile they are easy to get wrong. When we do get them wrong we suffer greatly. I also noticed that in many teams, management didn’t really understand or value the technical practices so developers were not really being empowered to use them.
Second, I wanted to demystify software development and make at least some of the ideas accessible to anyone. Do people outside the software industry really understand how software is created and maintained even though software affects all of us in profound ways?
While software is radically different than the world of physical things we all live in, many of the ideas we’ve been developing in the software industry have a great deal of value for everyday life, and for other disciplines like science and even art. Software is the essence of our new society and it’s at the core of the information revolution. So the ideas are important but very difficult for people without the background to access, and that’s because software is a world in and of itself.
One of the big challenges we face in our society both personally and collectively is the explosion of information that is coming at us all the time. It’s difficult to make rhyme or reason out of the barrage of data that constantly accosts us. Art, science, and the social sciences are also barraged with huge amounts of data. The reductionist aspects of science have helped us decompose ideas but at the same time it makes it very difficult for us to see the big picture.
These are not varying concepts to software development. One of the biggest challenges we face in software is managing complexity, so we’ve built many techniques and tools to help us with that. These ideas are either directly or indirectly transferrable to other areas of our lives.
I started playing with some of these concepts and discovered that I can explain them using some common terminology and some common sense.
I read a lot of books on software development, many of them are good but many of them aren’t. And even the good software books can be challenging to read, so I wanted to write a book that was more accessible and would actually be fun and engaging to read.
I also wanted to write a book that would change how people think about many of these technical practices and I know that in order to change people’s thinking and behavior, I’d need a lot more than just a series of facts. People learn through stories. They learn through anecdotes and metaphors and when we use these approaches, we often see people naturally taking up new behaviors. So instead of writing a technical treatise I decided to tell stories. The stories I tell come from my own experience working with thousands of software developers, and through these stories readers can see what works and what doesn’t.
Everything boils down to common sense, even the most technical practices are based on common sense and so I try to boil down the technical practices to things that anyone can relate to. I have a lifetime of experience in the industry, and I’ve seen ideas come and go. I spent much of the past thirty years being frustrated, but over the last fifteen years or so, I have seen great progress being made.
I have seen the practices that I discuss in my book both succeed and fail in the real world, and the key distinctions seem to be related to how well the purpose or context of these practices are understood by those who use them. So *Beyond Legacy Code* focuses on the reasoning behind the practices. There are principles that make them work, and we want to understand their purpose so we can apply them correctly.
I remember in the late 70s people talking about how thinking computers were just a few short years away. We don’t talk about that much anymore because we realized we have no idea how to program our computers to approach many of the problems we deal with as humans. If anything, the last few decades have taught us how *little* we know and if we want to take computers to the next level, to do really interesting things, then we have to build software more reliably. And that won’t happen with the “cowboy coder” mentality that pervades our industry.
Some people think that the practices of Extreme Programming (XP) are sort of a shoot from the hip approach to writing software but nothing can be farther from the truth. XP is a highly disciplined approach that requires a great deal of skill and focus. It’s not for beginners but when used correctly, it can be amazingly powerful way of building software.
These practices are not for everyone or for every project. They work especially well for challenging projects or pioneering software development where we’re building things we have never built before. The industry has a long way to go and we have been making great strides. Agile has gone from a nice idea to the standard in software development today. But Agile was started by software developers for software developers and the heart of Agile lies in technical practices that have to be well-understood.
This is why I wrote Beyond Legacy Code, to show that there are alternatives. The code we write is not inherently doomed to become legacy code that’s difficult to work with and hard to repurpose. If we pay attention to the forces involved in software development, to how things change and how we can adapt to change, then we can make our code far more adaptable. This will not only drop the cost of developing software but radically drop the cost of maintaining it.
To learn more, read excerpts, watch a video, and purchase Beyond Legacy Code, visit http://BeyondLegacyCode.com.
Previous Post: « How to Define a Successful Software Product
Next Post: Why Nine Practices? »