Framework Design Guidelines: Scenario Driven Framework Design

Ccontinuing in our weekly blog post series that highlights a few of the new image[5]_thumb[2]_thumb[2]_thumbadditions to the Framework Design Guidelines 2nd edition.. This annotation is found in Chapter 2: Framework Design Fundamentals. Joe and Chris nail the core things.


As software developers, we enjoy creating fun and powerful new capabilities, and sharing them with other developers. That’s one of the reasons API design is so enjoyable. But it’s also incredibly difficult to step back and objectively assess whether some new capability that you’re particularly passionate about has utility in the real world. Using scenarios is the best way I know of to identify the need for and ideal usage of new capabilities. Developing scenarios is in fact incredibly hard, for good reason: It requires a unique combination of technical skill and customer understanding. When you’re finished, you could make a series of decisions based only on gut feel and intuition, and perhaps deliver some useful APIs, but the risk that you will make a decision you will later regret is far greater. When in doubt, it’s best to leave a feature out and decide to add it later when a compelling need is better understood.


Each developer has his or her own methodology, and although there isn’t anything fundamentally wrong with using other modeling approaches, the problem generally is the output. Starting by writing the code you want a developer to write is almost always the best approach—think of it as a form of test-driven development. You write the perfect code and then work backwards to figure out the object model that you would want.

Comments (4)

  1. Shail says:

    Hello Brad,

    I just finished second chapter of the book. I would also like to draw some good point from it. Like  –

    1. We need to develop Framework to be used by various kind of users, not to be created for "Intellectual Pleasure".

    2. People should understand that "Object Oriented Programming" is creating maintainable code and applications, still it lacks usability things.

    3. Some time in name of "Object Oriented Programming", people just kill there apps. Sometime re-factoring an application to make its design better and more object oriented, we have to sacrifice performance.

    4. Overuse of Abstraction, example was of "File" class in System.IO namespace

    There is one very very important section in that chapter on "Naming". It says to keep the name very simple and sometime get help/approval from usability engineer.

    There is a kind of catch in this case. I found that working with people from different countries will lead to so many names, which even doesn’t make sense. Example one of my fellow developer created a function "Create_An_Products", and as per his/her knowledge of English, this is the best name 🙂

    I hope this is a kind of annotation from me for your 3rd edition 🙂

    Its really worth to buy this book from Amazon. Very nice work !

    Thank You

  2. BradA says:

    THanks Shail — those are some very good point!  I am glad you got them out of the book!

  3. Лечение геморроя – вылечить заболевание при помощи лекарств. Ресурс будет полезен всем болеющим анальными трещинами, а также вирусологам и студентам, и любому кому интересны проблемы геморроя. Отдельный раздел сайта посвящен рецептам от геморроя при помощи народной медицины.

  4. Does visual studio use the recommended guidelines by default? It’s my impression that visual studio defaults are the de-facto standard. Would it be possible for MS to release a visual studio setting selection that say "C# Design Framework Guidelines"?

Skip to main content