The CSS Friendly Control Adapters were never an official product.

That’s right, they were code samples that accompanied a white paper illustrating how to extend the System.Web.UI.Adapters.ControlAdapter class shipped in .NET 2.0.  The fact that these were released as sample code is clearly noted in:

• The summary of the white paper (”This white paper discusses control adapters in general and a sample set of adapters in particular. The samples demonstrate how you can adapt controls so they are easier to style with CSS…“);
• On the main entry page (”These sample control adapters demonstrate…“); and
• On Scott Guthrie’s blog post announcing the toolkit (”This toolkit provides information about how the ASP.NET 2.0 Control Adapter Architecture works, as well as a set of 5 sample control adapters (with full source that you can optionally tweak/modify)…“).

I think it was very clear from the beginning that this was sample code to accompany documentation.  As such, I’m not sure where the author’s expectations came from.  Sample code is never intended to meet everyone’s needs, to be robust and full-featured, to be bug-free, or even to be maintained.  It is written to illustrate a concept.  Microsoft never “promised” anything with this code.

Microsoft never “withdrew support”.

Remember, this is sample code; it exists as part of official documentation to illustrate a concept.  This piece of official documentation is still hosted and provided by Microsoft at www.asp.net/cssadapters, with a forum that is still visited by the original developer.  The base classes originally released in .NET 2.0 are still there in .NET 3.5.

Quite the opposite of withdrawing support, Microsoft released the code under the MS-Permissive license to allow re-use and then went a step further — they listened and responded to the community that sprung up in the forums by turning over future direction and development to the community.  You can read through the forums if you want to know more of the history.  The community wanted to have control of this code, and expand upon what Microsoft had done since Microsoft had no intention of doing so itself.  Microsoft listened, and gave the community what it asked for.

So what is wrong?

I’ve never been a Microsoft apologist, and I’ve been a frequent critic of their products, their marketing, and their business practices.  But let’s give credit where credit is due. I applauded the decision to open source this code, and it turned out to be an early sign of a much more open and transparent way of doing business within this sector of the .NET division (cf., ASP.NET MVC).  While the author blames Microsoft for the lack of maintenance, that is entirely the fault of the community.  Let’s address a couple other common misconceptions within the Microsoft community.

1. The rate of binary releases does not reflect the health of the project. The author seems to think that the project is dead because there haven’t been any further binary releases since the move to CodePlex.  This seems to be a common view in the Microsoft ecosystem. In fact, the CodePlex site shows that there has been a regular (but not frequent) stream of code commits, including three commits so far in 2009.  In open source software, changes to the source are the key indicator of a project’s health, though things like project maturity obviously play a part in determining rate of change.
2. Open source software is not freeware. Freeware is simply software that you aren’t asked to pay for. Open source software is software that you have the ability to fix for yourself. At least since April 2007, only one person has committed any code.  In the forum thread where Microsoft “handed over the keys”, the current maintainer posted, “If anyone wants to be added to the developer list, send me your CodePlex user name and I’ll set you up.”  As of today, there are only four other developers listed in CodePlex and none of them seem to be actively contributing.  That’s a failing of the community, not of Microsoft.  The “you owe me” and “why don’t they fix it?” attitudes seems to be much more common in the Microsoft community than in the Java or Ruby communities.  Rather than complaining, send in a patch, as others have done.  Patches are almost always welcome, and they benefit everybody.

Ultimately, the technical problems noted by the author are the fault of the community, not Microsoft. The community has the power to fix the code, but few have stepped up to the challenge.

Microsoft is ultimately to blame for the situation.

Wait… what?  At the top, I said I agreed 100% with the author’s main conclusion, and I do:

Microsoft needs to redesign their server controls to emit accessible, semantically meaningful, layout-table-free markup from the get-go. In my opinion, they really dropped the ball by not doing this in ASP.NET 3.5. If that had meant retaining some legacy 2.0 server control versions alongside their 3.5 counterparts, so be it. I can understand needing to maintain backward compatibility with 2.0 and not wanting to break existing sites. But that’s no reason to hobble designers who have long since abandoned layout tables.

