Recent Readings

I was an agile coach at Google for 18 months, starting in 2008. I figured I should check out this book and compare notes.

The book is directed specifically at agile coaches: people whose role it is to turn development teams to agile methodologies. The authors are trying to mentor the mostly junior coaches in how to deal with their team. There are three layers of experience: teams have limited knowledge of agile, coaches know agile principles and are passionate about them, but lack skills to transfer their knowledge and enthusiasm to their team, and the authors who have it all.

The authors cover many situations that can occur with teams new to agile and some of the ways to get them past obstacles. In doing so, they often drop into you vs. them language. This emphasises the adversarial aspect of the relationship between team and coach and makes the job of the coach that much harder. Teams can emit enough negative energy on their own without muddying the channel further. Coaches really need to cultivate their sense of being part of their team, not apart from it. Even if the assignment is temporary, for its duration their fate is tied to that of the team.

There is a lot of material for junior coaches dealing with novice teams. One thing that I found missing was more advanced material. Agile books in general are good at bootstrapping a self-adjusting team, saying that over time they will find individually optimal processes. But what are the stumbling blocks of intermediate or advanced teams? What are some other techniques that more experienced coaches use? The basic stuff is great, but more original material would have been even better.

The book uses an interesting device. Most of the book is written in the joined voices of both authors. But every once in a while, one author relates a personal anecdote or opinion. So the text breaks off and the lone author is either offset from the margin or put in a sidebar. So it's always clear who's talking.

The last chapter about self-learning opportunities for coaches was excellent.

Here are some selected useful bits of advice that stuck with me.

During stand up meeting, make sure each team member is reporting to the team and not to one individual in particular. This is not a status reporting meeting but an opportunity for the team members to coordinate their day's work. At Insidr, we have the scrum master take notes during the meeting and it can very easily devolve into each member reporting status to the scrum master, each in turn, while nobody else pays attention. This is the opposite of what the stand up meeting is meant to be.

Have the stand up meeting at the task board, or bring the task board to the stand up meeting. The meeting is more meaningful if the tasks being discussed are right in front of everybody.

Approach reading a book like building a jigsaw puzzle: peruse all the pisces, find the edges, work out the easy parts of the interior, and keep the most difficult pieces for last. When dealing with a book, scan all the headings and illustrations to get the overall message, then read the parts that provide the overall structure, skipping hard passages to focus on breadth over depth, then coming back to parts of interest.

Started reading:	2011-10-27
Finished reading:	2011-11-21

I really liked Uncle Bob's Clean Code, and I thought this would be aimed in the same direction of how to produce code in a way that is enjoyable. But it has more to do with Uncle Bob's vision of software engineering as a profession. He presents the attitudes and behaviors that he feels are part of a professional software engineer's ethos.

One important aspect deals with commitments. They form the basis of the relationship between engineer and client, whether the engineer is a consultant or an employee, in which case the client is the business manager. Commitments create expectations and each side usually understands things differently. A professional understands this potential for misunderstanding and makes sure everyone is on the same page. This includes avoiding to commit to goals that cannot be achieved, and doing everything to deliver on what was committed to. The professional also has a duty to work with the client to find a goal that is achievable and serves the business.

Another important is handling pressure. A professional relies on a set of best practices in his everyday work and they should not abandon them the going gets tough. If these practices represent the best way that the engineer knows how to work, then they should be that much more important when the project is having difficulties.

The book ends with with Uncle Bob's manifesto for his vision of the software craftsmanship movement. When I say I'm a software craftsman, I care mostly about workmanship and a certain creativity. It's more about a state of mind, really. The Software Craftsmanship movement, with capitals, as described by Uncle Bob and others, cares a lot about methods of training and apprenticeships. It's more about external relationships.

Overall, the books has many interesting anecdotes about Uncle Bob and his career, but little that is broadly applicable beyond that.

Started reading:	2011-06-13
Finished reading:	2011-06-29

At work, we use jQuery for client-side logic. Since we don't have a front-end engineer yet, I need to be able to maintain and extend this code. I like the other "... in Action" books and this one has good ratings on Amazon. Plus, I get the PDF of it so I can search through it for specific keywords.

Right off the bat, the introduction to jQuery really helped me make sense of the notation and some of the weird incantations. It also mentioned some DOM navigation methods that I will be able to apply immediately to our codebase to make it a little better.

Started reading:	2011-05-25
Finished reading:	in progress

I've been curious about Hadoop for some time. MapReduce is such an exciting paradigm and I didn't get to do enough of it when I was at Google. I tried to use a 50% off coupon to buy this title directly from the publisher's website, but ended up buying the ebook instead of the paper book. It's great to have the ebook so I can do searches in the text, but I cannot read an entire book on my computer screen; so I had to buy it one more time to get the printed version.

