I finally finished “Working effectively with legacy code”, reading it a few pages at a time every morning on my way to work. Legacy code is one of these topics you know are important, but which you never really want to hear about, so the book has stayed on the backlog for a while. Recently, I helped out someone establish tests on a legacy code base, and began following Michael Feather’s tweets with great enjoyment, and decided it was time to read it.

Who should read it?

The developer who is already familiar with unit testing, comfortable with his language, object-oriented concepts, and what makes code maintainable - and wants to expand his thoughts and tools on testing and testability.

3 things I liked about it

The chapter titles are awesome – just like good naming is a hallmark of Clean Code, the chapter titles convey very clearly what the intent is. “I need to change a Monster method and I can’t write tests for it”, “It takes forever to make a change”, “How do I know that I am not breaking anything”, “I am changing the same code all over the place” – they all evoke situations we have been through one time or another, and the corresponding chapters do address these questions head-on.

Clear concepts and vocabulary: if anything, the one sentence that will stay with me is “legacy code is simply code without tests”, a wonderfully clear and opinionated definition, which not everyone may agree with. Feathers defines a few concepts (like a Seam or a Pinch Point), which provide a helpful language to think and and discuss legacy code.

Multiple languages: I write primarily in C# and F#, so in principle, learning about specific issues of testing legacy C code isn’t high on my concerns list. Still, I found that going through examples in languages I am not familiar with was interesting, in that it provided both a broader perspective on testing and on the relative strengths and weaknesses of various languages. It also made me think of techniques I seldom (if ever) use in C#, like pre-processor directives.

3 things I didn’t like that much

Multiple languages: covering multiple languages provides a broader perspective, but it also comes at the expense of each individual language. If you are specifically interested in, say, C#-specific techniques, this book may disappoint you - it is fairly general.

A bit dated: for a book published in 2004, it aged remarkably well. Still, 8 years is a long time in computer-years. From a C# developer perspective, there have been a few major releases of both the language and the IDE, with implications on testing and refactoring. I would assume (hope) that today, most language/IDEs do support refactorings like Extract Method. On the language side, the book touches on using function pointers to achieve decoupling, but the context is mostly C. With the emergence of functional concepts (Func<T> in modern C# for instance), I think this would warrant a bigger discussion today.

A somewhat tedious read: this book is not exactly a page-turner. Reading legacy code examples (a good part of them probably not in a language you are comfortable with, unless you are a polyglot) and figuring out mechanical steps to disentangle it isn’t material that will be turned into a Hollywood movie any time soon.

Parting thoughts

I really enjoyed this book, but I would recommend it with an asterisk. Depending on how you want to look at it, a polyglot book will either lose specificity, or gain generality. Personally, I think in this case, the gain in generality easily compensates for the lack of depth in each individual language. Yes, I would like a C#-specific book which points to useful, up-to-date tools – but that book would be obsolete in 2 years at best. By covering a variety of languages, Feathers illustrates very different solutions or ideas, and because he uses only fairly simple features in each language, the ideas remain easy to understand and convert into other “coding dialects”.

My personal bent is for concepts and language, because they last longer than recipes and tools, which is why I really enjoyed this book: it helped me create / articulate a mental map. I don’t have many computer books published in 2004 that I read for insight, today – and this one feels like one of these “timeless classics”.

That being said, I think it takes a certain experience with unit testing and code maintenance to appreciate the book, and I wouldn’t recommend it to someone who is just starting with tests and wants to find quick solutions to their problems. It may work (the book is very clear on steps and methodology), but I suspect it may be potentially frustrating.

Totally unrelated note: this is the first technical book I read on Kindle, and I have mixed feelings about it. I was hoping that the Kindle could serve as a portable library for all these massive technical bricks. On one hand, it’s nice to have the possibility to carry around searchable books; on the other hand, clearly, it’s not the best way to read through code samples, where good old paper still has an edge.

Who should get this book

This book is definitely for programmers. It’s a series of 15 lively interviews with legendary figures in software development, covering question ranging from what makes code beautiful to how to recognize a good programmer. If you are interested in the history of the young field of software, and want to get some perspective from highly respected people in the area, this book is for you!

3 things I enjoyed about it

Hear what the Masters have to say: every developer has his/her opinion on what good code is, whether comments are good or bad, or how to debug a program. This book gives you the opportunity to hear what people who really know what they are talking about think about this. Chances are, you won’t be able to talk about this with Donald Knuth around the water cooler and hear his take – you’ll get that with this book. Furthermore, having 15 different takes on similar questions provides an interesting way to compare views, and see where everyone agrees, and where there is disagreement.

