Book Progress and Progrssive APIs

After posting about the Scenario Driven Design and the Design Guidelines book we are working on, I got several questions asking what “progressive API” is. Coincidentally I just submitted the final manuscript for a chapter that has a section on progressive APIs, so here is the related excerpt:


Progressive Frameworks


Designing a single framework for a broad range of developers, scenarios, and languages is a very difficult and costly enterprise. Historically, framework vendors offered several products targeted at specific developer groups and for specific scenarios. For example, Microsoft was providing Visual Basic libraries optimized for simplicity and a relatively narrow set of scenarios, and Win32 libraries optimized for power and flexibility, even if it meant sacrificing ease of use. Other frameworks, such as MFC and ATL were also targeted at specific developer groups and scenarios. 

Although this multi-framework approach has proven to be successful in providing APIs that were powerful and easy for specific developer groups, it has significant drawbacks. The main drawback[1] is that the multitude of frameworks makes it difficult for developers using one of the frameworks to transfer their knowledge to the next skill level or scenario (often requiring a different framework). For example, when there is a need to implement a different application that requires more powerful functionality, developers hit a very steep learning curve, because they have to learn a completely different way of programming, as illustrated in Figure 2-1.

Fig. 1

[Sorry, I don’t know how to post pictures yet. I will add the picture one I find out]

A much better approach is to provide a progressive framework, which is a single framework targeted at a broad range of developers that allows for transfer of knowledge from less advanced to more advanced scenarios.

The .NET Framework is a progressive framework and provides such gradual learning curve (see Fig. 2 below).

Fig. 2

[Sorry, I don’t know how to post pictures yet. I will add the picture one I find out]

Achieving a gradual learning curve with a low entry point is difficult but not impossible. It is difficult because it requires a new approach to the process of framework design, much greater design discipline, and has a higher design cost.

Fortunately, the guidelines described in this chapter and throughout the whole book are meant to guide you through the difficult design process and ultimately help you design a great progressive framework.  

You should also keep in mind that the developer community is vast. It ranges from office workers recording macros to low-level device driver authors. Any framework that attempts to serve all of those users may end up being a mess that could not satisfy any of them. The goal of a progressive framework is to scale though a broad range of developers, but not every possible developer. Clearly this means that those developers that fall outside this target will need specialty APIs.


[1] Other drawbacks include slower time to market for frameworks that are wrappers on top of other frameworks, duplication of effort, and lack of common tools.

Comments (1)

  1. Keep up the good work! I can’t wait to see the next section!

    I am very interested in how to design a progressive API. I am nearly certain this can be done with little resources.

    The ".net framework" is kind of a broad statement — it cannot have all been designed this way? Some areas seem easy to use, others a nightmare.