One of the drawbacks of books on bleeding edge technologies is that by the time you read the book, the examples need to be tweaked to get them to work. Things like CLASSPATH have changed and sometimes the interfaces are not exactly the same. In the book, they talk about older Hadoop interfaces that were in use until version 0.18, and newer ones that were introduced in 0.20. They decided to keep all the examples in the old style since all of Hadoop understands them. I'm using version 0.21 to play with it, which is pretty much all moved on to the new interfaces.

A lot of the examples deal more with the details of running a Hadoop MapReduce, and less with powerful ways to use the MapReduce paradigm. Maybe the chapter on "Advanced MapReduce" will fill my need.

Started reading:	2011-03-17
Finished reading:	in progress

Came recommended by Kent Beck. The authors wrote jMock. This books explains how they approach writing tests.

Well worth the read, whether you're new to TDD or if you're a seasoned practitioner. Part I and II lay out how TDD works and the authors' philosophy with regard to writing software. Many other books describe TDD and the authors are candid when it comes to their personal practices. YMMV. Part III is a very comprehensive case study where they use the practices in anger, that is, trying to achieve some goal and not for as a toy exercise. Part IV revisits some of the concepts illustrated in the case study. Part V pays special attention to some advanced concerns when writing tests, such as testing persistence or multithreaded code.

Ever since I began using JUnit, I've been adamant about initializing the fixture in the setUp() method and not in the constructor. Early JUnit would create all test instances before it ran the first one, so you didn't want to reserve any resources in the constructor. I class with 20 tests would reserve and hold 20 resources for the duration of the test run. Instead, you reserve the resource in setUp() and free it in tearDown(). Now, instead of holding up 20 resources, at most one is held at any given time. And the best way to remember to reserve expensive resources in setUp() only is to do all fixture initialization there rather than split it up between constructor and setUp().

So you can imagine my surprise when I see the authors initialize their fixtures in their test class constructors. What are they thinking?!?! I had to go back and write some sample tests using the latest JUnit and print traces in constructors, setUp(), tests, and tearDown() to validate my assumptions. Lo and behold, at some point in time, JUnit got it's act together and now creates test instances as it runs tests, not all of them at the beginning of the test run. For a moment, I was afraid that Grails might leave me stuck in the dark ages of setUp()-only initialization, but I'm safe there too. Not I've got to update my habits.

The sample problem had lots of complexity: GUI, asynchronous communication, Jabber-based RPC, etc. Some of the code transformations are sometimes hard to follow, especially the further you get in the case study and they pick up the pace. Some side-by-side comparisons would have been welcome, but maybe hard to do in the limited space of the book.

The authors used a neat trick to track their development progress through the sample problem. They kept a hand-written list of tasks on a sheet of paper, crossed out items as they completed them, and added tasks as they happened upon them. Here's a snapshot from the somewhere halfway through:

Todo
single item - join, lose without bidding
single item - join, bid & lose
single item - join, bid & win
single item - show price details
multiple items
add new item through the GUI
stop bidding at stop price
translator - invalid message from Auction
translator - incorrect message version
handle XMPException on send

I used a similar technique a long time ago to implement a feature with great success. I'm going to re-introduce it to my toolset going forward.

I really liked the chapter on test data builders. I already grew more comfortable using test helper methods to clarify the text of a given test after reading Gerard Meszaros' xUnit Test Patterns. The builders in this book take it to another level. The authors use builders and Hamcrest matchers to create DSLs that really make tests easy to read and makes their purpose crystal clear. Groovy and Grails already have support for writing builders and I'll have to spend some time adapting the examples in the book to the Groovy way.

Started reading:	2010-12-20
Finished reading:	2011-02-09

We are using Grails at work. I am using this book as a reference, looking up topics as needed and leafing through it to get a general feeling for the language. Groovy is a lot like Ruby, but with a syntax that is much closer to Java.

I was looking up the -p and -n options to write scripts for processing input files, and I was annoyed that there was no exhaustive list of the resources available to my script as it processes lines. The book mentions line, which holds the current line, and count that counts lines read so far, but what else is there? How about the current filename? Or the line number within the current input file? I had to dig through the source code for Groovy to find out that line and count were all that there was.

There is a second edition planned for middle of 2010. You can get early access copies from the publisher, for a price, as part of the Manning Early Access Program.

The chapter on database support via JDBC shows the massive support for database operations using dynamic features of the language and closures.

The support for XML and HTML using builders is also very promising.

Between this book and the online documentation, I have found answers to almost all my questions.