A lively discussion: full credit goes to the author, Peter Seibel. He is a great interviewer, and has solid credentials as a developer, and it shows. He asks great questions, and the excitement of the discussion shows in the book. It’s also full of anecdotes and stories from the trenches, and fantastic quotes, making it a really entertaining read.

Literate programming: I was at least familiar with most topic discussed in the book, but I had never heard of literate programming before. Most of the interviews discussed this approach to programming, and generated interesting discussions - and made me curious about it.

3 ways I would have liked it better

Old school: I often feel that I started computing in the Dark Ages. I mean, my first computer had no mouse and hard drive, and its floppy drive made it cutting edge. Most of the guys in the book have worked with punch cards, and talk about devices which I can’t even begin to imagine the purpose of (rotating cylinders?). On one hand, it makes for great anecdotes, and gives a broader perspective on software development. On the other hand, it felt a few times like what they are describing is a bit disconnected from my own experience.

Length: I really enjoyed the book, but I had to read it by small installments. As much as I am a geek, there is just that much I can read about this in one single day!

… and I couldn’t find a third criticism.

Final thoughts

I really enjoyed that book, and would recommend it to anyone who is interested in software development, and its history. There are two points that I found intriguing in the book. First, no one seems to like C++ – which came a bit as a surprise to me. I don’t use C++ myself, but I naively thought that as a widely used OO language, it would have supporters. It doesn’t seem to be the case. The other point I found interesting is that the idea of design patterns was shot down by quite a few people, with arguments along the lines of the architecture astronaut criticism dear to Joel Spolsky. I definitely respect that opinion, but I wonder if this is generational, and has to do in part with developers used to work with low-level languages, in a time when low-level concerns mattered more than today.

Who to give it too

This is an excellent book for the C# developer with solid foundations in object-oriented design, who has already some exposure to writing unit tests. If you have worked on a decent-scale project, and found yourself thinking “hmmm, I am sure there is a smarter way to write these tests”, you should definitely get that book. Note that while it will be extremely useful to the test-driven development practitioner, this is NOT a book on TDD.More...

I finished “The Drunkard’s Walk – how randomness rules our lives”, by Leonard Mlodinow, a few days after Sway; I have postponed writing about it, because a minor storm of work has hit my parts – but I really loved this book, and thought I should say a few words about it.

The book’s point is that humans are very bad at drawing conclusions from observations of random phenomena. They routinely make gross mistakes when dealing with conditional probability (92% of Americans, some of them with pretty solid mathematical credentials, get the Monty Hall problem wrong), and fall prey to the Law of Small Numbers, seeing patterns where there is none, and refusing to admit the importance of randomness in shaping our fates. In the end, the message is pretty upbeat – I loved this quote from Thomas Watson:

If you want to succeed, double your failure rate.

I really enjoyed how the book builds up following the history of probability and statistics; some of the individuals who contributed to its development are truly remarkable (just lookup Cardano for instance), and the book contains a fair share of anecdotes about them. If anything, it gave me my first introduction to Benford’s law, which I am still digesting – and which has been weirdly prominent in the news, via the Iran election issue.

In short, I strongly recommend this book if you are interested in either history of sciences, probability, or decision making.

While travelling to Seattle, I went shopping to the bookstore and purchased “Sway – the irresistible pull of irrational behavior”, by Ori and Rom Brafman. Each of the book’s chapter illustrates a specific bias which leads individuals to make poor decisions, through multiple experiments or real-life stories.

If you are familiar with decision theory, and specifically with decision biases – the way our brain plays tricks with us and processes information poorly, misleading our judgment – you will probably not learn much from the book. Even then, it’s a pretty entertaining read; the style is light, and the anecdotes and cases funny and very clearly explained. If you are not familiar with the topic, I recommend the book: it is a good primer to recognize traps and make better decisions!

The part which was new to me was the chapter “Compensation and Cocaine”. It seems that monetary decisions and altruism are processed in completely different parts of the brain (no surprise so far), but also that when one is active, it shuts down the other. Furthermore, the monetary decision brain is processed in the same place as the center of pleasure derived from sex, drugs or gambling (not sure what this says about the financial sector…), which has very practical implication in designing incentives. From what I gather, altruism provides a stronger motivation than money – but surprisingly, mixing both doesn’t add up: the pleasure center will completely override altruistic motivation, which is then ignored – and reduces overall motivation.