Kickoff Meeting

Introductions: Does everyone know everyone else?
Ice-breaker Question: What do you want to get out of this Study Group?

Time: How long per meeting?
Location: Where can we have our meetings?
Frequency: Shall we meet every 1 or 2 weeks?
Pace: How many pages per meeting? How much time per reading? Do we want to be speedy to get through the material or do we want to go deep?
Focus: To what extent do we want to stick to the text of the reading during our meeting?
Expectations: Is it okay to come to the meeting if you haven’t completed the reading?
Roles: Shall we choose to follow the suggested roles?

Meeting One

Assigned Reading: Preface, Introduction, and Part I (Chapters 1-5).
Assigned Roles: Everyone will take on the role of Discussion Director and Technical Vocabulary Enricher.

Opening questions:

• Does it make sense to create locked down APIs? For example, final classes and concrete classes hidden behind factories?
• How does duplicate code affect our ability to preserve existing behavior? To add new behavior?
• What dependencies in our current code base are going to give us the most problems?

Technical vocabulary:

• Legacy Code (xvi)
• Edit and Pray (9)
• Unit Test (14)
• The Legacy Code Change Algorithm (18)
• Sensing and Separation (21)
• Seams (30)
• Mock Objects (47)

Meeting Two

Assigned Reading: Chapter 6: I Don’t Have Much Time and I have to Change It and Chapter 7: It Takes Forever to Make a Change.
Assigned Roles: Everyone will take on the role of Discussion Director and Technical Vocabulary Enricher.

Opening questions:

• Does it make sense to create a Sprout Method or a Sprout Class even when doing so degrades the design?

Technical vocabulary:

• Sprout Method (59)
• Sprout Class (63)
• Wrap Method (67)
• Wrap Class (71)

Meeting Three

Assigned Reading: Chapter 9: I Can’t Get This Class into a Test Harness. Note: we are skipping Chapter 8: How Do I Add a Feature?.

Assigned Roles: Everyone will take on the role of Discussion Director and Technical Vocabulary Enricher.

Opening questions:

• How to decide between using Extract Interface and Extract Implementor?
• Have you ever used the Null Object Pattern? If so, could you illustrate with code or on the whiteboard?
• Is there any reason to use a Singleton?

Technical vocabulary:

• Construction Test (107)
• Pass Null (111)

Technical vocabulary (Dependency-Breaking Techniques):

• Extract Interface (362)
• Parameterize Constructor (379)
• Subclass and Override Method (401)

Meeting Four

Assigned Reading: None.
Assigned Roles: Rick and Igor will take on the role of Code Connector. The plan is to (1) find some code that was recently changed without using techniques from Working Effectively with Legacy Code; (2) bring the original code to our meeting; and (3) work through the same change using techniques from Working Effectively with Legacy Code.

Meeting Five

Assigned Reading: Chapter 10: I Can’t Run This Method in a Test Harness and Chapter 11: I Need to Make a Change. What Methods Should I Test?
Assigned Roles: Everyone will take on the role of Discussion Director and Technical Vocabulary Enricher.

Opening questions:

• Has anyone caught themselves doing anything differently because of what we’ve learned so far?
• Does adherence to the Single Responsibility Principle affect testability?
• Is anyone familiar with the Command/Query Separation design principle? If so, could you explain it to the group?
• What is Michael Feathers advice on testing private methods?

Technical vocabulary:

• Skin and Wrap the API (205)
• Lean on the Compiler (315)

Technical vocabulary (Dependency-Breaking Techniques):

• Adapt Parameter (326)
• Expose Static Method (345)

As a group we all felt that the techniques in Chapter 11 were overkill. Rather than discuss that chapter we chose to create a mindmap that captured the costs and benefits of unit testing.

I find myself having huge arguments with someone at work about how to write unit tests. In particular, things like having ifs and loops in tests. I am wondering if you could send me resources about the format of writing unit tests.

The definitive resource is xUnit Test Patterns: Refactoring Test Code by Gerard Meszaros. I’ve often used the book to influence people: if you don’t agree right now I will club you with this book that I’m holding. Kidding.

Most of the book is online. In the part of the book that describes test smells, Meszaros calls out Conditional Test Logic as a code test smell. There is a section of the Result Verification chapter that describes how to Avoid Conditional Test Logic.