Started reading:	2009-10-22
Finished reading:	2009-11-19

We're using Grails at work. I went through the first chapter and the starting tutorial. I was using Grails 1.1.1, but ran into some snags. The save() method of domain objects didn't work. I downgraded to version 1.1 and it worked fine. I upgraded to version 1.2-M3 (experimental) and it worked, but something failed later on when I introduced a service, as per the example. The section on testing talked about integration tests, but the code samples were for unit tests. The book could have used more proof reading.

Buying the physical book entitled me to download the PDF version for free. That's nice.

It mentioned Guice in passing when talking about dependency injection. I hoped there would be a way to use Guice with Grails. That would have been awesome. But a look at the index and a search through the PDF showed one a single reference to the word "Guice". Too bad. It seems Grails uses Spring internally for its dependency injection needs. It does have an interesting automatic injection mechanism for certain classes. Controllers, for instance, only need to create a variable with a given service's name and it gets injected automagically. It doesn't seem to work for tests, though; I can't ask for a service instance to be injected in my test for the service.

There is a very nice section on testing that shows you how to unit test the various artifacts like domain classes, controllers, services, etc. The examples include mocking. There is also a section on integration tests. I wrote some unit tests and the facilities added to Java's Collections API made creating test data a synch.

There is a long list of plugins for Grails. It would be nice to have a more exhaustive introduction to the major plugins. There is a nice chapter that talks about a few plugins, but it is tied a little too closely to the sample application the authors are building throughout the book. Some would be useful to me, others wouldn't. Other plugins are introduced through other chapters, such as acegi when talking about security. I understand that the list of plugins is ever-changing and that a book cannot really keep up, but I feel like there are gems hidden in there that I am going to miss because of information overload.

Between this book and the online documentation, I have found answers to almost all my questions. I did have to peek at the code on a few occasions.

Started reading:	2009-10-20
Finished reading:	2009-11-19

I hesitated between getting this book or Pragmatic Version Control Using Git, but a colleague recommended against the latter.

I'm not going to read it cover to cover, but it's already been very helpful with sharing branches via an authoritative repository and interacting with Subversion. So far, the explanations are clear and the examples are brief and to the point.

It was very helpful in dealing with Subversion. I'm able to sync up with the Subversion repository at work, work in my Git branches, and commit changes back to the repo, without the rest of the team having to worry about it.

I also tried to keep both the Subversion and Git repos for Dependency Finder up to date, but that has proven too difficult. I wanted to use the Git repo as the canonical code repository and have the Subversion repo mirror it, but I couldn't keep my local Git repository up to snuff on both of them. That's ok, I'll just drop the Subversion support from the project, that's all. :-)

Started reading:	2009-10-14
Finished reading:	2009-10-30

At the suggestion of a colleague, I'm reading Jerry Weinberg.

Like the alternate title says, A Guide to Giving & Getting Advice Successfully, the book is more about human interactions than about the business of consulting. And it is very good.

Weinberg takes us through a stoll across his vast experience as a consultant, sharing bits of wisdom as he goes along. He tries to couch each bit of advice in a catchy slogan, like The Law of Raspberry Jam or The Orange Juice Test. Some of them end up sounding kinda corny: Rudy's Rutabaga Rule.

One of the more interesting ones is The Law of Raspberry Jam: the wider you spread it, the thiner it gets. You can have a lot of influence on one person, or a little influence on lots of people. You cannot have it both way.

Another really interesting one comes in the chapter on pricing yourself. The Second Law of Pricing states that the more they pay you, the more they love you; and that the less they pay you, the less they respect you. I have been thinking for a while now that people care about a thing in proportion to how much they have to pay for it (for a very wide definition of pay). If you give them something for free, they won't really care much for it and will let it wither and die. If they have to spend resources for it, they will look after it much more. It could be a piece of software, or a tool, or a new practice.

Started reading:	2009-02-03
Finished reading:	2009-02-23

A short book that covers the best parts of the language and tries to avoid the more questionable aspects. Too bad it does not look at web programming or Ajax.

This little gem redeemed JavaScript for me. A great, quick read. It really brought in the functional aspects of JavaScript and the focus on closures. It also goes to great pains to differentiate between good features of the language and bad or outright dangerous ones. It also has plenty of railroad diagrams to document precisely the grammar of various statements. These are interesting, though not strictly necessary.

This book really helps you get into the JavaScript spirit of things. When I first approached JavaScript, I was still stuck in the more of object-orientation you find in other major languages, with classes and such. But JavaScript has a rather unique take on objects and it pays to reframe your thinking along its lines of strength. It really clarified closures and the use of functions to control scope for me.

