Very short and to the point book, but summarizes many of the best practices I personally value. Highly recommend for introducing folks to the ideas behind software craftsmanship.

Tidyings section is nice, but it could be expanded

After a synthesis of the main gestures used for refactoring, Kent does an excellent job at giving a theoretical frame to help decide when to refactor.

This provides a great helicopter connection between the details of what refactoring means on the ground and the bigger picture of what it means at the strategic level for the organisation.

Contains small index of mini refactorings called tidying(s) meant to simplify existing code, and minimize the cost of change over time. The book is a quick and easy read. Much of the content is common sense, but common sense attained from years of experience.

When a software developer is writing code, she/he is often confronted with a problem: How much work should I put into writing “the best” code versus just doing a quick but serviceable job? Kent Beck, pioneer of the influential Extreme Programming: Embrace Change, addresses this question via an in-depth look at the process of “tidying” code. His answer is usually to “tidy first”… but not always. This book seeks to identify exactly when one is in those exceptional situations.

Interestingly, Beck even explores economic reasons in his analysis – a main driver of developer effort that’s not talked about much in development books. These reasons are explored at a theoretical level that incorporates a bit of economic theory.

At times, this book can seem to be overly organizational and thus a bit dreary. That is, it categorizes situations instead of constructing a narrative. This approach became an extremely obvious limitation while I listened on an audiobook format. Perhaps a written text might avoid this pitfall somewhat more, but I suspect that even then, this shortcoming will show up in the reader’s experience.

This book’s audience is limited to those engaged in the art and practice of software design and development. The size of that audience is not huge, but it is growing. Developers can continue to learn from Kent Beck, one of the most observant, self-aware software authors in the industry. Those who desire to better themselves daily will benefit from his passion and attention to detail in this book.

I've read several books on refactoring over the course of my career, including both editions of Martin Fowler's book Refactoring. What they all have in common is that refactoring is powerful but ends up feeling like this massive undertaking that will break your code, particularly if it's not well tested.

The problem with traditional refactoring comes into play when there are other people waiting for the work you're doing. There's pressure from product and engineering leadership to get something shipped. Refactors aren't necessary to those stakeholders and so it just ends up in a backlog of technical debt to be solved when that part of the code breaks in production, probably as a rushed hotfix.

Tidy First has made me realize that it's ok to just do a little cleanup around the changes I'm making. Keep it small, and don't change the behavior. As I was reading through this book, in a single sitting, I realized that I already do many of the tidyings Kent recommends, I just didn't have a proper name for them or consider them as refactors.

Where the true value of this book comes from is in the when and why sections. I now have a framework to apply to the decisions I make to know when it's ok to tidy the code and an understanding of why I should or shouldn't make those changes.

This book belongs on the desks of every software engineer. Refer to it whenever you see code that looks a little messy or is hard to understand.

I look forward to reading the rest of the books in this new series that Kent is releasing!

On the plus side, "Tidying" code (making small structural, but not functional, refactoring code changes) makes perfect sense, and this book reminds us all to leave the code campsite cleaner than we found it, as it were, so to speak, Not really a new idea, but Kent provides a new word to describe what we do. Plus, the book is very short, and thus a quick and easy read. Each chapter is only 2 pages or so long. It also provides a timely reminder about the importance of coherence and coupling, and it even made me go and dig out my old copy of Yourdon and Constantine's "Structural Design" in order to re-read their original thinking on these topics.

