.NET Fireside Chats - Brad Abrams and Krzysztof Cwalina

DZone recently had an opportunity to sit down with Brad Abrams and Krzysztof Cwalina, authors of 'Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries, 2nd Edition'  In this interview, they discuss some best practices for developers to follow when designing and exposing their own frameworks.

DZone has also made available an excerpt of chapter 9 from Brad and Krzysztof's book, which can be downloaded here.

DZone - Tell us a little about what you do at Microsoft?
Brad Abrams - I am a product unit manager for parts of the .NET Framework in particular the Line-of-business story for Silverlight as well as the Managed Extensibility Framework.    But I am not sure that tells you what I do…  I create joy for developers using the .NET Framework.. I relish identifying the emerging demands in software development and creating frameworks that makes developers lives easier!
Krzysztof Cwalina - I am Program Manager on the .NET Framework team. I lead a team responsible for the general Framework design and architecture, and some APIs in the base libraries.

DZone - What motivated you to write the first edition of this book?
Brad - Krys and I have been working on these guidelines sense nearly the first day development of the what would later become the .NET Framework.   I was designing parts of the Base Class Library such as String and Object.    In doing so I realized that for developers to really have joy while using our framework, we needed consistency across the framework, so ASP.NET, WinForms, ADO.NET all needed to follow the same style and naming conventions.  So Krys and I began working on these guidelines as an internal specification.  We had some success at that, but I never considered doing a book.   A few years later, after .NET Framework 1.0 shipped I had a chance to go meet with several companies and spend one week at a time with several development teams in their work place.  I was amazed that so many of the issues they were debating and struggling with were already covered in the internal document we had been working on.  When I came home, we quickly started working on polishing the specification up into book format. 
Krys - When I started designing APIs for the .NET Framework I searched for available resources on the subject of API design. There were close to none. There were some very good API designers at Microsoft who knew how to do design great APIs, but the knowledge was distributed and not easily accessible. I thought it would be great to gather the knowledge in one document, and make it available to everybody in a form of a book.
 
DZone - Why did a second edition become necessary?
Brad - There were a couple of forces pushing on the need for a 2nd edition.  The most important one was new innovations in the .NET Framework created new patterns and options for .NET developers.   We believed that new frameworks should certainly start to follow those new patterns.  Innovations such as Linq fall into that category.   The other force was that the software development industry continues to mature – new patterns are becoming mainstream that affect the way frameworks are designed.  Patterns such as Test-driven development fall into that category.
Krys - Since the release of the first edition, we learnt how to explain some API design concepts better, so in addition to the changes resulting from new additions of the platform, some sections and chapters were updated to provide clearer guidance. 

DZone - What constitutes a 'Framework'?
Brad -  I think of a framework as being a set of code that is explicitly designed for use by someone else who is often separated by time or space.  If you are just writing some code for yourself to use right away, you can keep a lot of things in your head about the intended usage.  However if you are writing some code that someone else will have to consume, maybe someone you have never meet, maybe someone that can’t practically speaking talk to you, the only way you have to communicate with them is via the design of the framework.
Krys - I am just going to quote directly from the book: framework is a large object-oriented reusable library. I know some people say that framework call user code and user code calls libraries, but I think the distinction is not interesting anymore, as there are not many reusable libraries that do not call back to user code.

DZone - What are some of the hardest problems that developers are trying to solve when it comes to designing frameworks?
Brad - Communication.  Framework designers have some intended usage pattern, some scenarios for how their framework can best be used. Communicating that to the consumers of the framework is really hard.  Documentation is very one dimensional, samples and quick starts show only one narrow path through, there are millions of combinations you miss.  Having direct one-on-one chats is the best way to communicate this sort of thing, but it clearly doesn’t scale.  By using the standard set of patterns that both the product and consumer understand, the communication channel can be greatly streamlined.  The FDG attempts to connincalize these patterns. 
Krys - Getting designs that are both simple and powerful. You can accomplish this with proper layers of abstraction, but it’s hard. It requires a combination of experience, passion, prototyping, modeling, and getting continuous feedback from customers who will end up using these APIs.

My name is Alvin Ashcraft. I am a husband, father, and .NET geek. I have 13+ years of software development experience in the Healthcare and Manufacturing industries primarily using Microsoft tools. Alvin is a DZone Zone Leader and has posted 76 posts at DZone.