Blog Archive

Review of Working Effectively With Legacy Code by Michael C. Feathers

Wednesday, 12 April 2006

Michael puts a new spin on the term "legacy code", identifying it as code without automated tests. For those of us used to the more traditional meaning of the term, referring to old codebases full of cruft and quick fixes on top of hasty modifications on top of quick fixes, this is a somewhat unusual attitude — we like to think that our new code is clean and not "legacy code", even if it doesn't have automated tests. However, it doesn't take long for the former to turn into the latter — leave it 6 months whilst you work on another project, so you've forgotten the details, then rush through a bug fix because it needs to be in production tomorrow, and you're well on the way.

A lot of the book is spent covering different techniques for getting nasty convoluted code under test. These techniques often focus on breaking dependencies, so you can instantiate an object in a test harness, or call a function without it sending an email or talking to the database. In many cases, these are sensible recommendations for improvements to the codebase, but in some cases, Michael recommends techniques you wouldn't expect to see in production code, such as defining preprocessor macros with the same name as functions to avoid calling them, or writing dummy implementations of API functions. This is not to say that the book recommends such techniques wholesale — Michael is keen to point out that these techniques should only be used to get the code under test, so that it can be refactored safely.

Chapters are helpfully named, with titles like "This class is too big, and I don't want it to get any bigger", and the book gives good advice on how to deal with the nastiest codebases. The key recommendation underlying it all is "get the code under test, so you can refactor safely", and this is borne in mind with those techniques that require changing the production code in order to get it under test — these techniques provide step by step instructions to help you make the required changes without breaking anything.

The content of this book is excellent, and the writing clear, so it is unfortunate that it is marred by numerous minor errors, such as spelling mistakes, or using the wrong identifier when referring to a code example. However, this minor niggle is not enough to stop me recommending it — every software developer should have a copy.

Highly Recommended. This book is a must-have for anyone who has to maintain code — which is pretty much every software developer on the planet.

Buy this book

Working Effectively With Legacy Code
Michael C. Feathers
Published by Prentice Hall PTR
ISBN 0-13-117705-2

Buy from Amazon.co.uk
Buy from Amazon.com

Posted by Anthony Williams
[/ reviews /] permanent link
Stumble It! | Submit to Reddit | Submit to DZone

Comment on this post

If you liked this post, why not subscribe to the RSS feed or Follow me on Twitter? You can also subscribe to this blog by email using the form on the left.

Review of Extreme Programming Adventures in C# by Ron Jeffries

Tuesday, 14 February 2006

I thoroughly enjoyed reading this book. It is neither a guide to XP, nor a tutorial for C#; rather it is a description of Ron's efforts to produce a working program that provides real customer value whilst learning a new language. The program in question is an XML notepad, with the aim of making it easier for Ron to edit his website, and Ron guides us through it in the humorous manner common to all his writing. Ron being Ron, the project is undertaken in an eXtreme Programming style, though the limitations of the book project mean that he hasn't employed all the practices "as written"; he is his own customer, and he doesn't always manage to find a pair, for example. As you follow Ron through the project, with the aid of the lessons he pulls out, you get a better understanding of the way he develops software, and are given an opportunity to judge how it compares to what you would have done. You might also learn a little C# along the way, as Ron explains each new language feature when he first uses it, though this is not the key focus of the book.

