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.

9:06:56 PM    comment []