Additional note: the author did a presentation at Google on the contents of this book. See it on YouTube. I'm sitting in the first row. I'm the guy with dark hair and a bald spot on the right.

Started reading:	2009-01-23
Finished reading:	2009-02-03

A horrible book for a horrible language. First, pretty much the entire book is written in passive voice, making it really hard to grok. Second, the author often makes broad sweeping statements but never dive any deeper. Things along the lines of: This bit is quite complicated but can be very powerful, without any further explanation.

Of course, the topic itself, JavaScript, does not help. Everywhere you look, you have to take into account that JavaScript works one way in IE and another everywhere else. Resig gives plenty of code to deal with the differences, but it is not clear if programmers wouldn't be better to use an abstraction framework such as Dojo.

The books has roughly three parts. The first part describes the language itself and it is simply horrendous. Very confusing, the author tries to show everything indiscriminately. The good is lumped in with the bad without enough information for the reader to decide which is which. The second part describes manipulating the DOM. Again, it is horrible. Lots and lots of browser-specific hacks. It would have been better if the author had described one shortcoming and then pointed to a framework that solves it and how. Instead, he keeps writing utility functions and builds his own vocabulary. For one thing, it is more procedural than OO, and it looks hastily put together.

The third part almost redeems the book. It is a series of case studies that show how to do AJAX in various contexts. Here, you get to see all the pieces at work: JavaScript, AJAX, CSS, JSON.

I can only hope that in the years since Resig wrote the book, we've made progress in making JavaScript less horrible to work with.

Additional note: it turns out Resig is the author of jQuery.

Started reading:	2008-11-07
Finished reading:	2009-01-06

I learned about this book while reading Clean Code by Robert C. Martin. Since it is written by Kent Beck, I just had to read it.

This book and Clean Code by Robert C. Martin have a lot in common but address it in different ways. While the later is more practical with lots of examples and case studies, this one reads more like The Book of Five Rings: here's a piece of advice, go think about it carefully.

Started reading:	2008-09-04
Finished reading:	2008-09-12

I like Uncle Bob. He's a good communicator and he is always entertaining. This book repeats a lot of good advice that you can find elsewhere and puts it conveniently under one set of covers.

By pure coincidence, someone suggested I look at Seven Pillars of Pretty Code by Christopher Seiwald, who wrote the Perforce Source Control System. This was at the same time as I was reading chapters 2 and 3 on naming and composing functions. Seiwald favors long functions broken up into blocks, each prefaced with comments. Uncle Bob talks about lots of short methods with meaningful names, alleviating the need for comments. So while I'm reading about writing code in the 21st Century, someone is actually pointing me to this guide to writing code in the 70's.

Uncle Bob missed the boat with this book in at least two regards: he only briefly mentions Dependency Injection and he fails to capitalize on the testing terminology introduced by Gerard Meszaros in xUnit Test Patterns.

Asside from that, it is a great read so far and I highly recommend it to anyone who want to write better code, code that is easier to maintain, code that is more testable.

In one of the case studies, he starts by showing a piece of his code, drawing attention to how nice it is. Well, it wasn't that nice, so I was expecting him to turn around and say something to the tune of: "You thought it was nice, but it is really quite dirty." But he didn't. Instead, he showed the original code, before he had cleaned it up. No doubt, the original code was a disaster and his cleaned up version is far superior, but I think if could have been made even better. Going through all the transformations along with the author was a really nice way of looking at all the tradeoffs as he was making them. The other, lenghtier case study is even better.

I highly recommend this book to anyone who cares about the quality and maintainability of the code they write.

Started reading:	2008-08-18
Finished reading:	2008-09-04

This book seems the be the first one to come out on Guice. It is the best, because it is the only one. Otherwise, it has quite a few shortcomings. For one thing, there is no index, making it impossible to jump ahead to a section that might talk about a particular subject. For instance, I want to know how to Guicify a WebWork application running in Tomcat, but without an index, I cannot figure out where to start looking.

The lack of index proved frustrating again, later, when I wanted to look up something I remembered reading, but couldn't remember which chapter it was in.

Otherwise, it was a good, quick read. The examples were very helpful, if sometimes too simplistic. The descriptions were very focused and really cut to the chase.

And I never did find out how to Guicify a WebWork application running in Tomcat, but the book did cover Struts 2 briefly. I guess I'll have to upgrade if I really want to use Guice.

Started reading:	2008-05-13
Finished reading:	2008-05-23

I'm reading the Pick Axe as part of learning Ruby for my new language for 2008. I'm off to a great start. The language has some really cool features and the author is very engaging.

