Speaking

Call for Presentations: Agile 2008

Brad Wilson — Sun, 11 Nov 2007 08:58:00 GMT

Mitch has posted the Call for Presentations for Agile 2008 in Toronto next summer.

I went to Agile 2006, mostly because I was presenting (and there, mostly because Mitch came in at the 11th hour and shepherded the process along). While I sincerely enjoyed presenting, many of us lamented that something seemed to be missing from the conference. Peter summed it up best by saying that the soul -- the Zen -- of agility seemed to be missing. Everybody was talking about the mechanics, but nobody was talking about the organics.

I didn't go to Agile 2007, partly because of that and partly because I was "saving" up my big trip for the PDC that never materialized. I'm thinking about trying to create a talk about agile philosophy for this year, but I'm not quite sure what I want to say. This blog post by Jonathan Edwards about Beautiful Code has been stewing in my brain for several months now...

p&p Summit, Redmond WA, Nov 5-9

Brad Wilson — Sat, 20 Oct 2007 18:27:00 GMT

It's hard to believe that another p&p Summit is almost here... the time has really flown by. This year I'll be co-presenting twice. The line-up of keynote talks looks positively awesome this year! (Despite Scott Hansleman's protestations to the contrary, he does belong in that group of intelligent and talented people. ;)

The first talk, "Yet another agile talk on agility", is one where Peter and I will answer questions from the audience about our experiences running agile teams, inside and outside of Microsoft. We run the talk just like an agile project, a technique that I first saw used by Brian Button. You start by creating an initial backlog (i.e., people ask questions and you write them down), then you go through an iterative stack-ranking and execution (i.e., answer them) process with time-boxed iterations (i.e., 5 minutes). It's pretty interesting process and never yields the same talk twice. It's also awesome in its ability to require no prepartion. ;)

The second talk, "Dependency Injection Frameworks", is one where Scott and I will talk about the work we've done evolving ObjectBuilder 2.0, as well as some sample containers that we have on the ObjectBuilder CodePlex project space. A lot of the work there has come from real container needs in the wild, and some of the concerns about the complicated architecture of ObjectBuilder 1.0 have been addressed. In addition to our new containers and new architecture, we'll show off some of the new core features we've added, including a lightweight version of the CAB EventBroker and a method-interception system modeled after Enterprise Library's Policy Injection App Block.

I'm trying to make a commitment to be there all through the first 3 days so that people can sideline me both before and after the talks. Unfortunately, I won't be able to be there for the last 2 days. If you're going to be there, and want to talk about any of the projects I've got going on right now (CodePlex, ObjectBuilder, xUnit.net, etc.) please don't hesitate to find me. You can also use the Contact page here on the blog if you want to make sure I find time for you.

Hope to see you there!

Seattle Code Camp v3.0 - Nov 17 & 18

Brad Wilson — Mon, 15 Oct 2007 20:20:00 GMT

Seattle Code Camp is back! More information.

Update: Looks like it's been pushed back a couple weeks due to conflicts, and is now November 17 & 18.

Seattle Code Camp Venue Change

Brad Wilson — Thu, 26 Oct 2006 08:56:00 GMT

That Code Camp thingy that's just 2 days away? It's not in Federal Way any more. It's at Digipen in Redmond:

Digipen Institute of Technology
5001 NE 150th Ave
Redmond, WA 98052 [map]

That puts it within walking distance of my domicile. :)

See you there this weekend!

Now playing: Vanden Plas - Wish You Were Here

Sessions for Code Camp

Brad Wilson — Sat, 21 Oct 2006 15:35:00 GMT

Peter and I will be doing two sessions together at Seattle Code Camp this year. The camp is next weekend, October 28 and 29, at DeVry in Federal Way.

The first co-presentation is our Micro-Pairing talk, which was actually born out of last year's Seattle Code Camp talk about Model-View-Presenter. It was an odd combination that seemed to work okay, but this talk will focus entirely on the Micro-Pairing agile practice (we used to call this "The TDD Pair Programming Game" until Brian Button suggested this better name). This is the same talk we did at Agile 2006 (in July) and the p&p Summit (a couple weeks ago), and this will likely be the last time we do this talk publicly.

The second is titled How I Pwn3d the World of Warcraft UI with Lua. This is a new talk that we've never given before. We will discuss the topic of end-user extensibility in game development, and we'll teach you the basics of how to extend the game for yourself using a Lua/WoW Object Orientation library called Ace2. We don't want to give away too many secrets before the talk, of course. :)

I will also be doing a solo session titled Introduction to Dependency Injection. Peter and I did a similar talk last year, although at the time we couldn't talk much about ObjectBuilder's inner guts and implementation. This time around, I'd like to spend a little more time talking about the types of things that dependency injection can bring to application development, as well as illustrate how you can extend ObjectBuilder yourself through a real-world example. I will attempt, within the time given, to show how to implement an event brokering system like the one present in CAB, but without the requirements of having CAB or WinForms. And this time, I'll be giving away all the code, of course. :)

We would love to see all of you there!

Slides from Agile 2006

Brad Wilson — Mon, 31 Jul 2006 18:11:00 GMT

Peter, Mitch and I gave our talk on the pairing game at Agile 2006 this year, and the session was well received (deck). I think the stars aligned for it:

The right audience. Our talk doesn't really focus too heavily on introducing the concepts of pairing and TDDing, but instead on our modifications to pairing. If you're not familiar with the concepts, then you can get a bit lost by the nuances of the problems we try to solve with the game.
The right size audience. Peter made the comment that the talk is much harder past about 50 people, and I agree. With an audience of 25-50, you can be very interactive. We pushed the outside envelope of audience size, but it still felt very intimate.
The right message. We finally were able to distill what is most important about the game (which I'll describe below). What helped was discovering that the basic technique already existed (Ping-Pong Programming), which led us to be able to differentiate against it effectively.
The right environment. We've given a variation of this talk in many forms, and I think this one works the best. In essence, we had a very tall table that was used for the pairing laptop (my shiny new MacBook Pro running Windows XP). This was better than sitting at a table, and better than using a podium, which hides the computer.
The right deck. I can't stress enough how amazing Cliff Atkinson's Beyond Bullet Points can be. We had multiple comments when we were done about how engaging the deck was for people in the audience. All the photography in the deck is from stock.xchng (highly recommended).

The essence of the game is quite simple. When doing Test Driven Development, you have a state machine that is sometimes called "Red/Green/Refactor". The idea is that you start with all tests passing (green state), write a test that fails (red state), write just enough code to make the test pass (back to the green state), and then refactor as desired (whenever you're in a green state).

What we say is that you have discrete activities: writing a test, making the test pass, and refactoring. After performing any one of these actions, you pass the keyboard to the other person. In the red state, you have to make the test pass; if you're in the green state, though, you can choose to write a new test or to refactor. This process is what Ping-Pong describes. The keyboard passes very quickly; if you have the keyboard more than about 5 minutes, you're probably doing too much.

Our addition to the process talks about why you're doing this, other than "doing something extreme, in an extreme fashion". The purpose of the frequent keyboard passing is to provide an explicit state for scope negotiation. When player A writes a test and gives the keyboard to player B, that's a great time for them to discuss whether the test is taking them in the right direction, what it means to the architecture of the code, whether the step is too big, etc. Similarly, when player B makes the test pass and hands the keyboard back to player A, that person can also negotiate over whether too much work was done, or whether they even like the work done at all.

This frequent negotiation overcomes some of the limitations of traditional pairing. When you do the traditional style of pairing, the driver might have the keyboard for an extended period of time (30 minutes? an hour or 2?). Without explicit hand-over guidance, it's very easy for an extroverted driver to take over the pair. By forcing the hand-off, you tone down your extroverts and empower your introverts. You make sure nobody has the opportunity or desire to check-out of the process when they're the observer.

Even though the process sounds very simple, it can have a dramatic effect on the quality of your pairing time. I found that this style allows the team to stay engaged and get a lot done in just a little time. A warning, though, that this style of development can leave you feeling both mentally and physically tired at the end of the day. Remember to take frequent breaks.

All that we're missing now is a good name for the technique...

Pair Programming Game at Agile 2006

Brad Wilson — Mon, 15 May 2006 00:05:00 GMT

Peter, Mitch and I will be demonstrating the TDD Pair Programming Game at the Agile 2006 International Conference in July in Minneapolis.

Hope to see you there!

Now playing: Dream Theater - A Change Of Seasons

Portland Code Camp 2.0 is Coming

Brad Wilson — Sat, 06 May 2006 15:27:00 GMT

Jason has announced Portland Code Camp 2.0 for July 22-23. If last year was any indication, it's going to be seriously great. The new venue sounds excellent.

Unfortunately I won't be able to make it this year, because they counter-scheduled against Agile 2006 (where I'm already presenting with Peter Provost and Mitch Lacey).

Speaking at p&p Summit Boston

Brad Wilson — Sat, 11 Mar 2006 00:01:00 GMT

I found out today that I'll be speaking at the patterns & practices summit in Boston in two weeks. I'm still negotiating what my talks will be, but undoubtedly there will be some coverage of Smart Client stuff (CAB and/or SC-BAT) as well as agile topics.

Update: I got my list of scheduled topics.

On Wednesday morning I'll be talking about Smart Client Baseline Architecture Toolkit (SC-BAT), which will offer an overview of what the project is and how architects can use our toolkit to create their own baseline architectures.

On Thursday morning I'll be talking about ObjectBuilder, our framework for building dependency injection systems. This is the first time we'll be talking about ObjectBuilder publicly, and probably the only time this talk will be given at a Summit. It will be quite different from the DI talk that Peter and I did at Seattle Code Camp; instead of talking about dependency injection in the abstract and showing an OB wrapper, I'll be talking about what OB is, where we've used it in p&p, and how you can use it to create your own customized Dependency Injection framework.

Speaking at Seattle XP tomorrow (Thu Feb 9)

Brad Wilson — Wed, 08 Feb 2006 08:34:00 GMT

Peter, Brian and myself will be speaking at Seattle XP tomorrow night. The topic is "Experiences of an Agile Team at Microsoft". Pizza and networking start at 6:30 P.M., and the talk begins at 7:00 P.M.

This is one of my favorite talks that we give. Okay, some of that is because I'm lazy and I like recycling decks and giving talks that take no prep; but some of it because I love to share what we've done. We are continuously refining and improving the way we deliver software, and it's exciting to be able to share that experience with others who are interested in taking the leap to make those improvements on their teams.