Video Recording of "Framework Engineering: Architecting, Designing, and Developing Reusable Libraries"
08 January 08 10:42 AM | kcwalina | 5 Comments   

I just received a video recording of a talk I did at the last TechEd. You can find the abstract below, and the WMV file can be downloaded from here. Hope you find it useful.

[UPDATE: I attched the slides in xps format. The ppt file is 10x larger]

Framework Engineering: Architecting, Designing, and Developing Reusable Libraries  

This session covers the main aspects of reusable library design: API design, architecture, and general framework engineering processes. Well-designed APIs are critical to the success of reusable libraries, but there are other aspects of framework development that are equally important, yet not widely covered in literature. Organizations creating reusable libraries often struggle with the process of managing dependencies, compatibility, and other design processes so critical to the success of modern frameworks. Come to this session and learn about how Microsoft creates its frameworks. The session is based on experiences from the development of the .NET Framework and Silverlight, and will cover processes Microsoft uses in the development of managed frameworks.  


Framework Design Guidelines 2nd Edition
03 January 08 02:39 PM | kcwalina | 25 Comments   

My blog was relatively silent for several weeks. First, I was traveling to Europe for the TechEd, then was busy at work, then the holiday break. It's time to go back to more regular posting.

I will start with an announcement (or at least a more formal and broader announcement): after my TechEd presentation, the first question I got from the audience was whether we are working on a new edition of the Framework Design Guidelines. The answer is "yes", which I am super excited about. Right before the conference, we signed formal documents with the publisher and started wortking on the book. It's going to cover the new features in the .NET Framework 3.0, 3.5, and new advances in languages (e.g. LINQ) that are relevant to Framework design. BTW, I would appreciate feedback on what specifically you would like to get covered or clarified.

We are shooting to have the book ready around the end of 2008, but the publisher already sent me a draft of the cover art:

What Do Swimmers Have to Say About Framework Design?
04 October 07 05:09 PM | kcwalina | 7 Comments   

I am starting to feel pressure to finish up slides for my presentation at the upcoming TechEd in Barcelona. I will be talking about framework architecture and design. Here is the abstract I took from the conference’s site:

WIN304 Framework Engineering: Architecting, Designing, and Developing Reusable Libraries  

This session covers the main aspects of reusable library design: API design, architecture, and general framework engineering processes. Well-designed APIs are critical to the success of reusable libraries, but there are other aspects of framework development that are equally important, yet not widely covered in literature. Organizations creating reusable libraries often struggle with the process of managing dependencies, compatibility, and other design processes so critical to the success of modern frameworks. Come to this session and learn about how Microsoft creates its frameworks. The session is based on experiences from the development of the .NET Framework and Silverlight, and will cover processes Microsoft uses in the development of managed frameworks.  

I am super excited about the talk, which I want to make into a continuation to the API design pre-con I did with Brad Abrams at the last PDC (BTW, the same content is available here). The PDC talk was about designing the API surface, but there is so much more to framework design!

