Thanks for the Scrum Training

I'm a certified Scrum master; I learned the secret handshake and everything!

I highly recommend taking the class, even if you have read a lot about scrum or are working in a scrum organization. Ken had very good insights, was thoughtful in answering questions and sent me home reflecting many things.

As for my fellow classmates, I'd like to thank everyone who supported the leukemia and lymphoma society with your tardiness! For those who are curious, $47 was the total penitance; though the number of late resources was quite less -- quite a generous group :)

Slightly off topic, if you are in Boston and are looking for an Italian restaurant, you must try Giacomo's (Ken, you really missed out!). The new law that lets you bring your bottle of wine home, makes the affordable wine menu great even for the designated driver, who happened to be me.

Speaking of driving in Boston... hmm... its too late to get started on that one.

Scrum and the product owner

Oksana and I (do we ever do anything alone?) are in Boston for Scrum training with Ken Schwaber this week. The class is interesting; I know a lot about scrum and have been practicing (or trying to practice) it since 2003.

One thing that I kept reflecting on during the class, is the true value of the product owner.

Before Oxygen, I always lacked the single wringable neck. I met with stakeholders, had iterations, backlogs, daily meetings -- everything, but the true product owner. Most times, I would have buy in from users and developers to participate in meetings and monthly reviews, but I never had what I have at Oxygen and it was a flawed way of working.

There is a conflict of interest between the product owner and a developer. Yes, you share a goal, however, its the developers job to expose risk and estimate effort and the product owners job to evaluate the information to make decisions that will decide the fate of the project.

It wasn't until training today and working with people that didn't have the luxury of the product owner that I remembered the pain lacking one. I've been trying to write about this and I have no words...

Luckily, Ken did a few weeks ago, this is what I want to say. I really loved reading it when Ken wrote it; today I appreciated how lucky I am (once again).

A call to women developers

An Italian blogger, rosalba, has started a collection of blogs, articles, books, code samples and anything else development related written by women.

I think its great; if you're out there, you should let her know!

Empty Interfaces

A recent practice I've taken up is empty interfaces.

Why you ask? Generics!

I love generics, they've added a whole new world to my design, but when it comes to using a generic interface, I find it best to wrap it in another interface, even if that interface is empty.

Here are some reasons:

1. The name is longer and intellisense isn't smart enough to fill in the types -- more typing (on the keyboard) is never fun (though visual assist does guess pretty well)

2. The name does not imply its responsibilities. Sometimes the generic interface is all you need, but the type of the interface is too generic to understand its responsibilities and behaviors.

3. If you need to add something extra to the interface, it will be quite painful to replace usages with an explicit interface.

4. A generic type name is an ugly type as a string -- I can never remember how to put a generic in the application configuration.

5. Less encapsulation -- if you have a generic interface that has two types, one type is implementation specific (like its used to consume another generic interface) and one type is consumer specific, consumers need to have more knowledge about implementation than they should, just to use the interface.

Here is a reason not to:
1. FxCop -- it gives you a warning... Here is what I think -- FxCop is great at giving warnings, but thats its job, it doesn't understand context, FxCop is not a reason on its own not to do something :)

The shield of YAGNI

YAGNI (you ain't gonna need it) is a good principal, but like anything, too much of a good thing isn't very good at all.

Yagni is a tool to keep us on track, to help us make decisions and guide us in our development. Like any other practice, it does not stand on its own without logic and reason. Sometimes its thrown around like my parents used the phrase, "because I said so." And while that works well for a crying three year old who wants to stay up late, any catch all phrase is dangerous.

When I am writing code, I add abstractions I don't need. You can argue this goes against yagni, because you don't need it (and you ain't gonna).

These abstractions are not there to support behavior that may exist in the future. They are added because, when things change (and they always do), it has ALWAYS been a lot more painful when they did not exist.

There is a very distinct difference between this and adding extra functionality or abstractions to enable change you think will happen.

This is an important difference.

Next time you are having a discussion and yagni is brought up, think about which one is driving what you supposedly don't need.

Xbox is Down!

And the oblivion expansion, Shivering Isles, comes out today.

What timing... not like I'd be playing anyway, being that I'm at work and have to paint my living room when I get home :(

Bonus Session

Oksana and my session about pair programming is now featured on the bonus session page for devteach, check it out!