spout

February 15, 2006 spout

A Reviewing Trick I Learned A Long Time Ago

I learned this way of reviewing artifacts from Cal Caldwell, a friend of mine from my instructor days. The technique is for doing code reviews, but I’m going to be using it later this week for some design docs. Anybody who recognizes this technique can chime in with what it’s called:

  • Every reviewer gets a different hat,” i.e. a POV that they adopt when reviewing, e.g. looking for coding guidelines, looking for readability, looking at a feature from an architecture pov, looking at it from a particular customer pov, etc. Anyone can have feedback on anything, but the idea is that with different folks wearing different hats, you get a greater coverage.
  • Every reviewer brings review comments to the meeting, i.e. you reviewer before hand and only report at the meeting.
  • Every reviewer must start with something nice! Too often, engineers focus on the negative. Saying nice cushions the blow and reinforces the good things so that they don’t get cut.
  • Each piece of feedback will be logged (hopefully by the person that provides it) and spoken to the reviewee, but will not be argued with. If a reviewee disagrees, they keep it to themselves, asking only clarification questions to make sure that they understand the feedback. What feedback is applied it up to the reviewee and any follow up arguments happen offline.

That’s it. The best code reviews I’ve every participated in used this technique and I can recommend it highly for that. On Monday, we’re going to use it to get through a large number of design docs, so I’ll let you know how that goes.

February 15, 2006 spout

Scrum is very focusing

We started using scrum in my group this week and I'm already finding myself pushing aside work that I would normally sign up for in other groups. Scrum gives you to choice of being able to say "I did what I said I was going to do yesterday" or "I didn't." I want to always be able to say the former or have a good reason why not. Is "I was working with this other group" a good reason when the rest of your team is focused 100% on the thing? This is going to play hell with MS culture, but in a good way, imo.
February 10, 2006 spout

Multi-Touch Interaction Research

Wow. I wonder how many years that existence of the mouse has set us back because it delayed us from using this.
February 10, 2006 spout

My Favorite Wiki: pinvoke.net

I guess wikipedia is cool, but the wiki that provides a vital service in my life is pinvoke.net, which provides an enormous, user-contributed list of Win32 API mappings for .NET. I find it useful not just because folks are contributing tons of stuff I use, but also because I find it a wonderful place to drop code for my own later use, e.g.

This is the closest thing I’ve seen to a working code repository that is just as easy to contribute to as it is to use. Highly recommended.

P.S. I think this kind of functionality should be built into the SDK docs. I’ll ask em.

February 3, 2006 spout

PM Skill #7: Use That Meeting Time!

It’s very easy, as the PM, to not want to waste team time in a meeting, letting folks go when there’s still 30 minutes left. In fact, lots of folks will praise you for your short meetings. That’s fine if all of the work for that meeting has been done, e.g. everyone’s reported their status, all of the open questions have been decided, etc.

However, it’s often the case that in these meetings, other issues will come up to be discussed in future meetings to be scheduled at another time. Don’t let your concern for your team mates’ free time tempt you to let em go! It’s hard enough to get the folks you need together in a room. Once you’ve got em there, use em.

For example, if you’ve got the team together for weekly status that’s scheduled for 60 minutes, it often only takes 30 minutes. In that 30 minutes, you may decide that a subset of the team needs to get together for an hour design discussion on whether to spinning text boxes to your next software project. As a dutiful PM (aka mom”), you’ll often find yourself saying, Sure — I’ll set that up.” Then it’s your job to find an hour on everyone’s calendar while that issue remains open and the project drags on.

Don’t do it! Instead, peel off the folks in the status meeting that need to be in the hour design discussion” and have the meeting right then and there. You’ve already scheduled the weekly status for 60 minutes, so you know those folks are free and just dying to get back to reading email in piece in their office — put em to work instead! Who the hell knows how long a design discussion is going to take anyway? It’s just as likely to go under an hour as over, so you might be able to wrap up the issue right then and there, skipping the need for another meeting altogether. Believe me, your team mates will thank you for that!

January 31, 2006 spout writing

Japanese version of Avalon book

I thought someone might be interested in the Japanese version of our WPF book. Personally, I love the cover.
January 31, 2006 spout writing

Pre-order “Windows Forms 2.0 Programming”

I just noticed that Windows Forms 2.0 Programming,” by Michael Weinhardt and Chris Sells, is available for pre-order. I've had a lot of requests for info on this book, so now folks can watch this space. Mike and I have finished the copy edit rounds, but we still haven't seen the final PDFs, so it's still going to be awhile (hopefully no later than early April).
January 31, 2006 spout

IE7 Beta 2 worth the download

I've been using IE7 for the last week or so and it’s definitely worth the download. Just Ctrl+/Ctrl- itself is worth the upgrade, imo...