I am also excited coming back to the wonderful city of Barcelona. Last time I was there, believe it or not, I was on the Polish swimming team competing in the Olympics (see #13). I hope this trip will bring back some memories from the other and completely different “career” I had in the past.

FxCop Rule for Multi-Targeting
02 October 07 04:50 PM | kcwalina | 16 Comments   

Two months ago, Scott blogged about the multi-targeting support in Visual Studio 2008. I worked on this feature in the planning phase (read “long time ago”), and so I am quite thrilled to see it finally in the hands of developers. Especially, that several years ago I remember our small working group sitting in a room and wondering whether such feature was even possible. The complexities of implementing it in a large project like the Visual Studio seemed quite daunting.

The thing that made implementing multi-targeting in one release possible was the concept of Red and Green bits.  You can read about the concept here, here, and here, but quickly: red bits are Framework assemblies that existed in the .NET Framework 2.0 and were serviced in versions 3.0 and 3.5. Green bits are assemblies that were added either in the version 3.0 or 3.5. The servicing changes in Red bit APIs are limited (after all it is servicing) to a very small number of API additions and bug fixes.

 We leveraged (and influenced) the decision to limit the number of changes to existing assemblies to drastically simplify the requirements for the multi-targeting system. That is, we made an assumption that the majority of differences between the Framework versions (targets) are on assembly boundaries. 

But now I have to confess, there are some limitations in this design that we accepted when we made the original simplifying assumption. There is a very limited number of APIs being added to the Red assemblies and the multi-targeting system is currently not able to detect these.  For example, if you set the target to the .NET Framework 2.0 and read the newly-added (albeit obscure) property GCSettings.LatencyMode the program will compile just fine but then fail to run on the .NET Framework 2.0 RTM. The reason is that the property was added to an existing (Red) class GCSettings, not to a new class in a new assembly. Despite that the number of such additional APIs in Red bits is very small (and that we recommend that you still test your programs on all targeted platforms), this can be quite annoying. And so feeling a bit responsible for this (and trying to promote FxCop J), I wrote an FxCop rule that can analyze IL of an assembly targeted at Framework 2.0 and warn you about all calls to members that are not present in 2.0 RTM.

Here is how it works: The test program below uses new LatencyMode enum and calls a new GcSettings.LatencyMode property. As I mentioned above, these APIs don’t exist in .NET Framework 2.0 RTM. Even if I built this project with the multi-targeting target set to Framework 2.0, the system would not complain about calling these APIs. But, as you can see in the error list, the FxCop analysis engine can deal even with this difficult to detect problem. You can think of the rule as a very smart (post) compiler-step.


A sample project with the rule is attached to this post. I provide it without any guarantees, as is, and in fact I am sure it has many bugs and problems. When I find time, I will work on it more to polish it a bit but I don't promise (i.e. treat it as a sample).

BTW, to install the rule, just build it and drop it to the FxCop rules directory. On my machine it is at C:\Program Files\Microsoft Visual Studio 9.0\Team Tools\Static Analysis Tools\FxCop\Rules. In addition you have to go to Project settings of the project you want to analyze and turn on FxCop analysis (the “Code Analysis” tab in the project properties). Lastly, you can either rebuild or right click on a project and choose “Run Code Analysis”. I hope it’s helpful.

Filed under:
China Trip
02 October 07 11:42 AM | kcwalina | 1 Comments   

Sorry for not blogging for such a long time. First I was on a combined business/vacations trip to China and when I came back, I got involved in some intensive planning for the future releases of the platform. I will try to post something about software in the next couple of days.

The trip to China was great. First day I taught a class on API design at the Microsoft center in Beijing and then my wife and I stayed for several days doing sightseeing, drinking the best tea ever, and indulging ourselves in great food (complete photo documentary is here).


Filed under:
Duck Notation
18 July 07 11:20 AM | kcwalina | 32 Comments   

I have been working with the C# and VB teams on design guidelines for LINQ. We started to talk about the so called Query Pattern, which describes what you need to do if you want a custom type to support the new query operators (select, where, group by, etc.).

The query operators use duck typing to determine whether they can operate on a type or not. This means that instead of implementing an interface (static typing) a queryable type will need to have a set of members that follow a specified set of conventions (naming, parameter and return types, etc).

For example, the C#’s foreach operator already uses duck typing. This might be surprising to some, but to support foreach in C# you don’t need to implement IEnumerable! All you have to do is:

Provide a public method GetEnumerator that takes no parameters and returns a type that has two members: a) a method MoveMext that takes no parameters and return a Boolean, and b) a property Current with a getter that returns an Object.

For example, the following type supports foreach:


class Foo {

    public Bar GetEnumerator() { return new Bar(); }


    public struct Bar {

