Creating Change

March 30th, 2007

on a recent e-mail thread, a friend asked for advice when introducing agile. here’s a cleaned up version of my response to him.

Solve THEIR problems, don’t push your own agenda

if you go to people and tell them agile is the key, they won’t listen to you. instead, go to people and listen to their problems. propose and implement solutions to their biggest and worst one or two. check back with them and make sure they are happy (or at least happier) rinse and repeat. if something in the “agile” toolset doesn’t scratch an itch they have, then you shouldn’t be using it. be flexible in everything except your values. be compromising. if they see you give in to what they suggest, they will be more willing to give in to what you suggest.

obviously a retrospective is a great vehicle for this. if you can get the team as a group to admit to problems that they NOT YOU are worried about, then the solutions you come to will also be owned by the team.

Start with individuals, not the “team”

as an outsider, which we are as consultants, it’s very, very hard to convert an entire team to our way of thinking. it’s hard to know what they all think, and the more you push, the more it becomes YOU vs THEM. not good. it’s much better if you can identify the change agents in the team, find the connectors, the mavens, and the salespeople (see The Tipping Point ) and talk to them. it’s much easier to convince one person, one on one that you have some good ideas, and that you might be able to solve some of their problems. do this first, and instead of 1 vs 10 it becomes 2 vs 9 or even 3 vs 7, MUCH better odds. if you can do this with the most influential people, then convincing the rest of the team almost takes care of itself.

this of course works the other way around, too. the most influential people on the team can easily turn the entire team against you, so you have to make sure that you are listening to them. addressing their problems and concerns, and making them feel heard. this is of course good advice for the whole team, but it’s so much easier when it’s one person at a time, you might as well start there.

Ask for help, and dish out the credit

it’s a funny thing, but when you ask someone for help, you usually get it. and believe me, if you’re trying to introduce agile, you’ll need all the help you can get. the easiest help to get is advice that is asked for one on one. ask your boss what the social makeup of the team is. ask those teammates for advice on what the team needs. ask someone to give a part of a presentation to management.

from their perspective, it’s a great thing to be asked for help. it means the person asking respects your opinion about something. it also means that they now owe you something and you’re less likely to hesitate if you need help from them. it means that you take ownership of the thing that you helped create.

if you can manage to make people look good in exchange for your efforts, not only will you spread out the work, but you’ll win yourself friends.

Read the Secrets of Consulting

‘Nuff said.

Object Mother…in rails?

March 6th, 2007

That’s right, the circa 2000 pattern still makes sense today. Use an “object mother” as a test factory to conveniently create objects for your unit tests to bang against. It will often default values, or have different states in which to create objects. For example, you might have a new_user, as well as a new_superuser and new_guest method all of which return users.

Read about the original pattern

But why, you ask, not just use rails’ fixtures? Glad you asked.

  1. it’s more intuitive and maintainable to setup the data you need right next to the test
  2. it’s easier to create just exactly the objects you need when you have test factory methods

But don’t take my word for it. Let’s look at some code.

First off, what does this look like in ruby? I am creating an “ObjectMother” module, which I then just mixin to my tests. A test might then look like :

  include ObjectMother
 
  def test_delete_project
    project = new_project('foo')
    post :delete, :id => project.id
    assert_raise(ActiveRecord::RecordNotFound) { Tag.find(project.id)}
  end

The magic is in “new_project”. It’s an entirely pragmatic construct. If you pass it a string, it will set everything else to acceptable defaults, and use that string as a name. It looks something like this.

module ObjectMother
  def new_project(options)
    options = {:name => options} if options.is_a? String
    options[:url_name] = options[:name].gsub(/\W/, '') if !options.has_key?(:url_name)
    Project.create!(options)
  end
 
  ...
end

Here in project, it defaults the url_name (which must be unique) from the name you’ve given it. However, you could also create a more custom project by running this :

  new_project(:name => 'garage', :url_name => 'the_garage', :description => 'foo')

This is how it works for projects, but it’s only purpose in life is to make my life easier and reduce the amount of code one has to type or read. So each type of thing it creates works a little bit differently according to our needs
——
h2. A more complicated example

I was playing with ferret last week, and wrote a test that looked like this :

  def test_across_types
    project = new_project('rabbit holes')
    post = new_post(:subject => 'a rabbit has a big head')
    user = new_user(:display_name => 'rabbit head')
 
    @search.string = 'rabbit'
    assert_find [project, post, user]
 
    @search.string = 'rabbit head'
    assert_find [post, user]
  end