Ruby's blocks is a very cool feature. And it has -p and -i switches just like Perl! But support for web apps goes back to CGI (at least in this book).

Started reading:	2008-02-19
Finished reading:	2008-03-19

An amazing text on testing. I read the first 200 pages, the narrative, and skimmed the rest of the catalog of patterns. It does a great job of defining a vocabulary for unit testing and really nails down the terminology. The narrative format really brings the language to life, shows how all the terminology fit together very nicely. A must read for anyone doing unit testing with any of the xUnit frameworks.

Started reading:	2007-08-27
Finished reading:	2007-09-12

The entire book can be reduced to two slides: one diagram and one bullet list of pros and cons. The diagram shows up again and again; they use it as a map to the contents, highlighting the current section. Each time, the diagram takes about three quarters of the page. It is not a very busy diagram and if could easily have

So far, it is very repetitive. They keep repeating the same things over and over. They keep promising that topics will be covered in more depth in later chapters, but I am still waiting.

In the end, the whole book could be reduced to that one diagram and a short bullet list of pros and cons. I was pretty disappointed. But if you need to sell a continuous build to someone who is not technical and does not understand programming, maybe this is a book for that.

Started reading:	2007-08-01
Finished reading:	2007-08-14

I needed something to browse on the train while I'm waiting for the latest Harry Potter book to come out: Harry Potter and the Deathly Hallows.

Started reading:	2007-06-25
Finished reading:	2007-07-11

I read the first edition early in 2003 and I really enjoyed it. The chapters on the theory of communication were very thought provoking and resonated well with what I had read about communication from Umberto Eco. At work, our agile user group has been looking for a volunteer to read the second edition and to do a book review, so I volunteered. That's when I learned I would have one week to read a 467-page book and do my review. Somebody wish me luck.

It took me three weeks, but I made it. Cockburn was kind enough to put the new material in separate chapters and highlight those in the margin. Chapter 1 is followed by chapter 1.1 with new additions to the material in chapter 1. So on and so forth for chapters 2, 3, and following. This way, I was able to look at a large part of the new material in time for my one week deadline and still provide a report that was useful. Now that I've gone through all of the book, I can do a more complete report.

The operative word should have been adaptive. The process or methodology must adapt to the team and its environment. This includes the people making up the team but also the cultural and political landscape in which it operates.

Cockburn has two key points. First, there's only us. We're all in this together, including suppliers, customers, management, sponsors, QA, etc. Second, the team must reflect periodically. You won't get it right the first time, or even the second or third for that matter. You must reflect on the current situation and make adjustments as needed. Many small adjustments over time have a better chance of success than one big-bang change.

Back when I first read the book, and this time too, I really liked the early chapters on the nature of communication and what the author calls osmotic communication. It worked very nicely with what I've read on the subject by Umberto Eco and Milan Kundera. These chapters reinforce the idea that we cannot convey a complex system of ideas perfectly in one communication event. We have to establish a dialog, be it with the requirements, the code, partners, etc.

Throughout the book, Cockburn keeps bringing up the concept of Shu-Ha-Ri, three levels of learning common in martial arts. "Shu" is the beginner who is looking for one proven way to get something done. "Ha" is the experienced practioner who is looking to grow their toolkit. "Ri" is the expert who is looking at the underlying principles, where specific techniques don't matter anymore. The author constantly contrasts the needs of Shu-level and Ri-level individuals. We must take it into consideration in our communicatios, with each other and with people outside the team.

Figure 2.1-2 is a very nice illustration of the fractal nature of iterative development. By opposition, figure 5.1-9 is complete crap. There is nothing on the x-axis and the y-axis therefore becomes irrelevant. The slope on the data line is completely artificial and the logarithmic scale on the y-axis is purely for effect. This is pure propaganda and is totally unsupported.

Aside from figure 5.1-9, this is a very insightful book and I highly recommend it.

Started reading:	2007-01-12
Finished reading:	2007-01-31

I borrowed a copy from work to take a quick look. The first 100 pages are a quick walkthrough of the language itself. The next 200 pages cover the extensive libraries and the index is about 50 pages long.

The book gives a brief, if hurried, introduction to Python. If you are already familiar with programming, and specialized scripting languages, this should give you what you need to start writing Python scripts. Like Java, real mastery hinges on thorough knowledge of the libraries.

The language is ugly, like Perl, but has many interesting features. It has slightly more elaborate data structures for quickly organizing data, and support for object-oriented programming is less haphazard. Still, some of the underpinnings are exposed and not always graceful, like prefixing methods with __ to mark them private. It's a step up from Perl, but not what I would call elegant or even readable.

I know there is a third edition out by now. I'm curious as to what's been added since 2001.