        public bool MoveNext() {

            return false;


        public object Current {

            get { return null; }





// the following complies just fine:

Foo f = new Foo();

foreach (object o in f) {



But, as you can see in the yellow highlight above, the describing the foreach pattern in English (or any other spoken language) is quite difficult and not very readable, especially if you contrast it with the simplicity specifying requirements based on static typing:

Implement IEnumerable.

… and having IEnumerable defined as:


public interface IEnumerable {

    public IEnumerator GetEnumerator();


public interface IEnumerator {

    public bool MoveMext();

    public object Current { get; }


The english description gets much worse for something like the query pattern, which is way more complex than the foreach pattern. Because of that, I was thinking that there must be a better way to specify such patterns based on duck typing. But when I searched the web, to my surprise, I could not find any simple notations to do that. If you know of any, please let me know.

In the absence of an existing notation, I started to think about something like the following:


[Foreachable] {

    public [Enumerator] GetEnumerator();


[Enumerator] {

    public bool MoveMext();

    public [ItemType] Current { get; }


This seems much easier to parse than the English description of the pattern. What do you think?

How to Fight Complexity in Software (part I)
17 July 07 04:02 PM | kcwalina | 0 Comments   

A couple of weeks ago, Grady Booch gave a lecture at Microsoft. It was a pleasure to hear of my software engineering heroes in person.  Grady talked about “the promise, the limits, and the beauty of software.”  

The main thing that captured my interest during the lecture was a discussion about the cost of complexity in software.

Grady said that there are many factors influencing the cost of software, but two of these factors have disproportionally high impact on the overall cost: a) the processes used to develop and maintain the software, b) the complexity of the codebase.  To fight growing complexity of the codebase, many companies allocate some percentage of their resources for refactoring, cleanup, and other activities that don’t directly result in features for the end user of the software. This really resonated with me. I am a huge fan of this approach. We do some of it here in the developer division (read about the MQ milestones here, here, and here), but I wish we and software industry in general did even more.

Filed under:
FxCop Designers Honored with the Chairman's Award
03 July 07 04:21 PM | kcwalina | 8 Comments   

Last week, during the annual Engineering Excellence week, several Microsoft engineers and managers involved in development of engineering tools and practices were presented with Engineering Excellence Awards. In addition, the principal designers of three static analysis tools were honored with so called “Engineering Excellence Chairman’s Award,” which is given for contributions that our chairman (Bill) considers especially important. The Chairman award was given twice in the history of Microsoft.

Mike Fanning, Brad Abrams, and I received nice glass statuettes and a framed letters from Bill and Jon (our VP responsible for EE). See pictures below. The letter says “The Engineering Excellence Chairman’s Award is the Microsoft’s highest award for engineering group employees worldwide.”

It’s extremely rewarding to receive something like that for what started as a hobby project on which we worked mainly in our free time (at least, before it was officially productized). I would like to thank Brad for being the “let’s do it now” person, pushing the whole effort of design guidelines and fxcop development, and Mike for his passion for quality and being the super-developer on the team. 

Of course, many others contributed to the success of fxcop. Once we gather all the names, we will post a new entry or update this one to thank everybody and record all the contributions for posterity. [UPDATE: Brad just posted on this here.] 


Generic Methods as Casts
07 June 07 10:56 AM | kcwalina | 3 Comments   

Somebody just asked me which of the following API design alternatives is better. They both do what we could call “casting.”


// Generic Method “Cast”

var foo = someInstance.SomeMethod<IFoo>();


// Simple Cast

var foo = (IFoo)someInstance.SomeMethod();

The Generic method approach can potentially have two benefits. A constraint can tell users what the subset of valid casts is. For example, the following API will allow casts to a collection (a subtype of IEnumerable):


public TCollection SomeMethod<TCollection>() where TCollection:IEnumerable {



If the user calls this method and tries to “cast” the return value to let’s say an Int32, the compiler with complain. For example,


var int someInstance.SomeMethod<int>();

… will generate the following error:


The type 'int' must be convertible to 'System.Collections.IEnumerable' in order to use it as parameter 'TCollection' in the generic type or method 'SomeClass.SomeMethod<TCollection>()'

Secondly, the Generic method might do different things based on the type parameter. The method relying on a simple cast has now knowledge about the type the user will cast it’s return value to.


public TCollection SomeMethod< TCollection >()

    where TCollection:IEnumerable,new() {


    TCollection newCollection = new TCollection ();

    ArrayList newArray = newCollection as ArrayList;

    if (newArray != null) newArray.Capacity = 0;

    return newCollection;


If neither of these benefits applies in your case, I would use a simple cast. It’s more transparent in terms of what’s going on. The users of a generic method might wonder what kind of “magic” is being done with the generic type parameter.

Framework design lecture avaliable for download
01 June 07 01:38 PM | kcwalina | 3 Comments   

I have good news for all who asked about an off line version of the API design lecture I blogged about a few weeks ago. After literally a hundred emails and comments on the blog (thanks for pushing me to get this done), weeks of trying to get this setup, including the difficulty of finding a server to host a 500MB file, and -- ultimately getting some help from Scott Guthrie (thanks!), the zip file is finally available for download here. Enjoy!

Silverlight - Program the Web the Way YOU Want It
05 May 07 09:36 AM | kcwalina | 1 Comments   

I just came back from Mix where we announced details of Silverlight’s programming model. This is pretty much what I have been working on for the last year and a half. It feels great to finally be able to talk about it. I will blog more about the details after I am back from my well deserved vacation.

But more importantly, I am supper excited that there is finally a real programming model for the Web. I am a system software developer, and to me, all existing web programming models felt like smaller or larger hacks. They are all based on technologies invented for something other than writing applications, but adopted to these scenarios over the years. For example, HTML was invented for representing documents with hyperlinks. This is quite natural for immature technologies, so I am not blaming anybody here :-).

When Silverlight’s vision started to crystallize, we realize that we have an opportunity to do the Web programming model right this time:

1.       Modern programming languages: In Silverlight, you can program using your .NET language of choice, whether it’s a traditional OO language like C#, VB.NET,  or C++, a dynamic language like IronPython or IronRuby, or a functional language like F#, … or choose from the plethora other 3rd party languages.

2.       State of the art markup: XAML really shines when you need the ultimate flexibility in representing graphics and GUI.

3.       First class garbage collected runtime: The runtime included in Silverlight (“Core CLR”) is basically the .NET Framework’s runtime with features irrelevant to the web programming removed (e.g. COM Interop).

4.       Large ecosystem of tools, information, and services: Silverlight’s type system is the same CIL type system used in .NET and the Silverlight Framework is simply a subset of the .NET Framework. This means the most if not all .NET Framework tools work or can be easily adopted to Silverlight. This includes Visual Studio, FxCop, .NET Reflector, MSDN, and new specialized tools like the excellent Expression Blend.

I already wrote a couple of small applications using Silverlight, and I have to say that it makes web programming natural for the first time. The platform no longer forces you to program its way, while your intuition and years of programming experience tell you to code some other way. It makes me say, for the first time in my life, that I am proud to be a web developer :-)

Filed under:
Nullable<bool> usage guideline
27 April 07 08:00 AM | kcwalina | 5 Comments   

I am starting to work on some updates to the framework design guidelines related to new framework and language features added in .NET 2.0, 3.0, and 3.5. One of such additions are the nullable types (Nullable<T>).

Coincidentally, somebody asked me today whether they should use Nullable<bool>. Here is the question:

Q: Do the guidelines have anything to say about the use of nullable types in public API? Subject came up here in context of a proposal to return Nullable<bool> from a method to retrieve an attribute value (null means attribute not found, true means value retrieved, false means no value for existing attribute).

… and in the absence of formal guidelines, here is what I recommended:

A: I would say that the rule of thumb is that you should use Nullable<bool>, if it’s obvious what all three values mean. For example, it there is an optional column in a database of type Boolean, it’s clear that true means true, false means false, and null means the value is not there. In your example, you had to explain what the values mean, so I would not recommend using nullable types.

Nourishing Creativity
24 April 07 05:39 PM | kcwalina | 0 Comments   

For those who haven’t heard about it, TED is a multidisciplinary conference for experts from technology, entertainment, and design industries. They just updated their web site and while browsing around it I found this very interesting presentation about creativity by Ken Robinson.

One of the main points Ken makes is that penalizing people for failing when they try new things is killing creativity. His talk concentrates on education systems, but I think the same mechanisms exist in the industry.

Filed under:
Online lecture on API design
29 March 07 11:31 AM | kcwalina | 30 Comments   

I gave a lecture on framework design at the Redmond’s Microsoft Research Center. They recorder and posted it on the Research Channel. You can see it here. It’s more than 3 hours long, but I think you will find it worth the time.  Let me know what you think.

Effective Presentation Skills
01 February 07 05:25 PM | kcwalina | 6 Comments   

I just watched a very interesting presentation. The content of the presentation is interesting, but not very relevant to the work software engineers do. The super interesting and relevant part is that it’s one of the best presentations I have ever seen in terms of the mechanics of presenting, and I think all who do presentations can learn a lot from it.


1.       The presenter wanted to communicate just one relatively simple thing that not many people pay attention to, so he had to capture the audience’s attention and he did a very good job doing it.

2.       The presentation has lots of content, but the content is just to support the main thesis; it's not a laundry list of things he wanted people to remember (that it almost never successful).

3.       The presentation shows the power of visual communication (and software). The same information presented in a static table, bullets, etc. would completely fail in communicating the main message.

Filed under:
More Posts Next page »
Page view tracker