Scott Guthrie is well known in the .NET world as being the main architect/designer of the ASP.NET framework. He has a very popular blog which is pretty much a press release blog for all Microsofts Web development technologies: ASP.NET, Silverlight, etc. On top of that he is extremely well respected amongst the .NET community and much of what he say's taken to be absolute "word" on best practices and usage of the Microsoft Web technologies.

One thing about his blog, and which I mentioned above, is that it is less of a blog (commentry, opinion, et al) and more of "press release" platform that the commmunity uses to see what's going on with the various Web technologies. Often times his posts are showcases for the various API's that will soon be released and are very tutorial based:

1. Here is the feature
2. This is the problem it solves
3. This is what it does
4. This is how you do it

Occasionally he'll post work arounds for various issues that developers are facing with technologies, integration or Visual Studio. However, one thing Guthrie rarely does is give an opinion or directly address the community. That is until this recent post in which he discusses the merits of technological debates and his opinion about them. To be honest I agree with him most wholeheartedly about most of his points, but then he begins to speak specifically about ASP.NET Web Forms and ASP.NET MVC debates and again while I follow him for the most part, at one point he really loses me. This assertion in particluar:

"d) I often find debates around programming model appropriateness and abstractions a little silly. Both Web Forms and MVC are programming web framework abstractions, built on top of a broader framework abstraction, programmed with higher level programming languages, running on top of a execution engine abstraction that itself is running on top of a giant abstraction called an OS.  What you are creating with each is HTML/CSS/JavaScript (all abstractions persisted as text, transmitted over HTTP – another higher level protocol abstraction)." 

What he is referring to here, is really the ongoing debate about whether or not ASP.NET WebForms is a "Leaky Abstraction"...here he is trivializing the argument via hasty generalization: "all things software are abstractions, thus all abstractions are good!" This is simply not true. While abstractions are all around us and for the most part are good, many times the abstraction causes more harm than good and MS has a history of creating these type of abstractions and many long-term developers are leery of such solutions.

To be fair, he does qualify his point with the following statement:

"The interesting question to debate is not whether abstractions are good or not – but rather which abstractions feels most natural to you, and which map best to the requirements/scenarios/developers of your project."

However, I feel that he does this not to clarify his point, but to qualify the agenda of the entire post:  WebForms is a good abstraction! However, after working with WebForms since 2002, classic ASP before that, and ASP.NET MVC now, I (and many others) disagree! I think many parts about WebForms are poor abstractions, in fact I am even leery about some of the newer features in ASP.NET MVC 2, but that's another story.

In fact, most of the poor abstractions that exist with WebForms were put there specifically to "shield" developers from the "complexity" of Web development. For example, in the late 90's there were many, many developers who had never developed anything other than desktop apps. To them, learning another technology such as HTML, CSS, or Javascript was a major blocker in moving from desktop to Web development. WebForms gave them what they thought they wanted: a nice abstraction over HTTP and HTML. Instead of hyperlinks, you got buttons. In place of POST and GET you got postbacks and events. This was all nice and good...for awhile.

However, pretty soon the abstraction became a hinderance. SEO became increasingly important and the ugly HTML the WebForms generated became a hinderance and developers had to clear huge hurdles to get the output clean enough to pass an SEO requirement. If it was possible at all. Additionally, the code behind concept created a great place for developers to combine BL, markup (oh, yes), data access, binding, html behavior (javascript),  hackery, etc... into a single co-dependent layer. Seperation of concerns was rarely (from my experiance) practiced as the framework itself lent itself this collusion of sorts.

In the end you get better and better at simply working around the limitations of the abstraction, instead of learning more about what the abstraction is trying simplify. This is bad in so many ways.

A better way to re-phrase Scott's qoute above would be: "The interesting question to debate is not whether abstractions are good or bad, but if the particular abstraction solves the problem is purports to and whether or not it causes more good than bad. If not, it is a poor abstraction." The debate is not about abstractions, it is about specific abstractions that cause developers more grief than good!

I just spent a frustrating two hours trying to get a unit test to run via Resharper for nada. The test would start and then exit as if the it was working but instead of showing a green or red icon as expected when the test was finished, it would remain 'grayed' out. I tried the usual: delete bin folders, run solution 'clean' via VS2008, delete the code directory and do a fresh SVN checkout. I even rebooted for nothing: no red, no green all gray:

I finally noticed that I had closed the output window of VS, so I couldn't see the build results. When I opened the output window I saw this exception at the very bottom of the list:

A first chance exception of type 'System.Configuration.ConfigurationErrorsException' occurred in System.Configuration.dll
A first chance exception of type 'System.Configuration.ConfigurationErrorsException' occurred in JetBrains.ReSharper.TaskRunnerFramework.dll
The program '[1012] JetBrains.ReSharper.TaskRunner.exe: Managed' has exited with code 0 (0x0).

What the f#*k? A configuration error was causing the Resharper taskRunner to die quietly? You have to be kdding me! Shouldn't the user be alerted if the software could not recover and had terminate? I mean, yeah it _did_ notify me, but not very explcitly - a pop up would have been nice!

Anyways, issue was found: I commented out the starting element of the ConnectionStrings section of the App.Config and when Resharper process tried to load the config it bombed. Crises averted, now back to work.

Note: This post was motivated by a 3 hour discussion with a release manager regarding why the name of the release was the same as a feature that we had pushed to a future release – “If feature x has moved to release y, why are we still releasing a build called feature x."

Why? Simple, it holds you and/or the team accountable for releasing the feature in that release on the planned date. This doesn't sound so bad one would think. After all, the feature was conceived hopefully from some end user or business need, feasibility was assessed, and the sprint was planned with dates engraved in stone. The reality is that while LOE can be estimated, there are additional factors at hand that wreck havoc on what will be completed by the cut-off date.

Typically, common cause variance can be mitigated and the estimate included in the original LOE, however the same cannot be said for special case variance.  For example, you can pretty much assume that a certain amount of effort will be attributed to research and discovery, before the developer even starts working on the task or feature. While in the exceptional case a developer may have sufficient domain experience to simply start coding a whip out the feature, the rule is that the developer will have to spend time familiarizing them with the environment, before jumping in. This is expected to cause a certain amount of containable variance with respect to a project or sprint. However, how do you reasonable plan the case where another developer on the team contacts some grave illness, such as swine flu and is not available and reduces the number of resources available?

In cases such as this, we simple do not plan for these special cases, because it is virtually impossible. If you did try to plan for them, you would never finish planning because there are an infinite number of things that can happen. It costs too much to plan for these types of things!

Back to my original point, when you name a release after a feature you commit yourselves to completing that feature and releasing it on the planned date, however you omit the possibility of special case variance affecting the outcome. In which case you still want to release something so maybe you release another, less resource feature; but the release is named after the feature that was omitted…this is awkward (especially for the build engineer).

You will communicate your intentions better (i.e. the goal is a release, not necessarily the release of a specific feature) if you name the release after some arbitrary name not tied in directly to a feature.

A non software related tale today. Lately I have been amazed about all the 'Green Shoots' stories spun out by the media regarding economic recovery. Driving into work I heard, "Stocks open strong on good news regarding a housing recovery"....what? Well, I checked Marketwatch to see what this "good news" was and saw the following article: "US Stocks Turn Positive After Upbeat Home Sales Data". Wow, home sales climbed 9.7% in july and up 8+% year over year? Year over year growth in this economy is definitluy something to get excited about. I then turned to comments section and found this whoopee of a comment:

"As other have said countless times, please do your due civic duty of accurately reporting the facts. There is no need for the added spin MW. I feel really sorry for the editor because the constant spin is in the articles while the truth is filled up in the comments section. While we all appreciate being given the opportunity to engage in discussion, it is sad when we have to hunt down the facts on our own time. We can handle the truth so please just report the stone cold facts and let us make our own judgments and interpretations. Welcome to reality.

U.S. Existing Home Sales Yr/Yr
$0 – $100,000 Up 38.8%
100,000 – $250,000 Up 8.7%
$250,000 – $500,000 Down 6.2%
$500,000 – $750,000 Down 8.9%
$750,000 – $1,000,000 Down 10.6%
$1,000,000 – $2,000,000 Down 23.3%
$2,000,000 + Down 32.4%

Source: National Association of Realtors"

Original comment is here.

And I thought, what's the real story here? Sales of bottom of the market are up, but the mid-high level is way down. Nothing real exciting here given the 8k government subsidy and the risk taking nature of first time buyers. A little more research gives a more realistic view of the current housing market: Existing Homes: WhatsReally Selling.

The media spin machine appears to be working overtime; to bad the millions of unemployed in this recession/depression aren't feeling so peachy.