On the negative side, it is not prescriptive, and I got a little frustrated by Kent rambling on about minor details such as whether to tidy the code before or after making functional changes, and/or whether to separate the tidying into a separate pull request or not etc. etc. The answer in almost all cases was "it depends" (and/or it doesn't really matter). I'm not sure I will continue reading his other, yet to be published, books in this new series. Not his best work perhaps. Sorry Kent.

This book is very practical and down-to-earth. I appreciate that the author has a vision for a series of books on software design, with this being the first manuscript. His writing style is engaging and entertaining, and I now have a greater appreciation for tidying my code and the proper methodologies to do so when the opportunity arises. Thank you for putting this book together, Kent. I look forward to reading the rest of the upcoming series on software design.

One of the few short books I have read that is packed with so much knowledge. Highly recommend!

Short story:

It was a quiet Thursday afternoon, I was sitting at my desk in the office. Suddenly, but not unexpectedly, a notification arrived - one of the jung devs assigned me to a code review. 30+ changes. Nothing crazy. Business as usual. I was kind of bored, so I decided to do it the old-school way - pair with the dev and ask the dev to guide me through the changes. We were both in the office anyway.

While reviewing we found a couple of things that could be improved, refactored, or deleted. In the beginning, the dev was in an "OK, that's a cool suggestion" mood, but after a while, he said, "Are you sure that this is in the scope of this ticket?". My immediate answer was "What? Do you expect a ticket that says 'please refactor your messy code'?". The dev's answer was "No", and the refactoring began. It wasn't anything large, split the big class into two smaller classes, one for read-only operations and one for everything else, plus a couple of minor facelifts.

While riding home, my brain was raging. This is the root of all software problems. Jung developers think in terms of tickets. They don't refactor their code, because they think that this process should be somehow regulated by the management. They wait and wait and what, applying more and more duck tape changes to the code, and so the mess grows and grows.

After two days of raging and trying to assemble my thoughts into something structural I started to google. There should be something on this topic. I found a couple of Kent Beck's talks on YouTube, the most important being "Tidy First? Kent Beck on Refactoring". Oh my god, this is exactly what I'm thinking about. I've promptly ordered the book. Read the same day it's arrived. 100 pages, with quite a few being blank for better chapter separation. Kent nails it. Everything makes perfect sense. Everything starts with the individual, your relationship with yourself, and your goals.

This is the exact book I need to explain to the devs how to approach refactoring on a small single-contributor scale.

If you're still thinking about it - just do it. It's worth it.

You can read about this book in his blog tidyfirst.substack.com

Having read some of the reviews, I got this on Kindle (a second-hand book would have been better).

The book is structured into 3 parts - Tidying, Structuring and Theory, broken into 30 small chapters; each chapter is maybe 2 pages (on a Kindle), excluding drawings - its would be a thin book and at 6pence a page its feels pricy.

Some of these suggestions should have gone into something like StyleCop. What he is doing is recounting all the pain points he has had over the years. Sometimes, writing code one way or another is a flip of a coin, so which do you choose? I have been maintaining some very expensive software, and his point about 'Just Delete It' was initially criminal (the company invested in its development, but we don't know what it does or if it's used), but it still exists in GIT history, so who is going to be the brave one to check in the deletion? So he talks about monitoring and metrics, which is a bit like a ReSharper HeatMap of your code, what the critical bits are, and what the dead wood is. The simple tips about shaping your Guard Code, eg do all the 'Returns' first to assert your preconditions, then all that is left is simple, understandable, happy path code.

However, everything in this book is what your Senior Developer passes on to the less Senior Developers. It would be nice to imagine they taught this stuff in universities, but they don't.

So, who is this book for?

Well, given the multimillion-dollar system (C#) I last worked on, I wish my team did. It's chipping away at the monolith, tidying up as you go, like eating the elephant one mouthful at a time. Sometimes, stuff is only obvious when it's written down, like the answer to a maze.

His point about Debugging Fortran can be applied to other code bases and this era, but Fortran has never run distributed in the cloud.

I'm guessing a Team Lead would encourage his team to have these habits, so he would read this book and in dev meetings instill these habits.

o'reilly publishing sucks. I wish authors self-published. I would buy that instead.

This book(let) probably should've been just a couple of blog posts. I can't disagree with the advice it gives, but there's not a lot and it's all so very, very basic. There are some good lessons in it for very new and inexperienced developers, but then there's easily a dozen better books to recommend instead.