Started reading:	2006-10-25
Finished reading:	2006-10-27

I waited two years before writing my comments. I don't remember much anymore.

The book was pretty good, very practical, steeped in the author's extensive experience. The presentation style was very approachable and lively.

Someone once said that Scrum was just the planning game from eXtreme Programming. It definitely is fairly simple to implement. It focuses on the communication between the development team and the project stakeholders and leaves the developers free to work however they see fit.

Started reading:	2006-10-02
Finished reading:	2006-10-11

A really quick read. The agile bias of the authors shows when they limit planning to 3-4 weeks, or put emphasis on people rather than process.

More than two years later, the only thing that really stuck to my mind is that one-on-one meetings with managers should be more about career development than status reporting.

Started reading:	2006-03-14
Finished reading:	2006-03-21

We use WebWork at work and I wanted to learn more. The documentation that ships with WebWork can be spotty, and since it consists largey of an alphabethical dump of their wiki, it is fairly hard to follow beyond the initial tutorial.

Anyone who wants to use WebWork should read this book. It is the best resource on WebWork out there, even though it has quite a few flaws.

It does a pretty good job of covering all aspects of WebWork and all the features it brings to the table. Many of the examples show code one way and then evolve it before your very eyes into a better solution, often more than once. The transitions could use better highlighting, though. I learned a lot about the capabilities of WebWork and it helped change the way I thought about one application I want to migrate from plain JSPs to WebWork.

One big problem is that the framework is still evolving quite a bit. The authors wrote the book mostly for version 2.1 but version 2.2 came out about the same time as the book and contains quite a few deviations. For instance, one of the first things you do is map *.action URLs to the ServletDispatcher servlet, which is deprecated in 2.2. The deprecation notice does say to use FilterDispatcher instead, but its documentation says to map it to * now. After you've read the entire book, you're in a better position to understand what is going on, but it is confusing when you are only trying to get the early examples to work.

The book has numerous typos throughout and the highly didactical tone can sometimes feel condescending.

Started reading:	2006-01-12
Finished reading:	2006-02-13

Very good intro to unit testing. Talks at great length about the need for tests and the advantages of designing for testability. It has a very nice tutorial on using JUnit and even briefly mentions the use of mock objects.

It is filled with very good pieces of advice. Many of them are arranged into catchy mnemonics. But they often feel forced and some are so long that it becomes hard to recall what they stand for. This reminded me of a similar device that I keep hearing: DRY - Don't Repeat Yourself. It's about removing code duplication, but everytime I see "DRY", it takes me a while to remember what it's about. So I try not to rely on mnemonics too much.

Pretty much everything it says I had already gathered from various other sources. Martin Fowler's books, Software Development magazine, Bob Martin's writings, etc. It is nice to have it all neatly summarized in one place, but it was all a little too entry-level for me. I would definitely recommend it to anyone who was not test-infected yet, though.

Very much like the authors' other book, The Pragmatic Programmer. I think DRY more or less originated in that book, actually.

Started reading:	2005-11-28
Finished reading:	2005-11-29

The book was OK. It is kinda strange, the first half is for non-technical people, like business analysts and such, and teaches them to organize tests and test data into tables and HTML pages. Then, about half-way through, it finally starts to address the technical issues regarding how you realize those tables with supporting Java code. The last few chapters go into more details about the architecture of FIT and the flow between some of the pieces. The book talks a lot about FIT and much less about FitNesse.

It so happens that I saw a presentation by Rick Mugridge on 2006 / 02 / 09. He spent most of the time extolling the virtues of testing. I would have liked to get more details about how FIT is implemented and the lifecycle of various objects. I guess it wasn't that kind of talk.

It is not my favorite book of all times, but it is the only one on FIT at this time.

Started reading:	2005-11-26
Finished reading:	2005-12-15

It seems I'm already familiar with most of the advice in this book, but I'm still going to rifle through it, just in case. When I first saw it, when it came out, I thought I already did many of the recommendations and simply disagreed with the others. Maybe it's time I took a better look.

This book came out at just about the same time as Java 1.4. Many of the items could use a refresher to bring them in line with the new language features in Java 1.5.

Started reading:	2005-10-14
Finished reading:	2005-10-18

I remember the first edition being a must-read for anyone doing C++.

I'm starting on a C++ project, so I'm reading this to refresh my memory about all the C++ pitfalls. This new edition has been updated to address today's use of templates, the STL, and design patterns in general. So far, every paragraph reminds me of why I prefer Java. :-)

Template Meta-Programming. Brrr.

Still a must-read for anyone doing C++. Here's a language with a million little gotchas, and they are all documented in this book. No one should be doing C++ without this book by their side.

