Mathias Brandewinder on .NET, F#, VSTO and Excel development, and quantitative analysis / machine learning.
by Mathias 17. February 2012 06:27
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.

by Mathias 21. February 2010 13:36

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.

by Mathias 15. October 2009 18:03
TheArtOfUnitTesting

I recently finished reading the Art of Unit Testing, by Roy Osherove (Manning); here are a few thoughts on the book.

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...

by Mathias 26. March 2009 12:32

I have been following Eric Lippert‘s blog for a bit, but I had not realized that he had co-authored a book on VSTO with Eric Carter until the second edition came out recently. I needed a good reference book on VSTO, so I went ahead and purchased it. And because the second edition is focused exclusively on Office 2007, but a good part of my VSTO work revolves around Excel 2003, I figured I might as well get the first edition, too.

I received my package from Amazon 2 days ago, and I must say, this is massive. As in, about 2000 pages total. I began skimming though, and so far I really like it. I have been learning VSTO mostly by grabbing pieces of knowledge here and there, and as a result my understanding lacks a bit of cohesion – which is where a book usually helps, by providing a comprehensive and structured approach to a topic. A friend of mine asked me today if I planned to read it all: probably not all in detail, but I’ll try to skim through everything. You don’t know what you don’t know, and glancing at everything quickly can prove surprisingly helpful.

Comments

Comment RSS