These nine practices could save the software industry. Beyond Legacy Code is filled with practical, hands-on advice and a common-sense exploration of why technical practices such as refactoring and test-first development are critical to building maintainable software. Discover how to avoid the pitfalls teams encounter when adopting these practices, and how to dramatically reduce the risk associated with building software—realizing significant savings in both the short and long term. With a deeper understanding of the principles behind the practices, you’ll build software that’s easier and less costly to maintain and extend.
By adopting these nine key technical practices, you’ll learn to say what, why, and for whom before how; build in small batches; integrate continuously; collaborate; create CLEAN code; write the test first; specify behaviors with tests; implement the design last; and refactor legacy code.
Software developers will find hands-on, pragmatic advice for writing higher quality, more maintainable, and bug-free code. Managers, customers, and product owners will gain deeper insight into vital processes. By moving beyond the old-fashioned procedural thinking of the Industrial Revolution, and working together to embrace standards and practices that will advance software development, we can turn the legacy code crisis into a true Information Revolution.
David Scott Bernstein has shared his passion for building software with thousands of developers at hundreds of companies around the world including IBM, Microsoft, and Yahoo. His firm, To Be Agile, helps teams adopt Extreme Programming practices such as test-first development, pair programming, and refactoring.
I've become somewhat wary of "how to be a better programmer" type books in recent years. I really want to become a better programmer, but I've been doing this for over a decade and it's gotten to a point where every book I pick up feels like rehashing the same stuff from Pragmatic Programmer, or adding codified common sense. I know it sounds like I'm tooting my own horn, like I think I'm some great programmer, but that's not what I'm trying to say - it's just that a lot of these kinds of books have little new to offer someone who has been in the industry as long as me.
I probably wouldn't have bothered picking up Beyond Legacy Code if not for the fact that the author actually mentions my master's thesis in the last chapter of the book (though he gets my name wrong, grumble), because I think it mostly fits the bill of "general book about being a better programmer."
I'm really glad I wound up reading it though, because for the first time in ages one of these books actually gave me a lot of new stuff to ponder and think about. Naturally there was a lot of head-nodding, as the book reiterates lots of things I already know, but David Scott Bernstein definitely did put these ideas to words in extremely novel and useful ways. In particular, I loved the CLEAN code acronym, which I'd never seen before and have now mentioned multiple times at work. It's not that CLEAN (Cohesive, Loosely coupled, Encapsulated, Assertive, Nonredundant) is a new way to look at code, but it IS a very handy pneumonic that's easy to reference and remind yourself of, like SOLID, DRY, YAGNI, etc.
Bernstein's chapter on Practice 2: Build In Small Batches, is particularly excellent. Not merely content with reiterating common sense ideas about building code, the chapter cites tons of studies and figures to back up the claims, really showing the value of building and releasing in small batches and avoiding huge team utilizations. I've directed people to read this chapter on multiple occasions since reading it, it's fantastic.
I think the title of the book is a bit misleading - I was kind of expecting something like Michael Feathers's excellent Working with Legacy Code, but I think the "Legacy Code" aspect of this book is pretty minor, in fact only Practice 9 deals with it directly. The rest of the chapters are more, how to write good code in general, and I suppose you could argue that all code is Legacy code once it's written, but the book title still had me expecting something a bit different. I also felt like the final chapter, Learning from Our Legacy, went on a bit too much, the final section in particular seemed to restate the exact same thing over and over, it kind of had a "can't figure out how to end" vibe to it. Part 1 of the book, which establishes how much of a "crisis" we're having in software development, was similar, you kind of read it going "okay, I get it" and wanting to get to the meat of the book.
Those minor gripes aside though, I think the book is definitely well worth reading, and I think it's earned a place on the shelf right near The Pragmatic Programmer as mandatory reading for junior and senior developers alike. Definitely highly recommended.
If you are a software developer, this is required reading. Although not all of the ideas presented are new, Bernstein presents them with a good narrative.
Each chapter has a Retrospective section which outlines the chapter. These are great to review the section just presented and can be used as a reference in the future.
I don't fully agree with everything he presents (e.g. using Cucumber for testing) but Most his ideas I'm in agreement with and he presents cited sources for the information.
I had bigger expectations about this book. Instead I just got a general overview of too well known development practices. Nevertheless, It could be nice intro for beginners or people outside development. I found some interesting bits like about pair programming but more often I had to struggle with too wordy explanations or repetitions etc.
A nice compendium of good development practices and principles, focusing on the rationale and the context for each one, rather than the nitty-gritty details of their techniques.
I had higher expectations for this book Maybe if this was the first book on software development I've read, I would review this book higher.
I'm a software developer with 15 years experience building software, mainline in OO, C# and Java mostly. My bookshelves are littered with programming books. Some of my favourites are Code Complete 2, The Pragmatic Programmer, Domain Driven Design, Clean Code, Software Craftsmanship, Working Effectively With Legacy Code, Test Driven Development by Example, Extreme Programming eXplained, just to name a few.
Compared to the existing literature, there isn't really anything new here. So for experienced developers familiar with TDD and Agile practices, there's not much new here to learn.
One gripe I have with the book is the usage of C.L.E.A.N. Cohesive, Loosely Coupled, Encapsulated, Assertive, Nonredundant. I don't think these describe what clean code looks like. To me, coupling / cohesion is more of an academic term than a pragmatic one. I don't think in those terms when I write software. SOLID principles are more close to how I think, with most emphasis on SRP, and adding in the DRY principle.
1. Passes all the tests 2. Reveals intention 3. No duplication 4. Fewest elements
Since there's only 4 rules, it's easier to grasp, and they lead to nice, clean, simple code.
If this is one of the first software development books you read, you'll get a lot from it. Hopefully this encourages you to dig deeper, and want to become a better developer. For senior developers with TDD experience, there aren't a lot of new ideas here.
As opposed to the title of the book, S. Bernstein does not focus here on how to deal with legacy code, but rather on how to avoid producing some in the first place. He details nine well-known "practices" (CLEAN code, TDD, refactoring, emergent design, etc.) and explains how they tame the growth of legacy code. I found the text pleasant, but I believe some content are already covered in other books such as Extreme Programming Explained: Embrace Change, Emergent Design: The Evolutionary Nature of Professional Software Development or Clean Code: A Handbook of Agile Software Craftsmanship to a lesser extent. Still, I would recommend the book to anyone unfamiliar with modern software development practices, as it remains a very good overview of the core practices.
A disappointment, in short. The author knows his subject. He damn knows it well. The content is here, if you have the will to concentrate on it : it is summarized as the 9 principles. The thing is, even if he is a decent story-teller, he is not a very good writter. The text is almost exclusively focused on declarations of intent, but very few practical material. My take-away bag was practically empty once the last page was turned. Ma note de lecture en Français ici
Excellent read because this book is written in human terms. This is the book to give to your budding agilists, your leaders who do not understand why software is an excellent, disarming understanding. There is a more technical section at the end that you will be ready for, after so many excellent chapters on concept ahead of it.
A must-read book for anyone inside or in close proximity to the software industry that lays out a serious issue with Legacy Code then spends the majority of the book with practical advice for developers AND MANAGERS on how to move forward into a bug-free future.
I picked this up again, not remembering that I had read it before...and learned there's a reason: the title isn't very good. This book really isn't so much about legacy code, it's really just a pretty basic treatment of good development process and practices. Pretty familiar stuff, if you've read books like Clean Code: A Handbook of Agile Software Craftsmanship and its ilk.
I was expecting something a little more targeted at, well, legacy code -- a sort of companion or alternate take on Working Effectively with Legacy Code.
Good: - A ton of good content. A nice complement to "The Art Of Agile Development", focused a little more from-the-outside-in. - Good formal mix of principles and almost-actionable practical tips. - At its best, this reminds me "Superforecasters" but for writing software.
Meh: - Very focused on Object Oriented design, which I would say was a flaw when it was published and severely dates the book in 2020. This is acknowledged at one point, way too late. - A lot of throw away references to non-software worlds (medicine, engineering disciplines) are often naive and sugar-coated, in a way that makes me skeptical of everything the author says.
If you had been following XP and Agile practices, the nine principles mentioned in the book may feel like a repetition. But the first part of the book was an eye opener where need of such practices, and where our Software Development industry stands is explained with all the propositions being backed up with solid data.
A good read for seniors in the industry; should give a new perspective of thinking for the industry in addition to individual’s career and project.
David S. Bernstein explains in this book his approach to prevent legacy code in the first place. While he also has good advice to stop making code worse, his advice is best used at an early stage of code degeneration. The book shines when it goes about practices of software development. If you ask yourself questions like “What should I do?” or “Where can I start?” then you find your book. You can follow the advice to improve your code.
Some chapters in the second halve of the book could be a little more to the point. However, the rest is well written and explains a current view on software development practices.
A great overview of modern software developing practices, written in everyday language that even non-technical people can get. The title might be a little misleading: the idea is that if we use the practices of the past, our code is already outdated as soon as we write it. There's much wisdom in this book; common sense that's unfortunately all too uncommon.
It wasn't earth-shattering, but it was a good survey essential technical and planning practices for software development. This might a good book for bootstrapping a new developer into the practices of an existing Agile team.