Started reading:	2005-09-12
Finished reading:	2005-10-14

Quickly read through it, skimming most of the non-puzzle stuff and skipping the language-specific section altogether.

Fine for college grads in their first interviews. The questions were too simple to really assess a candidate to a senior position. Nice sample of interview puzzles, though.

I keep recommending it to people who need to prepare for technical interviews.

Started reading:	2005-07-12
Finished reading:	2005-07-15

Lots of very practical advice on how to take already existing code and bring it under test. The author offers many techniques for minimal code transformations that allow you to write tests against the code. Once the tests are in place, you are in a better position to launch larger refactorings. While the transformations work better on objet-oriented code, many apply just as well to procedural code.

The introduction to test-driven development is very nice. The example feels genuine, not just a contrived example piece of code that bears no relation to your actual code. This one guides you through a few iterations to show how the amount of work and refactoring vary between through them.

The tone tries to remain casual and engaging, but it seemed forced in places. Martin Fowler and Robert C. Martin have had more practice at walking the fine line between humour that helps the medicine go down versus humour that's besides the point. But still, the quality of the advice more than makes up for any stylistic shortfall.

I really liked the notion of effect sketches and feature sketches. They relate strongly to the transitive closures that I compute using Dependency Finder. My tool works automatically and will miss some impacts whereas the author derives his sketches manually. Maybe the tool can help guide the manual process and make sure it covers all dependencies.

Started reading:	2005-02-08
Finished reading:	2005-03-16

eXtreme Programming 2.0.

Actually, it's a complete rewrite of the first edition.

Actually, it's more like reinventing XP. Kent Beck is adjusting XP so we can benefit from his additional five years of XP experience. The first XP was squarely aimed at programmers; this new version should appeal to everyone involved in software development. The practices have been updated: some have been dropped, some are new. He recommends a much more gradual introduction if you want to move to XP, instead of the strong push from the first edition. He is also much more explicit about ways to customize XP to your circumstances.

Like Tom DeMarco's Peopleware and Alistair Cockburn's Agile Software Development, he reminds us that software is written by people. But he goes further, showing how XP brings back humanity to those who practice it.

Still a quick read and very inspirational. Plus, the bibliography at the end has many of my favorite authors and titles.

Started reading:	2004-12-08
Finished reading:	2004-12-18

Really good follow up to Martin Fowler's Refactoring.

Refactorings was about small, self-sufficient transformations. Here, Kerievsky starts composing them together into larger transformations to help you take existing code to, toward, or away from patterns. The goal is not to end up with one pattern or the other, but instead finding ways to improve software little by little. It is the journey that counts, not so much the destination. This book makes a good bridge between agile methods and design patterns, keeping today's work in focus and keeping things simple but not loosing sight of the final goal.

I really liked the reference to design debt. Whenever you take a shortcut during development, you incur design debt. A little debt can help you get things done, but you need to repay it before it becomes unmanageable. Just like a credit card. This metaphor apparently works very well with management.

Started reading:	2004-11-29
Finished reading:	2004-12-08

Two authors for whom I have immense respect and a foreword by Tom DeMarco. I finally got around to reading this one. I delayed because the other XP books already covered the planning game as far as I'd care. But hopefully these authors can make it interesting still.

I was pleasantly surprised that something apparently so simple as the planning game could have almost infinite subtleties. The authors have streamlined it somewhat but the original intent stays. Divide the work into manageable chunks and let technical people make the technical calls and the business people (customer) make the business calls. This is not only when to schedule stories, but when to split them and actually when they are done. Well worth the small investment in time.

Incidentally, I met Kent Beck at a local event the day after I finished reading this book, on 2004-11-17, and I got him to sign my copy.

Update: I met Martin Fowler at a local event on 2010-05-12 and I got him to sign my copy too. Two for two.

Started reading:	2004-11-08
Finished reading:	2004-11-16

The guys from Peopleware are at it again. This time, they tackle the management attitude that plays the ostrich and keeps its head in the sand, denying reality instead of facing it. They are making a case for knowing what risks lie ahead, how to notice them, and how to prepare for their possible occurrence.

In their usual style, the authors keep things light and simple, yet offer quick and easy rules to get you going. The book is peppered with anecdotes taken from their professional experience. You can start applying the advice from the book immediately and get results right away.

Their approach to quantifying risk through simulation has its detractors (see reader comments on Amazon), but I think the very simple act of listings the risks and their associated contingencies (what to do when a risk manifests itself) and mediation (preparation ahead of time) are already a big step forward from mere wishful thinking. It helped me keep some of these risks in mind and stay on the lookout for their manifestation. I, too, would question a proposition that says: _the math for this is too complicated for you, but trust our handy little Excel spreadsheet._ But the book is still very much worth the read and contains a lot of fair advice.

