Kobe outrage – why?

Over the last couple days, I've seen a small firestorm erupt over Microsoft's Kobe MVC sample project.  First out of the gates was Karl Seguin, with a rant about all sorts of coding ills found in the source.  Then, today, I saw another great post that breaks down some specific problems with duplicate lines and cyclomatic complexity.

My first reaction was to share in the shock and horror of it all -- after all, how could Microsoft issue a sample app so obviously riddled with problems, but as I thought about it some more, the real issue became obvious:

Real-world apps deal with this sort of coding all the time.

You see, very few apps evolve in environments that are conducive to crafting museum-quality code throughout the entire application.  Very few software teams, in fact, are comprised entirely of developers who are capable of crafting this sort of code.  Our development teams have imperfections, and so do our systems.

Maybe Microsoft should have been held to a higher standard because (a) they're Microsoft, and (b) this is a sample application where the primary deliverable is the source code itself.  That's valid, but what's more interesting to me is that this brand-spanking-new framework is so damned easy to mangle and abuse!

As architects and managers, one of the most valuable long-term effects we have on the software we develop is to leverage good ideas across our teams and our code.  It's not sufficient that we can dream up the perfect architecture and the perfect solution if it stays in our heads.  The real measure of effectiveness is how well we can project these good ideas across the entire breadth of code in all of our systems, and this is where our current tools fall short.

Developers love C# because you can do anything with it.  It's a fabulously-flexible tool.  Architects try to impose order by mandating the use of standards, frameworks, and constraints.  It's a perpetual tug of war.  We're supposed to be working together like an orchestra, but in most cases, we're still a bunch of soloists who just happen to be on the same stage.

In Kobe's case, the mere fact that people are opening up this code and recoiling in shock because the code doesn't look the way they expected is proof that we're not where we need to be  -- on many levels.

Related articles by Zemanta

• Avoiding the high cost of bad code (infoworld.com)
• Microsoft Embracing Open Source? (solutionset.com)
• Drastically leverage your Code Reviews (codebetter.com)
• Introduction to the ASP.NET MVC Framework (codebetter.com)