Home > Articles > Programming > Windows Programming

Ten Years of Framework Design Guidelines: Video Podcast Transcript

In this transcription of one of our OnMicrosoft podcasts, Brad Abrams and Krzysztof Cwalina discuss industry changes that have affected (or been affected by) the Microsoft .NET Framework over the last decade.
Like this article? We recommend

Welcome to OnMicrosoft—conversations with thought leaders in Microsoft technologies. In this session, Brad Abrams and Krzysztof Cwalina provide a sneak peek at their PDC presentation on framework design guidelines. Learn key lessons from 10 years of framework design.

Brad Abrams: Hello! Welcome. I'm Brad Abrams, an employee at Microsoft. We're at the Redmond campus, and I'm joined by Krzysztof Cwalina. Krzysztof, we're doing a talk at the PDC. (We just found out about this last week, actually, so we've been working hard to finalize things for the talk.) [Meanwhile,] it's 2008, and about 10 years ago you and I started working on the very first draft of [our book] Framework Design Guidelines.

Krzysztof: Yeah, I cannot imagine that it has been 10 years.

Brad: We debated lots of things back in the day. We had this living Word document that went through rounds and rounds of reviews—and, of course, tons and tons of additions—and then it eventually became a book that I'm very proud of. And now we're doing [the second] edition. [Cwalina and Abrams published Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries, Second Edition in October 2008. -ed.]

But it's good to look back from the year 2008 and just think about what's changed over the last 10 years—how things have either changed or not changed with the guidelines. While I definitely think we've learned—I personally have learned—a lot over the last 10 years, I'm equally impressed by what hasn't changed—certainly, some of the key fundamental tenets of the guidelines. I think we talked early on about "usage first" design—rather than design with a UML model, design with sample code in mind. That has stayed the same. Are there other things you think have stayed the same?

Krzysztof: I think the concepts of simplicity, layering—kind of factoring the framework the right way.

Brad: Yep.

Krzysztof: What changed? We learned a lot about how to explain the design of large framework libraries.

Brad: I think that's true. One of the things that we were talking a lot about in 1998 was properties versus methods. When we first designed the CLR [Common Language Runtime], we didn't have properties at all—all we had was methods. We actually built the first version of the BCL [Base Class Library] and large parts of the framework—Windows Forms and parts of ASP.NET—without any properties whatsoever. So when we made the move to having properties supported in the type system (this is well before we shipped 1.0), we had to think really hard about when to use methods and when to use properties. From a geeky low-level CLR there's no [real] difference between properties and methods—they both resolve to the same IL call that invokes the method. We had to think about what's the developer semantic and what's the meaning. And I think where we landed is about methods being action-oriented (taking some operation—doing some transformation, for example) and properties being a lot more about (at least logically) just exposing data, getting and setting data, and properties shouldn't do a lot more than that.

Krzysztof: Definitely. We were talking a lot about the concept of component-oriented programming or design, where components are basically things that have constructors, properties, methods, and events. This list of four constitutes the underlining of framework design.

Brad: That's right, the PME [Properties, Methods, and Events model].

Krzysztof: Exactly. Finding ourselves in 2008, we have a new concept of extension methods. And when we started to think about how they impact the framework design, we discovered that they actually will have enormous impact on the design. They sound like they're just methods but—

Brad: Describe what extension methods are, just to make sure [that our audience understands].

Krzysztof: Extension methods are basically static methods that you can call with syntax that [makes them] look as if they were instance methods. So basically it's very easy to declare an extension method; it's just a static method with the first parameter being annotated with the modifier called this. As I said, extension methods sound like they are just methods; you may think they are just static methods with some modifier, but they actually fundamentally change the design of the framework. For example, some of the things that you can do with them: You can have implementation in interfaces—or, at least, the system appears as if interfaces had an implementation. And, for example, they are used extensively in LINQ. Because of extension methods and their property that I was just talking about, every single type that implements IEnumerable(Of T), the interface, can gain new capabilities.

Brad: Even ones that were implemented long ago now automatically have IQueryable.

Krzysztof: Exactly, exactly. Another very game-changing property of extension methods is that we always had the tradeoff between componentization and dependencies and usability. So if you wanted to have a component that was very usable, it was nice if the component was able to do quite complex and high-level scenarios. This is the mental model of the many developers who program real business problems. With regular methods, we basically had to put all the functionality related to the business problem on the type that was implemented in methods, which meant that there was a lot of coupling between different parts of the framework. You didn't want to compose your program for very small building blocks—you wanted to have the components that some people called "Swiss Army knives": They do a lot of things, and that's very usable—that's great for high-level programming.

Brad: Yeah, yeah.

Krzysztof: Unfortunately, it's not so good for decoupling parts of the framework. Extension methods allow you to get both usability and decoupling, and the reason is that a method that appears as if it were on the component foo could actually been in a completely different place—because it's just a static method.

Brad: Yep, yep, I love it. And I think that the other great benefit for extension methods is, especially as a user of a framework, you're no longer locked into exactly the decisions that that framework author made. So, for example, if you really want a reverse method on string, you can go write one and have it appear as on string.

Krzysztof: But, as we sometimes say, with power comes responsibility, because extension methods now allow anybody to add a random method to system.string.

Brad: Even though we spent hours and hours designing system.string, now anyone can go and mess with our design.

[Both laugh.]

Krzysztof: Exactly. So that's a big part of the design guidelines for extension methods—talking about both the powers that they offer and the responsibility of people using extension methods not doing things like adding random methods to system.string.

Brad: Totally. Another thing, if I roll back to 1998, the kinds of things we were thinking about: the whole idea of managed code, specifically having managed memory with a garbage collector and a just-in-time compiler really controlling the memory allocation in your program. That was a foreign concept. Certainly other systems [were] going on, but really a lot of the internal developers as well as some of our initial external customers weren't sure that they were willing to trust a sensitive thing like memory allocation and deallocation to the system.

Krzysztof: Yeah.

Brad: Could the garbage collector ever do a good enough job? One of the things that we were thinking about at the time is how you design APIs in a world where there is garbage collection—where usually there [are] not memory ownership issues, as you have with C and C++ APIs. And then, of course, dealing with the realities of some of the resources not being directly managed by the garbage collector; for example, file handles and window handles. How do you build frameworks that work well in that environment? In some intuitive sense, you don't lose the management benefits you get with the garbage collector, but you're able to get rid of those database connections in good time.

Krzysztof: Yeah, yeah, definitely. I remember talking to developers and customers about the .NET Framework 10 years ago, and there were lots of questions about the GC [garbage collector]; ranging from, "Is it ready? Is it primetime for GCs?" to what you mentioned, "How do I manage other things than memory? Is GC for [those things]?" and so on, and so on. Right now, I don't get these questions anymore. When was the last question someone asked you about [that]?

Brad: It has been a while. In fact, I had to scratch my head a little bit. But I used to be really good at answering them, because they used to come up all the time.

Krzysztof: Yeah, exactly. Now, if I had to say what is the one of the most common questions that is not "practical," but [rather] a "big" question, [I would say that it's] how a new technology will impact framework design. I think most often people ask me about concurrency threading. What are we going to be doing with the multiple colors that are showing up?

Brad: That is definitely the 2008 year equivalence: concurrency.

Krzysztof: Yeah, exactly. So, we are making big investments in the .NET Framework in terms of features, and thinking about how we can make multithreaded programming as easy as memory management was made by introduction of the GC—where you don't have to worry about the majority of the tasks related to multithreading.

Brad: It strikes me that it's the same kind of thing; we are essentially adding a layer of abstraction. That's what the garbage collector does when you use the new operator in C#: You're building on a layer of abstraction, and expressing more of your intent in the program, rather than the actual operation. It strikes me that that's the same solution—we're working on different models, but that's basically the solution for concurrency—have developers express their intent. Their intent is that this chunk of code run, and do that in a way that then the system can go figure out how many threads to put that on, based on the hardware on the machine, and how to synchronize things and whatnot.

Krzysztof: I think this will be a multilevel approach, ranging from: 1) making the current explicit threading much easier—because more developers will have to be doing this—to something where developers, as you said, express the intent, and [then] the framework, the system, worries about the details; 2) multithreading that is completely automatic, where the developers don't have to think about multithreading. A good example of this approach is ASP.NET.

