Chris Anderson: Rants

1,000 points of API design

Tue, 14 Jan 2003 05:06:56 GMT

Been talking with Anders Hejlsberg recently about new technologies and APIs… he made some great comments about 500 point APIs, from which I based this rant…

Why is it that technology companies feel that a new API will solve their problems? You need to look no further that Microsoft’s data stack to see examples. We went from DAO to RDO to ADO to ADO.NET. Of course, these were based on an underlying implementation of ODBC then OLEDB and finally .NET managed providers. I know that the teams had great reasons for each of these changes. You can see the same parade of technologies in almost all fields.

Before any API is obsoleted and replaced there should be a simple test. Your new API starts with a score of -1000. Once you have come up with 1000 or more positive points about the new API, then you can create the API. Today we are plagued with too many 500 point APIs. They have a lot of great features, but often they don’t justify the amount of API churn.

I would argue that .NET was a great example of a better than 1000 point API. .NET gave developers a great managed code environment with cross language support, ASP.NET, WinForms, and web services. The value of managed code justifies the new API.

Everyday technology teams are faced with tough customer problems to solve. They have continued request from developers for new APIs, features, and solutions. Probably one of the biggest problems developers face today is complexity of their developer platforms. At Borcon last year James Gosling made the comment that J2EE had become so complex that most developers should ignore pieces of it. Of course, the only problem that a new API can’t solve is the problem of too many APIs.

Everyone wants to work on new exciting clean APIs and tendency to reinvent the wheel is always present. Every new API is the one that will solve all the problems. The next new API is the one that will last for the next 20 years. Each API is the abstraction layer that other APIs can plug into. It’s like metadata for metadata for… eventually you need to have real data!

The problem with trying to fix the API proliferation is that it requires you to have a much more rigorous process for creating APIs. This process makes development take longer. With customers screaming for features, competitors constantly at your heels (or getting farther ahead), and stock holders wanting something new to drive up revenue it can be hard to take the high road and design APIs that can last. In addition it means you have to stick with the decisions you make.

There are times when your customers will ask for exactly what they don’t want. Designing high quality APIs is a balance between delivering timely customer value and producing carefully crafted long lasting systems. The challenge for anyone developing software is to walk this line carefully.

Meeting Etiquette

Thu, 09 Jan 2003 07:33:13 GMT

My frustration with meetings is increasing… I believe that on a daily basis I violate each of the issues listed below… I only hope that by publicly taking a stance against these evils, that I will be forced to fix my behavior...

Laptops at meetings...

Why do people attend meetings when they aren't going to contribute? I can understand if the entire point of the meeting is to disseminate information. All too often I see a meeting where, as everyone sits down every person opens their laptop and promptly begins browsing their email or the web. Before anyone points out the obvious - I have been guilty of this also. I recognize this is a problem, and I try to stop. The wireless network has brought us unparalleled connectivity, but (to quote spiderman) with great power comes great responsibility.

Being on time...

Being late to meetings has become so commonplace that people will only comment if you are ten minutes late - five is expected. Of course, to fill the time gap while we all wait for you we at least can check our email. :)

Scheduling meetings...

Schools long ago figured out that it actually takes humans time to travel from one location to another. They respond to this requirement by making each class 50 minutes long starting at the top of the hour. This gives each student 10 minutes to travel from one class to the next. Since no one (well, including me) has the curtsey to do the same this guarantees that you will be late for the next meeting.

What about core hours? In a company with no required schedule, people widely vary the time of meetings. Amar (sorry, his weblog is offline) scheduled me for a meeting tonight at 6:00pm. I couldn’t understand why he would schedule a meeting so late - I started the day at 8:00am after all (and I’m trying to have a home life). Of course, for Amar (who started his day at 10:00am) a 6:00pm meeting was clearly in the middle of his day. In an industry where people can work any hours they like, how appropriate is it to limit meetings to the times when “you” are comfortable?

Meeting purpose...

People should know the goals and objectives (and hopefully agenda) of a meeting before you ask them to attend. Brainstorming, Reviewing, and Information Briefing meetings are very different and need a different audience. I have seen more meetings where someone decides that every “reviewer” needs to attend the “brainstorming” meeting - making the invite list for a brainstorm meeting be 20 people... not very productive for brainstorming.

Preparing for a meeting...

If you are going to attend, you should be prepared. If the meeting is a review - read the material before hand. If the meeting is a brainstorming meeting, try to spend at least 5 minutes before you get to the meeting (maybe in the morning, when reviewing your schedule?) to think of a few ideas. You are invited to meetings to participate, not to take up space!

Ending a meeting...

When a meeting is about to end (which should be as soon possible, not when the scheduled time is up), a few things should happen… Notes that can be read and understood by people at the meeting should be posted to a public (well, public to the organization/context that the meeting was help in) location… Tasks should be assigned to specific individuals with due dates, expected deliverables, etc... Decisions should be broadcast to all affected

Email Responsiveness

Tue, 07 Jan 2003 05:57:29 GMT

I'm not sure if this is a universal truth or not, but I suspect it is.

People can't manage their email.

This isn't a spam problem or tool problem. This is about people that don't understand how to deal with mail in a timely fashion and manage their time. I have seen people that proclaim proudly that they have 4,000 messages in their inbox with 1,000 unread items. It must make them feel important to be so popular?

It is time to take a stand. We must demand action.

Jeff Bogdan (a coworker) and I have been trying a new system. We basically compete with each other to keep our inbox as small as possible. We read mail several times a day and try to respond, file, or delete each mail as we read it. The goal - less that 20 messages in your inbox.

It's amazing - Once you get your email under control the frustration you feel when someone isn't responsive to your mail is even worse. We are hoping that we can use shame and humiliation as a tool to convince others to follow our lead on agressively managing mail.

This is such a huge deal at a company like Microsoft. We communicate almost exclusively through email. It is not uncommon for people to get 200 mails a day, with some people toping at over 500. I'm sure that many other large companies out there are the same way. People get bogged down in mail, stop responding, and next thing you know you are always walking down to someone's office asking them to read you mail right away. Or, even worse, you start tagging every mail with a !

Read mail several times a day (not continuosly, but also not only in the AM or PM)
When reading mail try to respond, file, or delete the mail when you first read it. The goal is to touch each mail only once.
Use Outlook (or whatever program is your favorite) to auto-file large mass mailing lists into folders so that they don't pile up in your inbox and hide important mails.
Keep less than 20 mails in your inbox.

Next soapbox... Meeting etiquette, but i'll save that for later.