.comment-link {margin-left:.6em;}

Tuesday, October 25, 2005

The French really know how to have a good time...


...and have tought me well :-)

The picture lost some detail when I scaled it down.
That's a Jeraboam of really excellent Bordeaux in case you were wondering. This was taken at my wife's family reunion in Hossegor 2 Summers ago. There were two magnums of Bordeaux in addition to this.

Saturday, October 22, 2005

Interfaces or Classes in APIs?

Last week some colleagues and I were debating the use of interfaces vs. classes in API design. Believe it or not, this conversation started because "it had been decided" that we would not adopt the convention of beginning interface names with the letter 'I'. The reason was that this was redundant because all arguments and return values for all API methods for a service should be interfaces and not classes. And so the debate began. Should we use interfaces or classes?

I think the answer is both. Value objects passed into methods or returned from methods can be either classes or interfaces. If you assume that the service (API) you're designing can itself have different implementations, then you should use interfaces for parameters that can have different implementations that are tied to specific implementations of that service. However, in some cases, a method will include a parameter that is a simple "struct" that might be used to modify the behavior of the method. For example, for a "lister" method, you might pass in an object that determines how many values should be returned or whether you want a deep listing of a hierarchical structure. These parameters might as well be defined as concrete classes. There's really nothing to be gained by allowing alternate implementations here.

In general, I like the pattern in which you use a factory to get a specific implementation of a service. That service implementation then acts as a factory that returns other objects that might also be used as factories for additional objects. A good example of this is the Eclipse resource hierarchy. You start by getting an IWorkspaceRoot from which you can get other containers such as IFolder or IProject's from which you can get IFolder's or IFile's and so on.

And yes, I'd prefer to prefix interface names with 'I' even if in some cases it's redundant.

I can't wait for the debate on Collections vs. Arrays...

Tuesday, October 18, 2005

Dare to be Wrong

Some number of years ago, I had started a new software project and I was stuck. I didn't even know where to begin much less understand what design choices to make. I was talking to a former boss (and still good friend) of mine and he gave me some of the most important advice of my career: "dare to be wrong". It seems so obvious now. Start in a direction and see where it takes you. If you run into a roadblock, back up and start again. This one phrase also embodies some well-known concepts in software engineering: iterative design, refactoring, agility.

Unfortunately, this advice only works if the environment in which you work allows it. I found this out the hard way when I joined a very large project at a very large company. The bottom line was that there just wasn't the time to be wrong. Actually, there was lots of time to be wrong--just not enough time to make it right. Coming in one day to find out that 3 other teams you didn't even know existed have decided to call the initial version of the API you just checked in to source control doesn't allow you the time to be wrong. Refactoring in an extremely large, distributed environment is at best difficult and often impossible.

At one point in this project, even the lead architects had to admit that we had done a lot wrong. The entire architecture was a house of cards waiting to fall. So almost an entire release was devoted to "refactoring", a misuse of the term that would probably make Martin Fowler physically ill. What was even worse was that rather than present this to the team as a good and healthy thing, the leadership of this project reiterated (almost daily) that we had lost a lot of "points" with senior management and this would not be allowed to happen again. How misguided... This was a very young project and the fact that we hadn't gotten all of the design right should have been expected.

Software engineers and managers need to be honest with themselves and their management and embrace "dare to be wrong". It avoids "analysis paralysis" and is healthy for employees, the process, and the project/product itself.

Sunday, October 16, 2005

Sue is blogging!

My friend Sue Senator has started a blog. Check it out!

Wednesday, October 12, 2005

I may not be able to resist any longer...

Apple unveils the new video iPod

Must...not...reach...for...credit...card....

Google Calculator

I just discovered this. You can type a mathematical term in English into Google and it will invoke Google Calculator. For example, I typed in "2 to the 6th" and Google returned:

2 to the 6th = 64
More about calculator.

You can also do unit conversions like "2 cups in liters" which returns:

2 US cups = 0.473176475 liters
More about calculator.

So cool. And yes, maybe I have been living under a rock...

This page is powered by Blogger. Isn't yours?