The Spec
The Language
The Practice
The Books

Book Reviews

Extreme Programming Explained
Test-Driven Development
eXtreme .NET
Pragmatic Unit Testing In C# With NUnit
Agile Software Development with Scrum


Extreme Programming Explained

This was probably one of the single most influential books I have read about programming. This is the second edition of the book but it provides even more excelent advice than the first. Both books are good to read, but I suggest getting this one since it actually contains the lessons learned after five years of use. Extreme Programming is extreme in that it turns the Software Engineering world upside-down compared to what it was previously. One think that makes Kent's advice remarkable is that he recommends things that have worked in actual practice. In the software world, I often feel like some things touted as "Best Practice" haven't really been well tested. I think that this shows that Kent has a gift for leading. This probably has to do with the influence of the patterns movement in software which requires that the practice be taken from actual practice. This first edition of the book convinced me to completely change how I make software and if you try it, you may change as well. This was a great companion to "Planning Extreme Programming", "Extreme Programming Installed" and "Test-Driven Development".

Once again, Kent Beck has written an extremely helpful tool for serious software engineers. TDD proposes that we follow two simple rules. This book helps to describe, demonstrate and teach the kinds of complex behavior that results.

If you don't think you are quite ready to start practicing eXtreme Programming, the practice that this book explains may be the best way to start.

Test-Driven Development has challenged my core concepts of software engineering by encouraging me to attempt something that seems simple but that actually turns out to be a discipline that even the masters sometime fail to live up to.

Because the practice of test-driven development is such a fundamental shift in how to make software, I find myself expecting far more from this little book than it can logically provide. This isn't to say that it isn't beneficial, it's just that test-driven development turns the world of software development upside down. As a result, many proposed behaviors and common tools are not prepared to help me make the shift. I find myself expecting this book to give me all of the answers. Sometimes it doesn't.

This book is weak on some important TDD subjects such as Mock Objects and Customer Tests, but, it provides excellent coverage of why TDD helps the software process. It does a great job of provideing practical examples. My favorite part of the book, and the part I find myself refering back to, are the patterns that it catalogs. Each time I re-read them something new seems to catch my attention.

The examples in the book are in Python and Java, but as a C# and JavaScript programmer, I didn't find this to pose a problem. The book covered the concept of influence diagrams which helped me to see more clearly the downward or upward spirals that the simple development behaviors that we practice can put us into.


eXtreme .NET

There are many books available about extreme programming and many available about Microsoft .NET. This book is one of the few that explains ways in which both can be present on one project team.

One of the things that I got from this book that I didn't get from other books is a good example of how to break a story down into tasks that take only minutes. That is one of the common themes in this book: tasks should be broken down into small steps.

Another valuable think I got from this book that I didn't get from others is some detailed examples of testing GUI interfaces in C# using reflection. This sells the book for me because testing GUIs in the .NET Framework has always been a sticking point to me.

It is my opinion, at this time, that this book does not demonstrate the most effective way to do eXtreme Programming on .NET. Many times there were examples in which many tests were developed at once before the tests were run. To better keep with the idea of small steps, and to provide easier examples, I think it would have been better to run NUnit between every line of assertion code. Also, TDD recommends that all duplication be removed after the tests pass every time. The author actually appeared to be discouraging this practice by saying that it could be a waste of time. I have found that the opposite is true; however. In fact, I believe that all software development is the relentless pursuit of clearity afforded by the removal of all redundancy.

Also, the author does not appear to have had any experience in the realm of dynamic languages. The practice of extreme programming really grew out of the Smalltalk community. Smalltalk is a dynamic language. I think that attacking this issue of dynamic language use in regard to the .NET Framework would prove to be an even more productive thing.

The examples in this book were all in C#. The book was written during the .NET Framework 1.1 timeframe, but it makes clear reference to the 2.0 Framework and tools as well.


Pragmatic Unit Testing In C# With NUnit

One of the things that I truly enjoyed about this book was how easy it was to read. The subject is not necessarily the easiest one to make enjoyable, but these authors have successfully done it.

The first chapter contains one of the best arguements, outside of test-driven development, for creating unit tests as a developer. It addresses most of the excuses I've heard from developers and really communicates the value and importance to developers directly. One very convincing argument that they use is that we, as developers, are being paid to create working code, not just code. Because it is a fact that any change to the code could brake existing code elsewhere, makes it clear that without re-running tests after each change puts the developer at risk of having deployed a bug without knowing it.

This book also provides thinking tools for determining what to test and encourages you to practice doing it by providing exersizes. This book really got me thinking about how much nicer it is to have a set of tests that must be made rather than a list of vague requirements. If only our users would provide us tests instead of dreams alone.

This book really exposed my lack of testing. I have been doing test-driven development for years now, but this book made it clear that I was missing some very important tests. I realized that increasing my tests should directly affect the amount of time I spend confused as I attempt to debug a program.

The examples in this book, as the title says, are in C#. This isn't that far from JavaScript, but really the book explained many things that were important no matter what language you use. It did discuss mock objects better than most books on test-driven development, but in JavaScript the concerns we have about mocking objects are usually far lower than when using a static language like C#.


Agile Software Development with Scrum

When I first heard about eXtreme Programming, I wanted to try it to see if it would work like its' creators claimed. It did. But then I had the problem of trying to explain it to those who weren't sure they wanted to try it. I guess I had been feeling the problems that agile software development solves for quite a while before I tried an agile method, but others seem a bit less concerned.

This effort to explain the "Why's" of agile led me to this book.

This book does an excellent job of explaining why agile works from the perspective of other disciplines that work the same way. It tells the author's story, about how he used to develop methodology software tools that he couldn't get to work for his own company. This led him to find a better way of developing software. The method he helped to invent was Scrum.

This book adequately describes how to set up a Scrum process for your team, but it also describes the philosophy behind agile methods in general. My favorite chapter is chapter 5. I have read parts of that chapter over and over again. I describes the problem of noise in a process. If there's too much variance between instances of the "process" then it isn’t well defined enough to use a planned approach to development. Instead, an empirical approach should be taken. This allows the process to change based on feedback.

The discussion of the value of a burn-down chart for monitoring the process was also very helpful. If you are having software project problems, I highly recommend that you get this book and read it.