The project is not just one big success story; Ron shares his mistakes with us so that we may learn from them. The book is interspersed with "lessons", where Ron reflects on the preceding section and tries to identify important points, either things that he felt worked well, or things the mistakes he made, and what he thinks could be done to try and avoid similar mistakes . Also throughout the book are sentences marked "sb", for "sound bite". These are short phrases which summarise a point, like "It's Chet's fault" (don't focus on finding who's at fault when things go wrong, rather focus on fixing the problem), or "You Aren't Gonna Need It" (focus on what needs doing now, rather than what you think you'll need for later). It is these lessons and sound bites which provide the "message" of the book — Ron's belief that incremental development, done test-first, with simple design, continuous refactoring and a focus on producing value for the customer is an effective method of producing high quality software.

If you like Ron's other writing you'll love this book. If you've never read Ron's stuff before and are interested in learning a bit about how he applies the principles of XP (and maybe a little C#), it's worth reading; you might even enjoy it.

Highly Recommended.

Buy this book

At Amazon.co.uk
At Amazon.com

Posted by Anthony Williams
[/ reviews /] permanent link
Stumble It! | Submit to Reddit | Submit to DZone

Comment on this post

If you liked this post, why not subscribe to the RSS feed or Follow me on Twitter? You can also subscribe to this blog by email using the form on the left.

Review of JUnit Recipes: Practical Methods for Programmer Testing by J. B. Rainsberger

Tuesday, 14 February 2006

When I discovered an obvious naming error in one of the early examples, I was immediately concerned about the level of proofreading that was done before publication of this book. However, I am glad to say that my concerns were unnecessary; there are no mistakes of any significance anywhere in the book.

The book is laid out into a series of chapters describing related techniques, such as "working with test data" and "testing web components", with each chapter split into a series of "recipes", each describing a particular technique. The layout of each recipe is good, with a problem statement, additional background, the details of the recipe itself, and further discussion. There are also references to other related recipes, that provide alternatives to, build on, or are relied on by this recipe.

The level of coverage is very comprehensive. Having read the book it feels like there is a recipe for testing just about everything you could write in Java, from simple classes, to XML generation code, database access code, EJBs, singletons, and JSPs. There are even recipes on managing your test suites, adding tests to hard-to-test classes, and the use of test implementations of other objects to allow testing objects in isolation.

Just because it focuses on Java and JUnit does not mean that this book is useless to anyone programming in another language. On the contrary, many of the techniques described can be applied in any Object Oriented language, though there are certainly some that are specific to Java. For this reason, I would highly recommend this book not just to Java programmers, but to anyone interested in improving the testing of their code.

Highly Recommended.

Buy this book

At Amazon.co.uk
At Amazon.com

Posted by Anthony Williams
[/ reviews /] permanent link
Stumble It! | Submit to Reddit | Submit to DZone

Comment on this post

If you liked this post, why not subscribe to the RSS feed or Follow me on Twitter? You can also subscribe to this blog by email using the form on the left.

Review of Agile Modeling: Effective Practices for eXtreme Programming and the Unified Process by Scott Ambler

Wednesday, 08 February 2006

This is a reasonably long book, at nearly 400 pages; it would be even longer if it wasn't for the excessively large number of words per page. I found this book hard to read, in part due to the layout, and in part due to Scott's writing style. Though he is a stout member of the Agile camp, Scott clearly also believes in the benefit of repetition to get his message across; there is many a repeated phrase or sentence, and there is at least one whole paragraph repeated word-for-word. All this detracts from the book, which is unfortunate since Scott has a lot of good things to say.

The book is divided into 5 parts. The first two parts cover the principles you should work to and practices you should be doing to say that you are doing Agile Modeling as Scott defines it. The values of Agile Modeling are the four values of eXtreme Programming, plus a fifth (Humility), and the principles and practices are then derived from applying these values to a modelling perspective. For example, the value of Courage leads one to Discard Temporary Models, and the values of Humility and Communication lead one to realise that Everyone Can Learn From Everyone Else, and that you should Model With Others. This description of the principles and practices forms the real meat of the book. Most (perhaps all) of what Scott says here is sensible advice which should be followed by anyone pursuing an Agile approach to software development.

The remaining parts describe the how Agile Modeling fits into XP and the Universal Process, with a discussion on introducing Agile Modeling into your process. This also includes a discussion of when Agile Modeling is *not* a good fit, as well as a check list of things you must be doing to say you are Agile Modeling, and a list of things which you must not be doing if you want to say you are Agile Modeling. The book finishes off with an appendix listing a host of modelling techniques to consider when the need arises; Scott is quite clear that you need to Apply the Right Artifact, and having a wide range to choose from makes this easier since you are not stretching a model beyond what it can easily cover.

If you are interested in modelling, and want to know how it fits into Agile projects, or you are looking to make your current process more Agile by reducing unnecessary modelling work, then this book is well worth a read; I just wish it was easier to read.

Recommended.

Buy this book

At Amazon.co.uk
At Amazon.com

Posted by Anthony Williams
[/ reviews /] permanent link
Stumble It! | Submit to Reddit | Submit to DZone

Comment on this post

If you liked this post, why not subscribe to the RSS feed or Follow me on Twitter? You can also subscribe to this blog by email using the form on the left.

Review of Agile Documentation: A Pattern Guide to Producing Lightweight Documents for Software Projects by Andreas Rueping

Wednesday, 08 February 2006

The title of this book is "Agile Documentation", but almost everything it says is applicable to documentation for any project, whatever methodology is used. Indeed, much of what is said is common sense if you think about it — but how often does anyone really think about it? Reading this book forces the issue, and hopefully encourages one to think about the purpose, readership and content of documentation a bit more in the future. However, some of the content is particularly important when trying to use an Agile development method, since it contributes to reducing the effort that is wasted on unused or unnecessary (or even unusable) documentation, whilst ensuring that the documentation that is produced is both necessary and sufficient for the project's needs.

The subtitle is "A pattern guide for producing lightweight doucments for software projects", which is quite apt. Essentially, the book consists of a set of patterns, divided into 5 groups, each of which describes a particular problem associated with documentation, and some discussion of the solutions. The key points are summarised in what the author calls "thumbnails" — a couple of sentences which appear in bold type in the pattern description, and which are then repeated in the "thumbnails" section at the back of the book. These enable you to browse through the book, reading each pattern heading and the corresponding thumbnail to get an overview of the pattern and determine whether it is applicable for your current situation, or jog your memory.

The patterns are not just presented on their own, they are backed up by experience reports from a number of projects that the author has been involved with. These are used both within the pattern descriptions, and in a separate section at the end of each chapter. They are not all positive, and are used to highlight the dangers of not following the patterns from the book, as well as the benefits of doing so. Overall, they give the advice a place of reference, and are the source of numerous examples.

One slight issue I had with the book was the number of typos, which was particularly unexpected given the subject matter. However, this did not detract too significantly from my overall impression: Highly Recommended

Buy this book

At Amazon.co.uk
At Amazon.com

Posted by Anthony Williams
[/ reviews /] permanent link
Stumble It! | Submit to Reddit | Submit to DZone

Comment on this post

If you liked this post, why not subscribe to the RSS feed or Follow me on Twitter? You can also subscribe to this blog by email using the form on the left.

Review of Lean Software Development: An Agile Toolkit, by Mary Poppendieck and Tom Poppendieck

Wednesday, 01 February 2006

If you're not convinced that Agile Software Development practices are at least worth investigating further after you've read this book, then you'll never be convinced. It is a well-written guide to the ideas behind Agile thinking, with plenty of references to other sources (the bibliography is 8 pages long); both those showing the benefits of Lean thinking in software and manufacturing, and the "original" sources for various techniques and methodologies. The interested reader therefore has plenty of material for ideas on where to go next, having accepted Agile practices as effective development practices.

The book divides lean thinking into 7 key principles, with 22 "tools" to help you adapt agile practices to your workplace. It also features a "try it out" section at the end of each chapter taking you through some simple steps that demonstrate how the particular techniques discussed can be applied to improve your software development process.

Some of these principles are obvious at first glance — "Eliminate Waste" for example — but this simplicity hides profound insight; in this case, the insight is that much of the "work products" of traditional software development processes are in fact waste, produced purely so the developer can "tick the box" and move onto the next task. Not only that, but the very process can itself generate waste — having analysts produce specs from customer requirements, which designers then turn into a high level design for coders to turn into software is very wasteful, because knowledge is lost at every stage; the very act of writing something down means that the understanding and background knowledge held by the author is lost, either permanently, or until the reader has acquired it for himself.

This book is aimed at project managers and lead developers looking for ways to improve their software development process, but I would recommend it to anyone who is serious about producing quality software. Whilst many agile practices require management buy-in (and if you can get your manager to read this book, it will probably help), others can be implemented by developers as part of almost any process.

Buy this book

At amazon.co.uk
At amazon.com

Posted by Anthony Williams
[/ reviews /] permanent link
Stumble It! | Submit to Reddit | Submit to DZone

Comment on this post

If you liked this post, why not subscribe to the RSS feed or Follow me on Twitter? You can also subscribe to this blog by email using the form on the left.

Review of C++ Coding Standards: 101 Rules, Guidelines and Best Practices, by Herb Sutter, Andrei Alexandrescu

Wednesday, 01 February 2006

The key points from the book are neatly summarised in the 12 page "Summary of Summaries" at the back of the book. This lists all 101 guidelines, with both their title and summary; the primary reason for reading the main body of the book is to understand the background and reasoning behind the guidelines, as well as any exceptions. These guidelines are not casually thrown together; they are well researched, with extensive references. It is also worth reading the introductory text to each section, as this pulls the guidelines from the section together; a nice touch from the authors is the selection of a "most valuable Item" from each section, one which you really really ought to follow.

In contrast with other books from Addison Wesley, such as Effective STL, which have a much easier-to-read layout, but in common with the other books in the C++ In Depth series, the text is slightly too small, and the margins slightly too narrow, so there is too much text on a page. This, combined with the high density of technical content, makes it hard to read cover to cover in one go. There are also a couple of errors; though nothing major, they do detract from the authority of the book, given the nature of the content.

In the preface, the authors state that they intended each item to be short, non-controversial, authoritative, and something that needs saying, and I believe they have achieved that. In any set of coding standards I usually find something that I disagree with, but there was not a single item that grated on me here. I agree with the authors that this book is something you should reference from your own coding standards.

Highly Recommended.

Buy this book

At Amazon.co.uk
At Amazon.com

Posted by Anthony Williams
[/ reviews /] permanent link
Stumble It! | Submit to Reddit | Submit to DZone

Comment on this post

If you liked this post, why not subscribe to the RSS feed or Follow me on Twitter? You can also subscribe to this blog by email using the form on the left.

Review of Test Driven Development - A Practical Guide, by Dave Astels

Wednesday, 01 February 2006

This book is subtitle "A Practical Guide", and it is definitely that. It includes an overview of many of the tools available to assist you in using Test Driven Development (TDD), along with detailed descriptions of how TDD works in practice. The bulk of the book is taken up with working through a complete project from start to finish using TDD. This demonstrates many of the techniques in action, and gives examples of how to test different types of behaviour, including the GUI, which is notoriously hard to test. The book also includes appendices giving an overview of eXtreme Programming and Agile Modelling.

Most of the book uses Java as the target language, and it does appear that the majority of tools available are for Java. However, that does not mean that the techniques discussed are not applicable to other languages; there are chapters in this book dedicated to the use of the "xUnit" testing framework for various languages "x" — such as C++, Python, and Visual Basic.

The main thrust of TDD is that you write tests for the expected behaviour of the production code before you write the code, and that you don't add new code to the system except in response to a failing test. This takes some getting used to, but the key benefit is that you get a high-coverage automated test suite which automatically tells you if you break something when you make a modification.

As programmers, we all know that automated unit tests are a Good Thing, but writing tests after the fact is difficult, and seems like a chore since we already "know" the code works. TDD is not like that. I've been trying it on my latest project, and I am now "test infected" — I'd rather work this way than how I worked before. Applying the techniques discussed in the book to C++ was relatively straightforward; with the help of a few editor macros, adding a new test takes just two key presses, and I've managed to add the automated tests to the build script, so they appear as compile errors in the IDE.

I would recommend this book to all developers, especially those who find writing tests tedious or unnecessary, and those who wish they had a better set of tests when modifying code. Though TDD is one of the key techniques used in Agile methodologies, it can be used under any methodology, since it just replaces the developer tests that most developers would like to have anyway (but probably don't).

Highly Recommended.

Buy this book

At Amazon.co.uk
At Amazon.com

Posted by Anthony Williams
[/ reviews /] permanent link
Stumble It! | Submit to Reddit | Submit to DZone

Comment on this post

If you liked this post, why not subscribe to the RSS feed or Follow me on Twitter? You can also subscribe to this blog by email using the form on the left.

More recent entries

Design and Content Copyright © 2005-2025 Just Software Solutions Ltd. All rights reserved. | Privacy Policy