Review: The Thoughtworks Anthology: Essays on Software Technology and Innovation

The Thoughtworks Anthology: Essays on Software Technology and Innovation
The Thoughtworks Anthology: Essays on Software Technology and Innovation by ThoughtWorks Inc.<br/>
My rating: 3 of 5 stars

I read this first volume after reading its successor. Compared with the latter, I found the first volume to be slightly disappointing.

Like its successor, it’s a series of essays from Thoughtworks employees, including Martin Fowler. Whereas the second volume had some detailed, practical advice, I found this one to be much more vague and generic. It sounds almost as if it was written during the early years of the agile movement (which it maybe was), giving advice and recommendations that seem common sense today.

Martin Fowler’s article on Domain Specific Languages, although interesting, is of limited value now that his book on the subject has been published. Rebecca Parson’s article on programming languages sounds like yet-another-look-at-how-many-languages-I-know kind of article. Neal Ford’s article on Polyglot Programming recommends we build solutions with more than one language; well, people have been calling Fortran routines from C, or testing Java code with Scala, for several years now.

The only exception I want to make is Jeff Bay’s Object Calisthenics article. He proposes 9 rules to deliberately follow during your next project, and claims that following those rules will yield a superior design. This is one article I definitely want to apply, and which has practical value. Some of the rules sound extreme, such as “Don’t use any classes with more than two instance variables.”. But it’s definitely worth a look.
<br/><br/>
View all my reviews

Review: Linkers and Loaders

Linkers and Loaders Linkers and Loaders by John R. Levine

My rating: 4 of 5 stars

You may have written hundreds, maybe thousands of programs, but if you are like most programmers then everything that happens after the compilation is kind of mysterious. Why does the compiler have to create object files? What are they? What is this so-called linker who combines those files into a library, or an executable? What’s its purpose? John Levine’s book answers those questions, and more.

Item 53 in 97 Things Every Programmer Should Know: Collective Wisdom from the Experts is “The Linker Is not a Magical Program”, and this book goes a long way towards taking that magic away. It carefully explains step by step what happens from the moment the code is compiled until it actually runs on the machine; and what’s more important, it makes it very clear why things are as they are today.

I was recommended this book in a reply to a Stackoverflow question, and I am not disappointed. The book goes occasionally perhaps a little bit too much into technical details, which I felt could be safely skipped. Perhaps a case study, i.e. going through every single step towards running a complete program, would have been useful, instead of exposing how different systems solve the different steps one by one.

Until I read this book I simply did not understand how a program actually ran on my computer. A few details are still a bit fuzzy, but now I feel much better equipped for dealing with obscure linker errors or custom linker scripts. Highly recommended for any programmer who wants to get to the bottom of things.

View all my reviews

Review: Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development

Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development
Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development by Craig Larman<br/>
My rating: 5 of 5 stars

Easily one of the best books on object-oriented design I’ve ever read.

Through two case studies (a point-of-sale terminal application and a Monopoly game) the author goes through the entire process of eliciting use cases, domain modelling, design modelling, and implementation. The UML notation is introduced and used along the way, as are several patterns—not only the classic GoF patterns, but also some extremely useful design guidelines.

This book should be read by any senior developer who’s currently involved in the early stages of a software project. Even if you do not follow its recommendations to the letter, it will certainly improve the chances of success. For example, since reading it I make a nuisance of myself by insisting on having detailed, written use cases—not simply bullet points on some powerpoint.

This book belongs on any developer’s bookshelf, right next to the classics.
<br/><br/>
View all my reviews