Started reading:	2004-10-14
Finished reading:	2004-10-27

The premise looks tempting, that software engineering should be driven like a craft, where masters lovingly guide and mold their apprentices, passing on their hard-earned experience, relying on their reputation for quality to drive business. It sure looks nice and romantic, viewed from here. But how realistic is it, really? How much of it is just blindly idealizing of the past?

The author points out that software development needs to cultivate a constant state of learning, where practitioners can continually better themselves. We must also take pride in our work and receive rewards commensurate with our abilities. If a star developer is ten times as productive as an average one, shouldn't their compensation plan reflect that too? The author suggests a craftsmanship model, complete with apprentices, journeymen, and master craftsmen as the way to get there. While the goal is noble, I'm not fully convinced that the path he chose is really the one to follow.

This book has a lot of thought provoking ideas and everyone who considers making a career developing software should read it. I once heard someone saying that everyone should read Kent Beck's book on eXtreme Programming, even if they don't agree with XP. It is a quick read and filled with very sound advice, regardless of whether or not you practice XP (e.g., test-driven development, refactoring, continuous integration). This book is like that. Even with a development philosophy aligned with SEI's CMM, your experts should still do presentations or publish articles to spread their knowledge and your developers should be given opportunities to develop their skills further.

Started reading:	2004-05-21
Finished reading:	2004-06-04

Magnus opus on enterprise software and multi-tiered applications with object-relational mapping layers.

Started reading:	2004-05-10
Finished reading:	2004-05-20

I'm taking a second, deeper look at it. I borrowed a copy from a coworker and I read it through this time.

Great, short intro to minimalist UML. This is followed by a quick review of OOD principles; they are covered at greater length in is other book: "Agile Software Development: Principles, Patterns, and Practices", but the quick review is still good. He ties it all together with two case studies, including his now recurring SMC compiler.

Quick to read, loads of good stuff. Lots of editing mistakes also, they should hire a new editor. He also suggests people use JDepend when he talks about dependency management. I beg to differ. People should be using Dependency Finder instead. :-)

Started reading:	2004-02-23
Finished reading:	2004-03-02

A great essay by expert presenter Edward Tufte. It's a quick read (27 pages) and includes the Columbia Accident Investigation Board criticism of NASA and its contractors' over-reliance on PowerPoint. You may think the author goes over the top at times, but the book is still filled with good advice for doing good presentations: focus on content and clearly show your data. The message you want to convey is in the narrative tying the bullet points, not in the bullets themselves.

Started reading:	2004-01-13
Finished reading:	2004-01-13

Good, practical guide for understanding how regular expressions work without going into the deep stuff about automata theory. I was hoping for more practical coverage of different syntaxes and more examples rewritten in each, especially Emacs. Still, quite good about regular expressions in general. But if you want to learn a particular flavor, you will need something more focused on that language or tool.

There is a more recent edition published in 2002 with 150 additional pages that I haven't looked at.

Started reading:	2003-11-04
Finished reading:	2003-11-05

Good introduction to design patterns and some of the higher principles of object-oriented design. Follows my own personal discovery of the fundamental principle of isolating change. I discovered it while I was reading Wolfgang Pree's Design Patterns for Object-Oriented Software Development, right after I had read the Gang of Four book in 1994.

A good book for junior developers, but I am way beyond it by now.

Started reading:	2003-09-11
Finished reading:	2003-09-12

Great textbook, with all the really important principles when designing object-oriented software. The tone is sometimes a little too facetious to my taste, but it is an easy read and well worth it.

The first few sections deal with the core principles of OO, such as encapsulation and polymorphism and substitutability and so forth. The style is very lively and concise and to the point, with carefully selected examples. Mostly in Java, but the principles apply across the board.

Started reading:	2003-09-03
Finished reading:	2003-10-20

I've been working on a "UML Lite" presentation to introduce coworkers to UML. I need it no longer; I can just point them to this book. I browsed through it at the bookstore and it hits the spot with good coverage of essential UML notation an also pointing out what is "nice, but I've never had to use it, so don't bother."

I already have a whole shelf of UML books and I already know what minimal subset I really need, so I didn't bother to buy the book. But if I had to recommend only one UML book, I'd be torn between Martin Fowler's UML Distilled and this one.

Started reading:	not started
Finished reading:

I good book on how to monitor your process and track that your improvements are paying off (or not). Filled with examples drawn from projects at Hewlett-Packard.

Started reading:	2003-09-01
Finished reading:	2003-09-05