My thought process was something along the lines of :

  1. I want to test that my searcher works across types
  2. I need to create a project, post, and user that all have a term in them (in different places)
  3. I want to search for the term, and make sure i get all of them
  4. I want to search for a term that maybe 2 of them have and make sure I only get those 2

Writing the test for this part literally took 30 seconds, I didn’t have to go lookup the fixtures or add a new fixture for my new case. I also didn’t have to remember all the things that it takes to make a valid project or post or user.

Helpful Additions To Test::Unit

March 6th, 2007

Doing a lot of rails work, I’m getting a good feel for testing in ruby and rails. Here are some tricks / snippets I use :

assert_raises takes a string and/or a class

I want to be able to write

one = Project.new('one')
 
projects

I’ve done this a few times, but I think cruisecontrol.rb’s implementation is the most robust :

  def assert_raises(arg1 = nil, arg2 = nil)
    expected_error = arg1.is_a?(Exception) ? arg1 : nil
    expected_class = arg1.is_a?(Class) ? arg1 : nil
    expected_message = arg1.is_a?(String) ? arg1 : arg2
    begin 
      yield
      fail "expected error was not raised"
    rescue Test::Unit::AssertionFailedError
      raise
    rescue => e
      raise if e.message == "expected error was not raised"
      assert_equal(expected_error, e) if expected_error
      assert_equal(expected_class, e.class, "Unexpected error type raised") if expected_class
      assert_equal(expected_message, e.message, "Unexpected error message") if expected_message.is_a? String
      assert_matched(expected_message, e.message, "Unexpected error message") if expected_message.is_a? Regexp
    end
  end

——
h2. assert_equal_sets

In Java, I used to push things into sets and compare them when I didn’t care about order. In ruby, I sometimes use assert_equal_sets. It does a compare of two arrays independent of order. So

  assert_equal_sets [1, 3, 5], [3, 5, 1]   # passes
  assert_equal_sets [2, 3], [3, 4]    # fails