I prefer to write test code that is straight line code: no conditional logic whatsoever. I suggest you adopt this guideline and see how it works for you. I would be interested in seeing any of your tests where you felt that conditional logic was needed.

I’ve noticed that not everyone I pair with uses Eclipse like I do. So I share what I know whenever I pair. In return I’m always picking up new shortcuts, techniques, and tricks.

If you use Eclipse and you don’t have a pairing partner to teach you shortcuts, techniques, and tricks then you might want to look at Eclipse on E. I highly recommend it.

Here is the list of stories that I’m using as a guide:

• As a developer I need to run all the unit tests before checking in.
• As a developer I need to understand where unit testing fits into my day-to-day work.
• As a developer I need to know what counts as a unit test.
• As a developer I need some reference tests and example tests to get me started.
• As a developer I need to understand what tools to use and how to use them.
• As a developer I need to see code coverage for my unit tests.
• As a build support person I need to configure the build to run all the unit tests.
• As a development manager I need to see the that unit tests are being created.
• As a developer or a development manager I need to see when a build has a failing unit test.

When my kids were in middle school they learned a technique for reading and discussing a book called a Literature Circle. They taught me the technique and I’ve used it to create a study group work agreement that I’d like to share. This particular work agreement was for a study group that was reading Working Effectively with Legacy Code by Michael Feathers. Feel free to adapt it for your own study group.

Study Group Work Agreement

All meetings will be scheduled for Tuesdays from 12:30 to 2:00. During the first 30 minutes we will eat lunch together. All members of the Study Group are expected to be present by 1:00. If we all arrive earlier we may choose to start the formal part of the meeting prior to 1:00.

To amplify our effectiveness we have chosen to assign the following roles: Discussion Director, Code Connector, Key Concept Illustrator, and Technical Vocabulary Enricher. Roles will be rotated each meeting and may be assigned to more than one participant. We won’t be assigning the typical meeting roles of Facilitator, Timekeeper, and Scribe—it is everyone’s responsibility to discuss the material in a respectful and timely manner.

As Discussion Director your responsibility is to develop a list of questions that your group might want to discuss about the material. Don’t worry about the small details: your task is to help the group talk over the big ideas in the material and share their thoughts. You are expected to post your questions to the study group wiki.

As Code Connector your responsibility is to choose one or more examples of code from your respective project that relates to the material. The Code Connector is also responsible for making positive changes to their project code base using techniques from the material just covered and to present their results at the next meeting.

As Key Concept Illustrator your responsibility is to choose a few special sections of the material to talk over. The idea is to help members of the group remember one or more the important concepts from the material. Once you have made your choices decide how to share the material. You might draw a UML diagram on a white board or tell a relevant story from your own work experience.

As Technical Vocabulary Enricher your responsibility is to be on the lookout for especially important technical words that your group needs to understand such as the Expose Static Method dependency breaking technique. Other examples from Working Effectively with Legacy Code are Sprout Method and Effect Sketches.

In addition to these roles you may also want to assign the role of Snack Supplier. As Snack Supplier your responsibility is to provide your study group members with a small inexpensive snack. For example, during the study group pilot the members of the study group were treated to Maple Syrup Pie and Lindt chocolates.

Further Reading

Fearless Change: Patterns for Introducing New Ideas by Mary Lynn Manns and Linda Rising
Pools of Insight: A Pattern Language for Study Groups by Joshua Kerievsky

The two definitions that I always share with any team that I’m coaching are from Michael Feathers, A Set of Unit Testing Rules, and Mike Hill, They’re Called Microtests.

Please be patient while I transfer my old blog posts.

The code retreat started at 8:30am, bright and early, on Saturday, August 8. The retreat was hosted by Mike DiBernardo at the PlateSpin office and led by Joe (J.B.) Rainsberger and Corey Haines.

Corey needed a place to stay in Toronto so I offered him a place chez moi (lots of room because the rest of my family was, naturally, at the cottage swimming in the pristine lake). Early Saturday morning Corey and I took the Red Rocket from my place in Kensington Market to Platespin.

After some bagels and coffee, Corey and Joe introduced us participants to the structure of the code retreat: work in focused sessions of 45 minutes; use Java because it is a straight forward language that most everyone understands; develop the code in pairs (or triples); switch pairs after each session; pick at least one thing as the learning objective for each session; and, finally, throw the code away after each session.

