Michael Feathers

Porn for Consultants

I don’t watch much TV, but there’s one show that I’m addicted to. It’s Kitchen Nightmares with Gordon Ramsay. There are two versions of the show, the British version and the American version. The British version is a bit better – it’s not quite as fluffed up, but regardless, both shows are worth a look. In them, Gordon Ramsay, a famous chef, goes to failing restaurants and tries to turn them around in a week. And, the way that he does it is incredible. He walks in, tries out the food, criticizes the hell out of it, and then proceeds to tell everyone on the staff just how insanely bad everything is and precisely how responsible they are for it. He doesn’t mince words either. Often every other word is bleeped. A couple of times, he’s gone to restaurant owners and told them to f--- off. It might just be that that’s how you say “pay attention” in the restaurant trade, but I’m pretty sure that it doesn’t work in software development consulting.

Ramsey has some advantages, as a consultant. Every meal service is a new iteration. He can walk in, teach the staff something, and see immediate consequences. He tears people down and builds them up, as needed, but when he leaves, the restaurant is a bit better off than it was before and people know what the problems are. Ultimately, they have to decide whether they are going to solve them. 

The fact is, this is very much like software development consulting, except for the “rough and tumble” bit. And, that’s why it’s porn to me. I think that ultimately, in the restaurant business, you can get away with a bit more because it’s a less polite industry. It’s seen as blue-collar. People yell at each other to get dishes out of the kitchen. It’s expected. In most software development teams, if anyone raises their voice it’s a big deal. Developers walk eggshells with each other, and it can make communication less direct than it should be. But, really, we need to call each other out when good practice lapses in a team. If we don’t, it’s not politeness; it’s abdication.

Ramsay gets results but sometimes it doesn’t work out. In the British version of the series, he goes back to restaurants he’s visited in the past and sees how they are doing. Some take what they’ve learned and continue to make progress; others fall back on old behaviors. I noticed early on that some teams I work with fall back also, and it led me to take a bit of a different tack than Ramsay takes. The question that I always have in mind when I’m working with people is what they’ll be doing after I’ve left. How do I give them something that they can build on and know whether they will own it. Maybe that’s what politeness is for.

XPDay London

I'll be speaking at XPDay in London this year.  The motto of XPDay is "more than XP, more than one day" and, sure enough, XPDay is being held November 19th and 20th.

The program is very good and I'm disappointed that I won't attend more of it since I'll be doing a class on TDD and a workshop on determining the organizational contexts which help, hinder, and challenge agility.  But, having said that, I am looking forward to the talks/tutorials I will be able to see.. those by Lasse Koskela, Elizabeth Whitworth, Jeff Patton, and Keith Braithwaite.

The TDD class is called TDD: The C++ Variations.  It's going to be a nuts-and-bolts session on making TDD work in C++.  Unfortunately, C++ hasn't received as much attention in the agile community. The class is hands-on, and we'll confront the issues that you run into immediately when you want to want adopt a test-driven approach.

From Objects to Functions in OCaml

I’ve been diving into OCaml recently and I’m using my usual diving board. Whenever I want to learn another programming language, the first thing that I write is an xUnit-style testing framework.

I don’t do it just because I love testing frameworks, although that’s reason enough, I guess – writing one makes learning and working in a new language much more enjoyable. No, I do it because implementing xUnit forces you into the nooks and crannies of a language early. The first thing that you do is look for reflection, exceptions, and object structuring. Once you’ve used those parts in a language, you may not know the best way to do things yet, but you can survive.

So, here's the core of my first-attempt OCaml xUnit – the test_case class:

class virtual test_case test_name =
object(self)
  method set_up = ()
  method tear_down = ()
  method virtual run_test : test_result -> unit
  method run result =
      result#test_started;
      self#set_up;
      try self#run_test result with
        TestFailure message ->
          result#add_failure test_name message;
      self#tear_down
      
end;;

The run method contains a straightforward implementation of the template method design pattern.  In OCaml, virtual means abstract.  The run_test method is implemented in subclasses of test_case.  Any exceptions that are thrown in a test are caught and passed to an instance of a class named test_result.

As it stands, this little xUnit works.  It's functional, but it isn't really functional.  In OCaml, you'd expect to see some functional idioms in use, but it's hard to see where they should be used.  In xUnit tests have state.  They call set_up to create it, and tear_down to get rid of it.  How do you handle state in a functional way?

The typical answer in functional programming is to parameterize.  Imagine that we don't have classes and we want to do everything that test_case run does.  We'd end up with a function that looks something like this:

let run_test setup test_function tear_down result = 
  set_up;
  try test_function result with
    TestFailure message ->
      add_failure result message;
  tear_down

Nice, but look at all of those parameters!  Makes you wish for objects again, doesn't it?

Well, not so fast.  One of the cooler things you can do in functional languages is partial application.  You can create a function that is defined as the application of another function to some subset of its arguments.  So, if I want to have a set of tests that use the same setup and teardown, I can define a new function like this:

let xpath_test = run_test xpath_setup xpath_teardown

If you remember from above, run_test takes four arguments: set_up, tear_down, test_function, and result.  What we've done now is bind xpath_test so that it uses xpath_setup and xpath_teardown any time that it is called.  However, you still have to pass the other two arguments (test_function and result):