class Array
  def reorder_like!(other)
    tmp = dup
    clear
    other.each {|x| self

——
h2. file_sandbox for testing against the file system

After dragging this code around me for the last 6 or 7 projects I’ve been on, I finally packaged it up as a gem . It lets you write code like :

in_sandbox do |sandbox|
  sandbox.new :file => 'b/a.txt', :with_contents => 'some stuff'
 
  assert_equal 'some_stuff', File.read(sandbox.root + '/b/a.txt')
end

Basically it creates a temporary directory for you to muck about in. After the block is ended (or teardown is called on your test) that directory and everything in it is guaranteed to be cleaned up. It also has a bunch of methods to make file based things easier like creating a file, etc.

Install it with “gem install file_sandbox”

Accessing Private Data in Ruby

January 29th, 2007

Of course that’s how you do it…

user.instance_eval("@password")

Every now and then you really do need to access a private variable and don’t particularly want to change the class. Especially in test code. Maybe it’s a smell, but I’d resorted to reopening classes and adding attr_accessor’s.

Moral issues aside, this is definitely a more elegant way of doing it.

Setting Today in a Test

December 20th, 2006

Ruby is awesome…

  def test_on_weekday
    today_is "May 3, 2006" do
      calendar.add("a call").at(4.pm).on(:saturday)
 
      assert_equal(Time.local(2006, 5, 6, 16),
                 calendar.appointments.first.start)
    end
  end

…playing with code examples for our book.

Stand ups as Huddles

December 20th, 2006

We’ve been talking about stand ups here at ThoughtWorks.

I’m actually not a big fan of the traditional yesterday – today – issues format. I find that too often it becomes a status meeting – this is what I did yesterday, doing more of the same today, and no issues.

Instead of a status meeting, I like to treat it as a planning meeting. I prefer to think of a stand up like a huddle in American football. The point is to focus on today, and figure out a game plan that makes the most sense. Who needs to pair with whom? Who’s tackling what stories?

I find the signal to noise ratio is much higher in the latter format as is the energy. It’s fine to mention anything from yesterday that is especially pertinent or interesting to the team, but I think the focus should be on today.

Effective Writing

December 8th, 2006

Our publishers have given us a deadline of the end of the year to get 60 pages out for DSLs in Ruby. That’s not a lot of time, but honestly probably a really great thing for us. We needed the push.

Putting everything else on hold for the month, I’ve found myself scrambling to find a way to apply all the discipline that I have when programming to writing. It’s hard, and getting started is always the hardest part.

I’ve gone through many days of “working” yet getting nothing done. This is what I’ve learned, it’s working for me, maybe it will work for you :
——
h3. Work top down

I remember outlining when I was writing papers in school. I never particularly cared for it. I could pretty much keep the structure of my paper in my head and just write from that. Turns out that’s not actually true for a book. And it’s even less true when you are writing a book with 4 authors in 3 different timezones.

Get a loose outline for the whole book, and then as you write each chapter, outline that in detail. Work on one chapter at a time.

Question Driven Writing

XP has TDD to keep you honest. If it’s not making a test pass, you should delete it or write a test for it.

In a similar way, why not start a chapter by writing the questions it should answer. If you find yourself writing text that doesn’t answer one of those questions, delete it, or add the question.

Work in Sprints

I find I simply CAN NOT concentrate if I’m online and checking mail and talking to my roomates and answering IM’s… As damaging as switching context is when I’m coding, it’s several times more damaging when I’m writing.

The problem is that there’s always more to learn, so it’s way easy to get distracted. Oh, Joe’s online, let’s see if he knows about declarative programming. Let’s google for metaprogramming. Let’s download rBehave.

Even working on examples can be a rabbit hole. And with no pair to pull me back to what we should be doing, I’ve wasted weeks on not important stuff.

The solution?

Figure out what needs to get done next. Do some outlining or research or write some examples, whatever. Once you’re confident that you have some material to write about, start a sprint.

I’m using 2 hour increments, but I could probably do 3 or 4.

  1. Unplug the wifi, evdo or lan cable.
  2. Take a minute to think about what you’re about to do (call it a mini standup) tell someone if, say your girlfriend’s available
  3. Set your timer for 2 hours and write.

The rules are you have to be making forward progress. If you come up against any hurdles, want to ask someone a question, park it. Write it down on a card or a “todo.txt” file.

What do you do when you write?

DSLs vs. APIs

October 27th, 2006

Ever since Joe, Neal, Zak and I started working on our DSL book, we’ve had an outstanding question that we had no good concise and simple answer for.

How is a DSL different than an API?

We’ve spent hours talking, arguing and asking others how they would answer this question. Still the answers we’ve had so far have been too complicated and didn’t feel “right”, until today.

I just got back from breakfast w/ Rob Mee, and we talked about DSLs among other things. His answer to this question is far too simple, so simple, in fact that I think we might finally have it.

Unlike an API, a DSL has it’s own grammar.

But what if it’s an internal DSL? Well, it still has an implicit grammar over and above its host language grammar.
——
Rob has a background in Linguistics and drew parallels between the difference between Pidgin Languages and Creole Languages

A Pidgin Language is one that forms when adults from 2 disparate languages come into contact and try to communicate. It has a minimal grammar and verb forms. It often follows subject – verb – object order and uses extra words for tenses. There are no native speakers of a Pidgin Language.

However, when adults that speak a Pidgin Language teach it to their children, a funny thing happens : their children add grammar to it. They become native speakers and the language morphs into a Creole Language.

Creole Languages are much richer than their Pidgin parents. It’s possible to more easily express complex concepts in Creole than Pidgin. They have more structure and can be more concise and exact as a result.

Interesting.

(if you’re interested in Pidgin & Creole, Rob recommends The Language Instinct)

Fun with Closures in C# 2.0

June 22nd, 2006

One of my favorite features in C# 2.0 are the anonymous delegates. Your code starts to almost look like ruby :). But hold on, they can be tricky.

Can you find the bug here?

Button[] digits = new Button[] {Zero, One, Two, Three};
for (int i = 0; i

——
Give up?

After executing this code, clicking any button would result in this ClickDigit being called with the value of 4 instead of the appropriate value between 0 and 3.
——
I groaned when I realized what it was. ClickDigit gets called with i in the state it is in when the button gets clicked – not when the event handler was attached.

Once you realize this, it’s very simple to fix it, even if it looks kind of strange.

So it should be :

Button[] digits = new Button[] {Zero, One, Two, Three};
for (int i = 0; i

Google’s Tiny Languages

June 21st, 2006

I am struck by how my friends, my english major, only use a computer for e-mail and myspace friends are unwittingly becoming programmers.

It’s all google’s fault.

They’ve gone and taught my friends some domain specific languages. Any of this look familiar?

chinese near 5503 roosevelt way, seattle

on google maps. Or

dentist appointment in seattle from 4pm to 5pm

on google calendar.

What is this world coming to? And more importantly, if “dentist appointment from 4pm to 5pm” is a DSL, what about the interface that lets you select an appointment over that same time period by dragging and dropping? Where is the line between DSL and UI? Or is it starting to blur a little?