Brad: Yeah, I totally agree.

Krzysztof: Most ASP.NET applications—or [rather] all ASP.NET applications—are multithreaded. Developers don't have to think about threading that way.

Brad: We're able to kind of encapsulate that in the ASP.NET programming model.

Krzysztof: Exactly.

Brad: Yeah.

Krzysztof: So now the challenge is how we take it from basically ASP.NET space and kind of expose it broadly, or use it broadly in the .NET Framework.

Brad: That makes lot of sense. So, then, if I go back again and think about 1998, what was going on there, we were working on C# and VB.NET at the time, but we were also thinking about how the CLR was really a common language runtime, and that this runtime would work with a wide range of languages. I remember buying COBOL books at that time, Perl books, and ADA [books], and having the chance to really delve into what these language features had—what was unique about them, what was the same. There were two levels of that problem. One level is just, could we build a CLR that would technically run those languages? All things being equal, that was the easier problem.

The harder problem was that then we needed to go build out a framework that would work with all the languages. If one language didn't support properties and another language did, does that mean that you're not gonna have properties in the system? What if one language supports exceptions and another language doesn't? What is the subset of all the language features that you're able to use in a framework design? We didn't want it to be the case that basically we would bottom out on that being whatever VB does, or whatever C# does. We wanted to have a more deliberate approach, and think about a design that would work for all languages. So that's where the Common Language Specification was born, the CLS, that we later standardized via the ECMA and ISO standardization process that really kind of encapsulated how all the languages would work with the framework.

Krzysztof: That was one of the things that really attracted me to the CLR and .NET Framework, because I was fresh out of school in 1998 and I remember doing projects in some exotic languages at school.

Brad: Yeah, yeah.

Krzysztof: There was always the problem that, yes, you have the compiler, but you don't have the whole ecosystem that is required to do some of the interesting things that I wanted to do—ranging from the development environments to, for example, forms framework. Yes, you could write an engine, [a] theorem prover, in ML; but then actually presenting a user interface was really challenging. So, the Common Language Specification and Common Language Runtime enabled some of the more exotic languages to actually plug into the ecosystem of tools in the .NET Framework. But I think they were still kind of treated as exotic languages. They were not used very broadly in the industry. Now, in 2008, this is changing. I think the industry is maturing to look at the broader language space and see [whether] some of the languages that used to be considered as exotic are actually more suitable for solving real business problems—that includes functional languages like F# and dynamic languages like Python, Ruby, and so on.

Brad: Yeah, absolutely. One could argue that the CLS and the broad framework we did 10 years ago planted the seeds that only now are we beginning to reap in 2008—having a plethora of languages that can plug into the framework, and we'll take advantage of that.

Thanks, Krzysztof. It has been great to think about how things have changed from 1998 to 2008. What do you say we get back together again 10 years from now, and see what's changed in 2018?

Krzysztof: Yeah, I cannot imagine.

Brad: Great—we'll see you then.

For more information, visit onpodcastweekly.com and subscribe to all our podcasts. Brought to you by the publishing imprints and information portal of Pearson Education.

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020