Lean Lean

Ever been confused by people saying "this is Lean" or "that is Lean" or "we should actually be using a cyclometric value-stream set-based burndown kanban for this"? I have, so I thought I'd write a quick pared-down cheat sheet to explain exactly what Lean is. A lean version of Lean, if you will.

At the very least, Lean is seven principles which, we're told, we should apply to making software.

1. Eliminate waste
2. Amplify learning
3. Decide as late as possible
4. Deliver as fast as possible
5. Empower the team
6. Build integrity in
7. See the whole

The first principle is fundamental.

List taken from Lean Software Development.

How to ask an open source project to do something

This isn't exhaustive, but I think there are two ways to ask an open source project to do something:

1. I want X. You should do X.
2. I want X. How can I help do X?

I have no data, but I think that asking the second way is what makes open source actually work.

To do: To dos (Palm Prē)

You might already know that I have a lot of lists on my computer. I may have mentioned once or twice that I have such lists. These lists are connected to a certain popular productivity system which isn't really about productivity and is a little bit like a cult.

I might have also mentioned that I've been longing for a "smart" phone, partly so I can have these lists with me at all times, to clutch at reflexively like some Popish talisman.

Now that I have a Palm Prē I have lists and a smart phone, and yet one does not know the other. I am at a loss as to how to get my lists — line-separated text files on my laptop — onto the Tasks application on the Palm. Even then, once they are on the Palm, I have no idea as to how to get them synchronized with something I can edit from my laptop.

Any ideas?

Palm Prē reflections

I got a Palm Prē yesterday. Here are some initial thoughts.

• I like the feel of the physical device
• The keyboard is small
• Camera is useless for taking photos of receipts
• The gesture UI is great
• The Mail application shows individual emails, rather than GMail-style conversations. Lame.
• I don't know how to get my lists out of text files on my computer and onto the Palm
• I don't know actually know anything about syncing from the Palm
• I still don't regret not getting an iPhone

UDS

I'm back in London after a mammoth two weeks travelling the globe bringing Launchpad joy to its four corners.

First up I went to Mooloolaba, Australia. If you're Australian, you probably know how to pronounce it. If you aren't, you'll probably never get it. Sorry.

I was there with the Canonical Bazaar team and some other Launchpadders, talking about their next few months of development. They are going to be focusing on helping Launchpad and the Ubuntu platform team work on our daily build initiative. Hmm. I really need a place to link to for that last one, don't I?

Mooloolaba is a beautiful place to be in November. If you are thinking of giving me something for Christmas, consider a holiday apartment there.

After Mooloolaba, I crossed the Pacific to reach Dallas, home of the twenty-eight lane highway. I didn't really get into the city that much, but man, UDS was great.

Most of the people there are directly involved in Ubuntu development. It's such a joy to see so many people from all over the world come together to work on Ubuntu, and an honour to think that I have a place in that work.

I spent most of the conference flitting from room to room, going to sessions about the Ubuntu development process, daily builds and the Software Centre. Occasionally, I cheated a bit and went to a random session that interested me. Mostly it was about Quickly.

As a Launchpad developer, one of the most exciting things about this UDS was seeing that Ubuntu developers have started building their own tools around Launchpad using our API. Many of these tools are things we'd love to integrate with the main web app, but many are things that are so Ubuntu policy specific that we're happy to leave them outside. After all, this is exactly

what the API is about.

I did a short plenary session where I hacked up an API script using launchpadlib and demonstrated it live. After the presentation, many people came up to me and started talking about their API-using programs and their experience making them. The amount of interest really surprised me.

I also ran a couple of workshop / discussions. The first was on improving Launchpad for API use, which was a bit disorganized, since I didn't realize I was supposed to be running it. The second was on getting started with Launchpad hacking.

For the "Getting started with Launchpad hacking" session, I passed around a USB stick, and asked the audience for an API within Launchpad to expose. mdz suggested "blueprints", so I went to expose the 'drafter' element of a specification. In front of a room full of people. Sheesh.

If you think pair programming is hard (it is, and if you think it isn't you are either doing it wrong or you have extremely helpful colleagues), programming in front of a room full of people is harder.

Still, we managed to actually expose the API and propose the branch for merging with only a little bit of evil.

The point of the session was to get people set up with Launchpad development environments, to show them how to even begin to expose a method over the API but even more than that, to give people a little push into just giving Launchpad development a try. By blundering my way into a valid patch, I think maybe we succeeded.

Now UDS is over and I'm back in London, jetlagged and exhausted to be sure, but genuinely happy about the plans we have for Launchpad development, and eager to begin to make them happen.

Evil Overlord talks

My "Hack Like an Evil Overlord" talks are now linked from my stuff page.

Tests: Costs and Benefits

I like unit testing a lot. I've recently been thinking about whether it really is everything that advocates like myself make it out to be. I'm still thinking, but I reckon that language has something to do with it, and that I wouldn't like TDD so much if I were writing in Haskell. Maybe.

Anyway, here are the benefits of unit testing, without justification or explanation:

• Easier to maintain code
• Avoiding regressions
• Make API clearer, both by describing it and by encouraging contracts.
• Confidence in changes to code

For new contributors, there are other benefits:

• Confidence in changes to code
• Confidence in the validity of your own patch
• Mechanism for exploring internal system behaviour

Some of the costs are:

• Maintaining tests
• Caring about the performance of tests
• Running the tests
• Debugging tests

For new contributors, there are other costs:

• Finding tests
• Figuring out how to run tests
• Figuring out how to write tests
• Learn unit testing

Is this fair? Is this clear? And exactly where was that post by that guy about unit testing being overrated?

On a half-related and slightly exasperated note, many of the conversations I've been having recently have been about costs and benefits. What happened to doing something because it was the right thing?