Isn’t it about time Microsoft stopped kicking this can down the road? I mean come on, it’s 2008 for chrissake. Is lean, mean, and meaningful HTML from ASP.NET server controls too much to ask for at this point? If you ask me, it’s an idea whose time is long overdue.

That really is the bottom line.  If Microsoft had built their controls to emit standards-compliant markup from the beginning, the entire ControlAdapter architecture would have never been necessary.  It is an ugly hack, but sadly necessary if you want to use WebForms and accessible, semantically meaningful HTML without rewriting all your controls from scratch.  And that is what’s wrong with the CSS Friendly Control Adapters — the simple fact that they are necessary.

In term of their implementation, the CSS Friendly Control Adapters are a good 90% solution, and the ones I’m using in my current project do everything I want.  They aren’t perfect, but when I look back at the code I wrote last week, or last month, or last year, I can point to a lot of decisions I regret more than my decision to use these adapters. As long as I’m doing WebForms, I will continue to use them.

About the same time I decided to start blogging, I started getting some pretty significant pain and numbness in my right hand, typically extending from the outside of the wrist up through the tip of my pinky finger and part of my ring finger, occasionally radiating intense pain up the back of my forearm to my elbow.  At the time, I figured it was probably from a combination of resting my wrist on the hard edge of my mouse platform, and too much lateral wrist motion when using the mouse.  I took immediate action, buying new hardware and attempting to reduce my mouse usage.

For the hardware side of things, I replaced my mouse with a Logitech TrackMan® Wheel.  The design was a little awkward to adjust to at first, but it addressed both of my concerns. First, it eliminated the hand/wrist/arm motion required for moving the cursor.  Moving the cursor with the TrackMan is done by scrolling a giant ball with your thumb, while your hand remains stationary.  Second, the larger size of the device helps me maintain a better wrist posture, elevating the joint off of the mouse platform.

My strategy for reducing my mouse dependence had two components.  While working during the day, I practiced using more keyboard shortcuts and memorized them.  While off the clock in the evenings, I practiced staying away from the computer.  That meant no scouring eBay for rare audio recordings, no touching up photos of the kids, and no blogging.

Did it work?  Yes and no — it didn’t continue getting worse but it didn’t really get better, either.  So I finally went to the doctor, who referred me to a physical therapist, who conclusively determined that the problem was due to compression of the ulnar nerve in the elbow, i.e., cubital tunnel syndrome, possibly accompanied by additional compression in the wrist.  The likeliest culprit seemed to be the arm rest of my chair.  I had lost significant strength in my right (dominant) hand, and embarked on a month of physical therapy.  I did exercises to restrengthen my hand, wrist, and elbow, and exercises and ultra sound to help my nerve repair itself.  At the end of my course of treatment, I felt 98% better.

Then it got bad again a few weeks later, despite my new awareness and my ergonomic changes.  Finally, something clicked in my head (figuratively, I think).  I’d gotten into bed one evening and started having the really bad pain from my elbow to my finger, and remembered some questions the therapist had asked when I first went in for my evaluation.  I realized that I’d been sleeping for some time with my right hand under my pillow, my elbow bent in as far as it would go, pinned in place by my giant skull.  I got out of bed, splinted my elbow with a towel, and eventually fell asleep.  I slept with my elbow splinted for about a week and a half, and that seems to have fixed the problem.  I’ve since had a couple recurrences of the pain, but each time that happens, I splint my elbow at night and it gets better pretty quickly.

So now that I’m recovered from that, the holidays are over, and work has slowed down a bit, I’m going to give this another shot.  We’ll see how long it lasts!

I know some of you are probably saying to yourselves, “what is the ALT.NET movement”? In short, the movement is a growing community of .NET developers who are frustrated with the tooling and guidance provided by Microsoft, as well as the closed, insular nature of the .NET development community.  The movement is aimed at educating the .NET community and showing that there are proven alternatives to “the Microsoft way” in terms of software architectures and that there are mature, viable alternatives to the development tools produced by Microsoft.  So why is this important?

These Lessons have Already Been Learned