What? Throw away the code after each session? Delete the code from version control too?

Yep. I found it quite difficult to throw away the first session’s code. However, by the end of the code retreat I was happily throwing away my code.

The goal of a code retreat is to practice programming rather than to accomplish a programming task. The structure of the code retreat cleverly supported this goal in the following ways:

1. Starting as 8:30 in the morning on a summer Saturday guarantees only keen participants who wanted to learn;
2. 45 minutes is too short to complete an implementation of Conways’s Game of Life;
3. While one participant characterized Java as a “baby” language, I think the choice was a good one because we didn’t spend a whole lot of time getting past basic understanding which we might have done had we chosen some other language;
4. Pairing and frequent pair switching are practices that emphasise learning rather than immediate productivity;
5. Because every pair was asked to choose one learning goal for each session the programming in each session felt like deliberate practice;
6. Throwing away the code each time was liberating because I could start a session with a new pair without either one of us having to understand the code that we had just written in the previous session.

Here are some of the deliberate learning goals that my pairs and I chose: don’t use if statements, work inside out by implementing the survival rules for a single cell, write tests using mock objects, and work outside in by writing tests using a DSL to describe the transition from one generation to the next.

Most of the code that I wrote with my pair was awkward and not worth keeping. But that is okay. As Chad Fowler writes in his book, The Passionate Programmer, if I sit down to practice coding and nothing but elegant code comes out, I’m probably sitting near the “center” of my current capabilities instead of the edges, where a good practice session should place me.

The code retreat reminded me how important it is to make time for deliberate practice. That is, make time where it is okay to ignore the strong pull of completing tasks and instead give myself a chance to experiment, learn, and practice my craft.

Those books will have to wait because the O’Reilly book that I’m reading right now is Masterminds of Programming. I want to share something that Tom Love wrote on page 248:

I just handed out to some of my friends this week a big pile of buttons with the word REQUIREMENTS and a red slash through it like a European road sign. On the back of the button are 14 acceptable alternatives to that word. Lots of discussions go on between individuals or between groups of the form of “I couldn’t do this work because you didn’t give me the requirements yet,” or “We need to have a group of people that goes out and gathers the requirements for this new system.”

The term is simply too imprecise. You need to have more precise terms as an alternative. On a big project that I’ve been involved in we have imposed a requirements tax. If anybody uses the word “requirements” standalone, they have to add $2.00 to the entertainment fund. If they want to talk about use cases, or if they want to talk about story cards, or they want to talk about performance metrics, or they want to talk about business cases or business process models, those are all acceptable terms. They don’t incur a tax, because now if you say, “I need to have the use cases or the functional specification, or a mockup of the application that needs to be developed,” that’s a precise request.

Let it be known that I will no longer use the word “requirements” standalone. If you catch me, I’ll buy you a beer. Now if you use the word “requirements” standalone, I’m likely to just get angry. Dear reader, you have been warned.

I quite like JUnit assertThat() syntax. I wanted to write this test assertion:

assertThat(sut.collapse(rawResults),
    hasItems(expectedBloodPressure_1, expectedBloodPressure_2));

However, the test assertion failed to work when I first executed my test because I needed an equals() method on the Result class that treated Result like a value object. That is, I wanted to test for equality based on the values of all the Result fields. Without thinking through the consequences, I added this method:

public boolean equals(Object obj) {
  return EqualsBuilder.reflectionEquals(this, obj);
}

Nice. Using the Apache Commons EqualsBuilder.reflectionEquals() method was simple and clear.

End of story. New code tested with an expressive and easy to write unit test. Not quite.

In the same application, during an overnight process that synchronizes changes from a data warehouse, new results are extracted, transformed, and loaded into the application.

I was doing some performance analysis to try to speed up this process and I noticed that most of the time was spent talking to the data warehouse. No surprise there. I scanned down to locate the first method that was not in the JDBC driver or in the JDBC library and found the equals() method on Result. It was being called over 700,000 times. What had previously been a super fast address comparison was now a reflection based equals. Yikes.

Clearly, adding an equals() method to make test writing easier was a bad idea. Gerard Meszaros categorizes this smell as a special case of Test Logic in Production that he has named Equality Pollution.

So, what did I learn? One, no test logic in production code. Two, never do performance tuning without a tool that lets you see what is actually going on.