Just Ship, Baby
Kent Beck, Three Rivers
Institute
Abstract: One of the beauties of the practices of Extreme Programming is that they provide a stable strap to hang onto when everything around you is swaying. The attraction of the practices can also become a trap, though. Shipping software is the goal, and the practices are a means to an end. The focus on shipping is no excuse for cutting corners, but perfect adherence to the practices is no excuse for not shipping.
Al Davis, the slick-haired general manager of the Oakland Raiders American football team, coined the phrase, “Just win, baby!” He wanted his teams to do whatever it took to win. If your game wasn’t pretty but you won, that was a whole lot better than losing beautifully.
Taken as a shallow statement, “Just win, baby,” is stupid and counter-productive. If a player says, “I don’t need to train hard, I’m winning,” losing is not far in the future. Cheating, also, may enhance winning in the short term but is actually a losing strategy. What if Al Davis, though, whatever you might think of his coiffure and business practices, is not actually a shallow man? What if, “Just win, baby,” isn’t a shallow statement?
In American football, as in many endeavors, there are many factors competing for attention. A player has to prepare physically and mentally, prepare to play with his team, lead other players when necessary, and handle what is often a complicated personal and financial life. Coaches and general managers, too, have a host of problems to solve. “Just win, baby,” is a beautiful statement in the midst of such a complicated swirl. It reminds each individual that they need to focus their efforts on what they can control, directed towards winning games. It reminds the organization as a whole that even in the middle of the inevitable conflicts and disagreements that everybody actually wants the same thing—to win.
I’ve been frustrated by my inability to capitalize on the success of JUnit. Since Erich and I wrote JUnit, it has been clear that folks using it to write and run tests could (and have) created tremendous value by reducing debugging time and improving design. Until my recent test-driven development book, though, I had not booked a dime in JUnit-related revenue.
Finally, a series of intellectual and emotional prods gave me the germ of an idea for how to simultaneously make JUnit testing more valuable, encourage even more testing, and create a revenue stream. Armed with my comprehensive knowledge of Extreme Programming, I immediately started by writing a handful of stories, then created a test package to write the first test for the first story.
I would begin with an Eclipse plug-in. For six or eight hours spread over the next few weeks I struggled to get the first test written and running. Writing tests for Eclipse plug-ins is not trivial, so it’s not surprising I had some trouble. I just kept bashing at the problems, trying to get that first test to run cleanly. It is also not surprising that I got discouraged and found other things to do.
So, the situation was perfectly understandable, but I still didn’t have any software. As with any speculative idea, the chances that this one will actually work out are slim, but without having anything running, the chances are zero. In six or eight hours of solid programming time, I can still make significant progress. If I’d just written some stuff and verified it by hand, I would probably have the final answer to whether my idea is actually worth money by now. Instead, all I have is a complicated test that doesn’t work, a pile of frustration, eight fewer hours in my life, and the motivation to write another essay.
Reflecting on my emotional state while I was stuck I can see clearly now that a big part of my problem was that I was afraid of the answer I would receive upon getting something done. What if, after seven years of struggle with trying to create a JUnit business, I finally had the best JUnit business idea I’d ever have and it still wasn’t good enough? I didn’t (still don’t) want to consider that possibility. The choice between having to confront my own fallibility and following Da Roolz was easy—make that dang test work because after all that’s the best way to write software.
I’ve sneering dubbed this philosophy “Rules-First Programming.” I hope by naming this demon I’ll have power over him the next time he comes to sit on my shoulder. When doing things right becomes more important than doing things at all, I hope to recognize his peculiar smell, an acrid mixture of frustration, sanctimony, cowardice. “Rules First Programming,” I will say, “you better go sit on some other fool’s shoulder today because today I am going to ship.”
I had an idea for another little tool yesterday. I wrote it without any tests, just to remind myself that I could still program without a net if I had to. I really didn’t like the feeling of not having any tests, especially when the algorithm got hairy. I’m not sure my code works in all cases. But you know what? I shipped. Turns out it isn’t that cool of an idea, and I’ll drop it. Total cost for that answer—3 hours.
My fear in writing this is that folks will take this as
an excuse
not to skip the hard practices in XP (you know, the ones about having
the courage to reveal your own weaknesses and relating to other people
as people). Those skills meet real social and technical needs in
development. Better skills are insurance for when development gets
hard. But lack of skills is no excuse for lack of progress. You get
paid to write programs. There are better ways and worse ways to write
programs. If right now isn't a good time to apply the better ways, you
are still getting paid to write programs.
Feeling grumpy? Test suite takes an hour? Can’t find a customer? Keep going. Just ship, baby. Today. Tomorrow, get some rest, tune your tests, and find a customer who’ll trade some scope decisions for a good lunch. Today, though, just ship, baby.