There are countless examples of proven practices and tools that are common in other object-oriented environments from Smalltalk to Java to Ruby that Microsoft has been slow to embrace or promote in .NET. Automated unit testing and test-driven development (TDD) have never been given much support from Microsoft, yet it is an important part of a quality-first approach and has long been a core practice in Extreme Programming.  Model-view-controller (MVC) architectures have been around since 1979 and are widely used in other object-oriented platforms like Java.  The wildly popular Rails platform for Ruby is based around an MVC architecture.  Yet it has never been promoted by Microsoft, and has always been difficult to do in ASP.NET.

Object-relational mapping (ORM) is another architectural pattern that has long been ignored (and even dismissed) by the .NET community.  Object-oriented design produces models that are conceptually very different than the models used by relational databases, resulting in an “impedence mismatch.” An ORM framework aims to mask the complexity of this mapping, allowing object-oriented software to evolve independently of its relational data store.  Hibernate has practically become the standard ORM in the Java world since its creation in 2001. It is integrated with all the major application frameworks and is even used by Google.  Why not apply these lessons to .NET development?

Your Job Could Be Easier

In the mainstream Microsoft development community, the majority of the focus is placed on data-centric architectures and rapid application development through visual tooling.  Chances are that if you’ve ever worked on larger-scale projects, or systems that need to evolve over time or be maintained for any period of time, you’ve run into problems with the Microsoft way and encountered pain.  The Microsoft endorsed approach to data access has long been to work from the data model, building stored procedures, and accessing the procedures through data access objects (DAOs).  Using code generation techniques, this can be a fairly fast process, using metadata to create both the stored procedures and DAOs instantly.

But what happens next?  What if you’ve put business logic into the stored procedures?  What if you’ve customized your DAOs?  What do you do when you have to add new columns to one of your tables?  You end up having to manually update your insert procedures, your update procedures, and probably a handful of retrieval procedures.  Then you have to update all of your DAOs to match the updated procedures. You may end up with some DAO methods that only partially populate your business objects. If so, you have to mentally keep track of how you got the data and whether that particular method returned all the data you need.  And how would you go about unit testing your application?

If you’re working on a small project, or a throwaway prototype, this might not be a big deal.  On the other hand, if you’re working on a larger project or if your system is evolving from month to month over a year or more, you’ve got a lot of pain ahead of you.  Why not use an ORM?  Microsoft is finally getting with the times and releasing their own ORM solutions, like the Entity Framework and Linq, but these aren’t the only options. In fact, they may not be the best options for you.  Both are in their 1.0 releases and have limited support for databases beyond SQL Server.  Mature alternatives exist.  For example, NHibernate is a .NET port of Java’s Hibernate ORM framework.  It is built on a solid foundation, backed by 5+ years of experience and lessons.  It supports all the major databases out of the box, and can be easily extended. It performs well. It is built on top of ADO.NET, and makes it fairly easy to use custom SQL or stored procedures using the ADO.NET API you’re already familiar with. Plus it is an open source tool, meaning that there is zero cost involved.

The point here isn’t that you should always use an ORM, or that you should use NHibernate rather than Entity Framework or Linq or some other .NET ORM like WORM or LLBLGen.  The point is that mature, viable alternatives exist.  MVC frameworks like Castle MonoRail and Spring.NET have evolved from implementations in the Ruby and Java worlds.  Unit testing frameworks like NUnit and MbUnit are free and have been around a lot longer than Microsoft’s current offering, which is still only available with the professional edition (or higher) of Visual Studio 2008.  One of the primary objectives of the ALT.NET movement is to increase awareness of these alternatives within the .NET community.

Microsoft is Listening… and Responding

This movement wouldn’t be so important if Microsoft wasn’t listening.  Fortunately they are, and the ALT.NET movement is already having a huge impact at Microsoft itself.  The movement was named by Microsoft MVP Dave Laribee in April 2007 and quickly gained momentum in a segment of the MVP community and the .NET open source community. Over the next several months, Microsoft made a number of key hires from within this community, including high-profile bloggers like Scott Hanselman in July and Phil Haack and Rob Conery a few months later. This instantly created high volume, high impact dialog between Microsoft’s development teams and the ALT.NET community, and showed Microsoft’s commitment to the community.

