When I first started using ASP.NET in mid 2001, it seemed so straightforward. There was only one *right* way to do something. The framework was manageable and after spending about 6 months working in it day-to-day, I felt like I pretty much knew the whole thing. In many ways, it was like the early days of Java in the late 90’s when I could get one O’Reilly reference (I think it had a tiger on it?) and grok the entire framework.

Now books on either framework span multiple volumes and even the best developers cannot keep it all in their head. You’re now forced to specialize, and even then there is a sinking sensation that you don’t know it all. It’s become harder to be an expert on ASP.NET and the .NET framework due to its exponential growth over the past few years. There are coders somewhere in a bunker at Microsoft that do nothing but crank out new framework classes. And they’re writing them faster than people can keep up.

The Paradox of Choice

In some ways, choice is good. We now have many many options about which ORM to use (NHibernate, LINQ2SQL, EF, etc). But all of these options also causes stress and sometimes inaction. It’s called the paradox of choice and is expertly chronicled by Barry Schwartz in his book:

    Participants … showed the pattern of reluctance to make trade-offs whether the stakes were high or low. Confronting any trade-off, it seems, is incredibly unsettling. And as the available alternatives increase, the extent to which choices will require trade-offs will increase as well.

Have we reached the point where we have too many choices and trade-offs in the ASP.NET world? Let’s look at our choices for IOC containers from Hanselman’s Blog:

Castle Windsor based on the Castle MicroKernel.

StructureMap has been around since June 2004

Spring.NET Licensed under Apache 2

Autofac intends to be IoC with a C# 3.0 flavor, but also supports 2.0.

Unity Licensed as MS-PL

ObjectBuilder was formerly MSFT’s only public foray into DI/IoC

Puzzle.NFactory Part of the larger Puzzle Framework

Ninject formerly "Titan"

S2Container.NET on version 1.3.7. Port of Java’s Seasar2

PicoContainer.NET Port of Java’s PicoContainer

LinFu Licensed under Lesser GPL

Wow! I’m exhausted from just reading that list let alone trying to investigate each.

With the explosion of all of these frameworks and choices is .NET destined to become the next Java – overburdened by its complexity and just waiting for the next new kid on the block to win over developers with its simplicity?

Less is More

If only there was a web framework that told you which approach it preferred – an opinionated framework if you will. And what if that framework used sensible defaults and chose the “standard” ORM that works for 99% cases without any configuration or angle-bracket wrangling.

Isn’t that the allure of Ruby on Rails? It’s sooo shiny and sooo simple…

In fact, it’s been winning over .NET developers right and left. Can Microsoft stop the bleeding?

Microsoft to the Rescue?

Luckily Microsoft is not idly standing by. I was glad to see on a recent blog post from ScottGu that a core focus of upcoming .NET versions would be simplicity. They don’t want to lose those developers that are overwhelmed by the amount of options and they realize that too much configuration and too many options can actually be bad.

An excellent example, is the new Web.Config file in ASP.NET 4.0. In current versions of .NET, the Web.Config file is littered with years of accumulated settings involving: session state, ajax dll redirects, http headers, and authentication settings. In short, it’s a convoluted mess.

From ScottGu’s post, here’s what a new “clean” web.config file will look like:

Now THAT’s what I’m talking about! I feel better already.

So, there is hope. We’ll see what other features VS2010 gives us and cross our fingers that they continue to give us “less” rather than “more”

One of the most difficult aspects about being a programmer is the fact that almost nothing you’re writing now will still exist in 15 years. It’s one of the truisms of our profession that change happens FAST — much faster than other professions.

At the end of your career there will be almost no legacy of running production code. That’s a bitter pill to swallow especially if you are a software craftsman who takes pride in his work.

For example, let me just take you through a brief stroll through the software graveyard by mentioning names like:

• Word Perfect
• Lotus 123
• Windows 3.1
• Geocities (which incidentally just shut down)

This is software that used to rule the world just a a decade ago and is now piled onto the trash heap of history. It gets even worse than that though. If you were the lucky guy who wrote the first version of Word Perfect, most likely, very little of code still existed by version 9.

And these were industry leaders. As good as you are, odds are you are not writing the next Word Perfect. You are probably writing a line of business application with a half-life of 5 years or less.

So should we be thinking about this while writing code today? It’s temping to just say that it will be rewritten in a few years so what’s the point of making it perfect. But therein lies the answer.

Code is never perfect and almost always has some kind of bug or breaking point if stressed hard enough. Imperfect people simply can’t make perfect code. The key is to make the code better with each iteration.

Change in the software industry is inevitable so why not embrace it and strive to make the code better each time you touch it? This is similar to the idea of not leaving broken windows in code:

The “Broken Window Theory’’ has inspired police departments in New York and other major cities to crack down on the small stuff in order to keep out the big stuff. It works: keeping on top of broken windows, graffiti, and other small infractions has reduced the serious crime level.

    Don’t Live with Broken Windows

Don’t leave “broken windows’’ (bad designs, wrong decisions, or poor code) unrepaired. Fix each one as soon as it is discovered. If there is insufficient time to fix it properly, then board it up. Perhaps you can comment out the offending code, or display a “Not Implemented” message, or substitute dummy data instead. Take some action to prevent further damage and to show that you’re on top of the situation.

Like a topic that I often write about in my other blog, we as software professionals need to focus on continually improving our code (and skills) rather than writing it once for eternity.