xpath_test a_test_function a_result

So, really, you don't need objects for template method-like work in a functional programming language.  But, there is one little problem: state.  When you're working in  an object, you have shared state among your functions by default.  When you working with functions alone, you have to pass state.

Here's how Ounit (a much more functional xUnit ported from Haskell) solves the problem:

let bracket set_up f tear_down () =
  let fixture = set_up () in
    try
      f fixture;
      tear_down fixture
    with e ->
      tear_down fixture;
      raise e

The bracket function assumes that set_up will return a fixture of some sort.  It also assumes that the test function and tear_down will accept the fixture.  It looks a little convoluted, but I suspect that template method looks convoluted to many people also.

I suspect that over time I'll start to see functional solutions from the very beginning, but it's nice to see that the path toward more functional style isn't very rocky.

Hamatai!

I’m back home now.

Last month involved a lot of travel.  I was with a client in Spain, then I was at the JavaZone conference in Oslo, followed by a trip back to the US for SD East, and finally back to Denmark for the JAOO conference. And, as if that wasn’t enough, I made a detour to Oslo on the way back from Denmark just to see a band. 

I know.. traveling specifically to see a band sounds bizarre, but people have been known to travel for football so I don’t think I’m that far nuts. The truth is, though, I’m not alone. The band I went to see is known for inspiring obsessive behavior. Steve Davis, an English snooker champion, blew his prize money in the 80s, getting them to re-form and hold a series of concerts in London.  That's obsessive.. and I think beats out the last minute trip I took from Miami to San Francisco to see them play during their first North American tour back in 2000.

The band's name is Magma, and they're hard to describe.  Take every intense form of music you've ever heard in your life.. avant-garde jazz, modern classical ala Stravinsky and Carl Orff, African-American gospel music, blistering rock and African chant.. undercut it all with furious drumming and distorted bass played at twice the volume you'd expect.. put a choral group on top of it.. and then make it intermittently violent and intensely beautiful, and you've got Magma.  Not everyone's cup of tea, but they are playing tonight and tomorrow night at a jazz festival in Nancy, France, and I kind of wish I was there. :-)

Assorted Links:

MDK Part 3
Kohntarkosz Anteria Extrait 1
Kohntarkosz Anteria Extrait 2
Magma's MySpace Page

What I learned from C that made me a better Pascal programmer

I snuck into programming through the back door. At first I wanted to be an architect, but I went to school in the days before CAD and, well, India Ink and I didn’t get along. You could easily spend hours/days on a drawing and if, at the end, you made one little botch you had to start over.   I think I wanted refactoring before I even knew what it was.

After architecture, I started taking math classes and I considered majoring in math, but it felt a bit selfish to me. I didn’t think that I could feel useful plugging away at theorems. Also, I wasn’t sure I really had the aptitude. I liked math but proof was harder than I expected.

My next stop was engineering. It looked like fun, but I started to have nightmares about designing vacuum cleaners for a living. It's not that I don't like vacuum cleaners, it's just that I don’t have a deep passion for them (applause for the people who do).

It all changed for me when I got a co-op job at a company that was writing demographics software. I worked with a computer running SAS-PC programs, and I became curious about programming.  It looked like fun. I started to learn more and then, with all of the fire of youth, decided that if I was really going to make a career of programming, I had to know that I could really be good at it. I had to know that I could really excel.

How did I convince myself? I decided that I would teach myself C. I’d read that C was the hardest programming language out there, so I figured that, hey, if I could learn C as a first language, by myself, programming might be thing that I should throw myself into. I started writing little graphics programs, displaying the results of formulas I’d read about from chaos theory. It was exasperating but fun. I stayed after work, exploring all of the nuances of C compiler command line. I stumbled through pointers and indirection, manual memory management, and printf debugging. It was hard slogging through alone, but I did it. I convinced myself that I could program.

The next step was to change my major to computer science and start taking classes. My first programming class was Introduction to Programming with Pascal. For a self-taught C programmer, nothing could be more gruesome. You couldn’t just open a file, you had to pass an input or an output parameter to your program. You couldn’t really touch memory, you had all of these little bits of syntax in the way that didn’t seem to map to anything real.

It was hard for me to know what was really happening behind the scenes, and I was a bit shaken by the experience. But, nonetheless, I thrived. I took more courses and I dutifully went to the computer lab every afternoon and logged onto the VAX/VMS operating system(!) and went about my work – until – one day late in the term – I looked at the terminal of the woman next to me and I saw something strange. It was an array subscript out of bounds error.

I’d never seen one before.

After a bit of reflection, I understood why. When you are programming in C, nothing is going to save you. After you spend hours debugging an errant pointer dancing over memory, you just learn not to do that.

These days, I have a greater appreciation for Niklaus Wirth's work (although I don't really have fond memories of Pascal) and I do appreciate it when a language's runtime or static checker lets me know when I've flubbed up in a particularly grievous yet stupid way.  But, after all is said and done, I'm glad that C taught me that lesson. 

Safety is good, but so is the possibility of danger.  It keeps us thinking rigorously, and there's value in that.

 

This blog was inspired by Reginald Braithwaite's Three blog posts I'd love to read (and one that I wouldn't)