These people weren’t brought in to act as Microsoft marketing drones, either—they are programmers, after all. They joined Scott Guthrie and company in the developer division to lead work on the ASP.NET MVC framework.  In October, the framework was publicly unveiled at the first ALT.NET conference in Austin, Texas.  The framework itself shows that Microsoft is listening, and is truly acting on a lot of the feedback it receives.  It is designed to be extensible and integrate with current open source IoC containers like Windsor, Spring.NET and StructureMap.  It is designed to be testable, and Microsoft has provided guidance on creating testing templates for open source testing frameworks like NUnit, MbUnit, and xUnit.net.

In March 2008, MSDN Magazine focused on a number of ALT.NET topics, including the ASP.NET MVC framework, the concept of inversion of control (IoC), and the process of continuous integration. The issue concluded with an article from Jeremy Miller entitled “What is ALT.NET?”.

More recently, the ALT.NET community has expressed serious concerns about Microsoft’s new Entity Framework.  The EF Team responded to the concerns, and while no changes will be made to the upcoming release, the response was both quick and candid, and pledged a more transparent design process going forward.  Hopefully they will follow the lead of the ASP.NET MVC team.

At any rate, Microsoft’s commitment seems clear. The ALT.NET movement will continue to have an impact on the tools and guidance released by Microsoft, and that will have an enormous impact on all .NET developers. If you’d like to try to make sense of it all, look beyond Microsoft to the ALT.NET community. Hopefully ALT.NET will continue to expand its outreach into the broader .NET community, providing guidance on non-Microsoft tools and continuing striving to incorporate ideas from other developer communities into mainstream Microsoft development.

More Resources

If you want to stay informed about your options as a .NET developer beyond the Microsoft press releases, or want to learn more about how practices and patterns from other platforms can be applied to .NET development today, the ALT.NET community can help.

• “What is ALT.NET?” by Jeremy Miller, March 2008 issue of MSDN Magazine
• “ALT.NET important to the viable future of the Microsoft ecosystem” by Udi Dahan, October 2007
• ALT.NET Yahoo Group
• Altnetpedia
• CodeBetter.com
• Alt.NET Podcast

Hopefully it is obvious from the title of this post that I chose the third path. Object-oriented programming (OOP) is not a trend.  It wasn’t invented yesterday, and it isn’t going away any time soon. When Microsoft released the .NET framework in 2002, forcing the legions of Visual Basic programmers to learn the new object-oriented VB.NET or perish, that was as clear a signal as any that not only was OOP here to stay—it was the mainstream.

I wasn’t starting completely from scratch. The computer science curriculum from the late ’90s placed a heavy emphasis on OOP, and I learned it via C++ and Java during that time.  Still, eight years away is a long time and I had a lot that I needed to relearn and I’d developed a lot of habits that I needed to unlearn. The industry hadn’t stopped to wait for me, either. Agile development practices now seem intimately linked to OOP and provide a framework of best practices for ensuring quality. Meanwhile, my family still expects to be fed, and my clients still expect me to deliver software.

I am starting this blog in large part to share my experiences learning OOP and agile development. In the May/June 2008 issue of CoDe Magazine, Microsoft MVP Jean-Paul Boodhoo wrote a terrific article called “Individuagility” in which he outlines his approach to teaching agile development. His steps correspond fairly neatly to my own experiences so far. The last point in his list does a great job of summarizing why I have undertaken my personal journey, and why I am documenting it:

Become a student of your profession. Most of the people who embark down this style of development do so because they have a passion to want to deliver applications that both please the user as well as please other developers who maintain the code. Like anything else in life, if you want to excel in anything you have to be willing to sacrifice a little. What does this mean? Make a commitment to read a book a month. Take time to download a tool you have no idea about and start spiking it. Speak at a user group. Write a magazine article about your learning. Passion breeds passion. If you get infected, more often than not, others around you will want to take part in the learning that you are going through!

Hopefully I’ll be able to impart some of my passion and advice, and motivate others to start or continue similar journeys.  My goal is one post per week, but as this post is just an introduction I’m going to try to follow it up in the next day or two with some actual content.  Stay tuned!