[gcblkjaidfj]

Martin Fowler is in the certification for box checkers business.

99% of the people that read them work at places where they must "move to X" to justify some department. They will likely implement a simulacrum of X (usually by importing some java library someone wrote as homework), adding all the pitfalls and future problems of X with zero of the benefits of X.

[thewarrior]

This is too dismissive. Most of Fowler’s work is written after interviewing lots of real world practitioners.

[morty_s]

Haven’t really read Fowler’s stuff, but I have read Martin Kleppmann’s Designing Data-Intensive Applications and that was helpful. Haven’t seen it mentioned here (though I haven’t looked thoroughly through the comments). Just thought I’d mention it here.

[dominotw]

I think that most recommended book on HN.

https://news.ycombinator.com/item?id=25987664

[zwieback]

Agreed, Fowler, Martin, etc. are often criticized not because of their work but because of their audience, or more specifically their paying customers. Makes little sense to me, I got a lot out of their writing, especially in the early days of OO.

[disgruntledphd2]

Fowler and Beck in particular have been massively useful to me recently. Refactoring and TDD by example are wonderful books, and completely changed my approach to software.

I also love Feathers and Working Effectively with Legacy Code, but that might be more of a niche taste ;)

[Jtsummers]

Working Effectively is a bit niche, but unless a team is willing to rewrite from scratch or stumbled on a perfect design, refactoring and dealing with untested code will hit everyone eventually. Hell, test suites may themselves not be sufficiently preserved or remain fully functional after enough time has passed. One of my best time investments was reading that book.

[mpfundstein]

Mind if I ask what your 3 most important take aways were and how you benefit from them in your work?

Thanks

[Jtsummers]

It's been a long time, so I had to ponder this question for a bit.

In context, I was working on precisely the kinds of systems that Feathers is talking about when I read the book. His definition of "legacy" revolves largely around a lack of testing which makes changing the system very difficult (you can't be sure what you've done hasn't broken something else, slows you down to make a proper analysis, or you move fast and almost certainly break things). We had inherited a 500k SLOC embedded system for maintenance, with changes needed, but the previous developers had stripped out all tests when they shipped it. Literally, I found the directories for tests and the test framework and every file was removed. So even if the system wasn't legacy before, it was by the time it got to us.

While I learned a lot, the primary benefit was improving my ability to communicate ideas I already had formed or solidified those ideas in my mind. I had struggled for a long time (I've talked about this in other posts) with managers not seeing the value of spending time building out automated test suites or enforcing good architecture/design, and there's only so much one person can do. Having a more articulate argument was very helpful.

Things I believed before and were reinforced by the book: automate testing as much as possible, unit testing is generally a positive and enabled by good modular design, modular design is critical to keeping a system sustainable over the medium and long term.

I'm looking through the table of contents to make sure what I'm talking about next came from this book and not other readings.

Particularly useful: His discussion of the "seam" model. Which is, in other terms, related to finding module boundaries and dividing the system cleanly into those modules when it wasn't already. If a system wasn't designed with modularity in mind or the clean initial lines weren't maintained, then these seams can be hidden away or blurred. He discusses, early in the book, how to find this, how to refactor to separate these modules, how to develop tests for each module. Looking at the TOC, it looks like chapters 9 and 10 were probably two of the more useful ones for me ("I can't get this class into a test harness" and "I can't get this method in a test harness").

Also, if you're working on a clean slate system this book is still helpful as it can help you keep the pitfalls in mind so you avoid creating another legacy app. A lot of what it discusses is still present in other good books (particularly those with an emphasis on refactoring, like, well, Refactoring and OO/modular design), but in the context of trying to change/improve a system that doesn't have a good (present) architecture or tests to aid you.

One caution, the print copies have gotten worse over the years. Get a digital copy or an old print copy. My office had a printing with about 20 pages repeated on top of 20 missing pages (for example, page 140->141 is actually 140->121 or whatever the numbers were), and when I bought my own, much more recent, hard copy (which I think I left with a coworker at that office when I moved because it's not here at home) it had other, similar, issues. I think I had a whole chapter missing two half chapters repeated in its place. O'Reilly has it in their digital library which I have had access to through most employers so that's where I actually ended up reading most of it.