Beyond Legacy Code

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.