Cwalina's Framework Engineering Lecture Posted
In my mind the single most important aspect of any system is usability. Unless the context states otherwise, when I use the term "optimize" or "efficiency" I am always always talking about usability optimization and efficiency. Things can be fast with a small footprint, but if you can't figure out how to use it right away or continually confuses your methods for your fields, then it doesn't really matter. Fortunately, Microsoft agrees with this. The days of every company writing their own coding-guidelines are gone and we .NET developers been unified under the great Framework Design Guidelines ("FDG") that Krzysztof Cwalina and Brad Abrams have so graciously given us.
To help further the unity in the community, Krzysztof recently posted a lecture on his blog entitled "Framework Engineering: Architecting, Designing, and Developing Reusable Libraries". Here is the abstract of the lecture:
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.
This video is, of course, not the only video on such an incredibly critical topic. Many years ago, Brad Abrams (and friends) gave a lecture series to Microsoft employees on the topic of framework design guidelines. These videos don't just cover the critically important topic of name guidelines, but also CLR performance topics, interopability guidelines, security topics, as well as various others. It's a video series that's essential to serious .NET development.
More importantly then these videos though, is the classic work produced by Krzysztof and Brad entitled "Microsoft Framework Design Guidelines". At the time of this writing, this book has 28 Amazon.com customer reviews and is still at five stars. Look at a few of the review titles: "A must have for any C# Developer or Architect", "For the individual who wants to rise above the masses", "If you only ever buy one .NET book, make it this one", "AWESOME * 10 = MUST HAVE;" and my personal favorite: "Passionate About Quality?" These reviews give you a good idea of the level of community acceptance that the framework design guidelines have. One reviewer even said "I would pay $5 per page for this book, and have found it to be, by far, the most outstandingly useful technical book I've read." This book covers in detail many of the aspects (and often times more) that have been covered in the videos. In fact, the videos are actually on the DVD that comes with the book.
The book is also not simply a set of laws. Throughout the book Microsoft architects and major Microsoft community leaders like Jeffery Richter make comments on various aspects of the framework. Sometimes they explain why a rule is stated in a certain way and other times they emphasis how crucially important a rule is. A few of the comments in the book explain problems in the .NET framework stemming from the fact that the guidelines were still in development (people used to say C# looked like Java-- well, many people used Java's nearly obfuscated coding standard!) At one point in the book one of the authors explains a usability study for .NET streamed and right-out admitted what most of us already know: .NET streaming is extremely non-intuitive!
Many times I hear people say that the success of the .NET framework comes from it's extremely efficient garage collection model, it's flexible common language runtime (in contrast to Java's platform runtime) and it's powerful JIT model. All those things are crucial, but ease of use is even more at the heart of .NET. Abstraction in framework design can be defined as the increasing of the semantic value or usability of any entity and it's at this point where we can see .NET far outshine Java and PHP. I've all but forgotten how to work with pointers, but it's when I forgot my coding standard that I'll start to become obsolete. It's been said that the success of Windows was driven by the very open nature of the Win16/Win32 API. Similarly, I highly suspect that it's the the beautiful abstraction with extremely high usability that explains .NET's sheer success. There's only so much marketing can do; at some point a product has to stand on it's own (even then, Programmers can see though marketing!). This beautiful abstraction and extremely high usability if course due to the existence and enforcement of the FDG.
To be clear, when I talk about FDG, I'm not simply talking about FXCop rules. I typically break the .NET framework rules down into three levels: CLS-compliance, FXCop compliance, FDG compliance, and the iDesign standard. If you do not strictly enforce CLS-compliance, then you may very well be completely stuck in the next version of .NET. Who knows how non-Microsoft compilers will become. FXCop will catch problems in your CLS-compliance and it will also catch many of the FDG violations as well. The FDG rules, however, also cover various aspects of security and performance that only a human can check. Lastly, when people often mention the FDG, many times what they really mean is the iDesign standard, edited by Microsoft Software Legend Juval Lowy.
In fact, I often use the terms "Framework Design Guidelines" and iDesign standard interchangeably. They aren't the same thing, but in some contexts it's acceptable to mix them. Whereas the FDG is primarily for the public interface of a framework, the iDesign standard covers both the public and internal. The term "iDesign standard" may not be familiar to all, but what represents is. It's been the .NET coding defacto standard since 2003. In fact, when you crack open any APress, Wrox, or Sam Publishing book, you will probably be looking at code following the iDesign standard. Further, the default settings for Visual Studio is the iDesign code layout.
Every .NET developer knows it and just about everyone follows it. Some may think the iDesign standard is optional and since it covers private code and in a sense it is optional, but, to be sure, if you are following the FDG rules and the iDesign standard, you have immediately chopped the learning curve of your system by an enormous factor. Also, if you ever go public with your application (i.e. go open source), you will need to make sure you follow the FDG standard (which includes CLS and FXCop compliance) and the iDesign standard. Otherwise, your system will probably have virtually no acceptance.
In closing, I should mention that Krzysztof Cwalina and Brad Abrams are releasing the 2nd edition of their famous book, due September 29, 2008. You can, of course, pre-order on Amazon. You can be sure that I will!