Kobe – Oh Dear Lord Why?!

Microsoft has kindly decided to remove the download and fix the issues before re-releasing it. Additionally, there’s a good dialog going on, mostly on twitter, but also on Phil Haack’s blog. Ayende also posted 7 or so posts about Kobe and related topics, which are worth a read.


Roughly 4 months ago I nerd-raged all over the efforts of a small team at Microsoft who put together a sample MVC application. Despite some pretty loud outcry, the response at Microsoft was pretty slow and definitely felt like “We’ll just wait them out” (which they did). Today Microsoft released the 2nd official MVC sample application – the Kobe Web 2.0 Resource Kit. Sadly, Kobe is on equal footing as far as craftsmanship and quality (on a related note, I’m will no longer be travelling to any NW parts of the US for fear of getting beaten up).

Now, before I go into details about some of the specifics, there’s a couple things we should probably get out in the open. Its been said that we should just face it and accept that 90% of ASP.NET applications are written like Kobe. It’s also been said that this Resource Kit doesn’t claim to be the “best” way to build applications. All I have to say to that is that I hold myself, my team, and Microsoft to far higher standards than that. I think it’s a complete travesty to release a sample applications that focuses on “architecture and implementation” with poorly thought-out architecture and horribly executed implementation. Imagine if the sample applications that shipped with the IPhone SDK looked like a Windows Mobile application. ASP.NET is pretty far behind when it comes to frameworks for Web 2.0 enabled sites, and if Kobe represents the way to build Web 2.0 applications with ASP.NET, then its a lost cause.

So is it really that bad? Lets go through a list of issues I have with Kobe, in no particular order:

Two JS frameworks (just like Oxite). To me this is like using NHibernate AND DataSets, or WebForms AND MVC. Call me crazy, but jQuery does everything I’ve needed from a JS library either directly or via plugins. This is a net loss in productivity and maintainability. Its possible ASP.NET AJax isn’t used anywhere and simply included in the scripts folder (something I can easily forgive).

Stupid CSS. I’m not an HTML or CSS expert, but I’m pretty sure what they’ve done with their CSS would make a Web 2.0 guru vomit. Here’s one of hundreds (maybe thousands) of examples:

<div class="wp100 bdr02 bgc03">

with the relevant CSS being:

.bdr02{border:#ffffff 1px solid}

As I myself was recently told: “by defining class names specifically tied to their design element, you are merely moving the design out of the style sheet and back into the content. This is defeating the entire purpose of stylesheets. You might as well just use <B> and <center> tags.” – and I completely agree.

Stupid HTML. Along with the really impossible to read and tightly coupled CSS, there’s some pretty bad HTML. *Most* pages start off with 6-8 nested divs, here’s a random look:

    <div class="pdl13 pdr15">
        <div class="fll w744">
            <div class="wp100 bdr02 bgc03">
                <div class="pd08 mostDownload01_l vat">
                    <div class="bgc02 vat">
                        <div class="mostDownload_m bgc02 vat">
                            <div class="wp100">
                                <div class="fll bgc05 pdr03 h20">

Many pages look like a mountain range…easily reaching 10 levels of nested divs , then back to 8, then 12, then 7…

By far, my biggest complaint is the sloppiness of the code, far exceeding what we saw in Oxite. There are major architectural and implementations problems with Kobe, but the lack of crafstmanship is so extreme that I have a problem seeing anything past it. Why do I keep ranting about poor code writing? Because it speaks volumes about the professionalism of the person writing the code. Also, Microsoft has internal and external guidelines for how code should be written. It should be a requirement for developers working at or for Microsoft to follow these guidelines (I’m guessing that it actually is). Some examples:

  • Excessive use of System.Int32 type instead of int
  • Use of int16 data type for seemingly no reason
  • Use of String instead of string in some places
  • Exlusively exposing concrete collection types (using List<T> instead of IList<T> or ICollection<T>), even from interfaces
  • Inconsistent naming like in Oxite (do private fields start with a _ or not, as an example)
  • Not listening to the compiler (bools don’t need to be initialized to false, reference types don’t need to be initialized to null)
  • Occasional swallowing of exceptions (while we’re talking about exceptions, the verbose and repetitive code used to “handle” exception seems questionable).
  • Bunch of useless usings atop most files
  • Code that’s never executed
  • Code that just doesn’t make sense:
      List<Presentation> presentationCount = group.Presentations.ToList();
      if (group != null)
  • Meaningless method documentation that just adds noise
  • Inconsistent use of braces for single-line statements
  • Inconsistent use of C# 3.0 features (automatic properties, var, …)
  • I’m sure I’m missing a lot


Architecturally, the same flaws that were present in Oxite exist here:

  • Fat controller (the two first ones I looked at where both roughly 80 LOCs)
  • Excessive use of magic strings
  • 0 unit tests, and lack of testability
  • No DI, check out this constructor (there are no overloads):
        IPresentationService presentationService = null;
        IAdsService adsService = null;
        IUserService userService = null;
        public PresentationController()
            presentationService = new PresentationService();
            userService = new UserService();
            adsService = new AdsService();
  • No domain layer (I’m starting to think MVC stands for Microsoft values Controllers)
  • Linq to SQL


I recently commented on twitter that the awesomeness of FluentNhibernate made it possible for ‘our’ way to become mainstream. I said that realizing that it never would become mainstream (I mean, it already is in most other communities, just not for .NET developers). Kobe and what it says about Microsoft’s ability (or willingness) to lead is the reason why.

I’m more than happy to accept that YOUR view of Kobe might not be the same as mine. Maybe you won’t be as upset about the programming style as me. Maybe you like LINQ to SQL and feel more comfortable with a 2-tiered system. Maybe you think unit tests are something only fake-developers talk about. I can accept all of those points of view. What I can’t understand is someone who thinks this even comes close to an acceptable sample/reference application from Microsoft (or anyone really). However its being promoted, it will be taken as the recommended way to build ASP.NET MVC applications.

Check out Kazi’s thoughts on Kobe as well

This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

37 Responses to Kobe – Oh Dear Lord Why?!

  1. Artem Tikhomirov says:

    Oh, thanks a lot! You should place it at the top of each of your blogposts.

  2. karl says:

    Since this seems to annoy you quite a bit (I understand, I’m the same with some people), I went ahead and created a CodeBetter feed minus my blog using Yahoo Pipes:


  3. Artem Tikhomirov says:

    No. It’s FH. It’s just incomplete. And you do not know it because you just talking about it. Moreover you do not talking about it originally – it’s just an echo of more thankful and more saint blog posts of other people.

    You always differentiate between MS and OSS projects just by their origins. I think that’s because you want to differentiate yourself from the .NETers “crowd” by associating your precious person to the smaller and cooler ALT.NET crowd. It’s ridicules.

    I don’t know why I’m telling you that instead of unsubscribing. May be it’s because you are not independent blogger – you are part of codebetter.com. And I’m enjoying most of blog posts here.

  4. KevDog says:


    I got on you previously regarding Oxite and the tone you used to criticize the project. In the spirit of recognizing the good and the bad, let me say that although you are highly (and justifiably) critical of Kobe, the tone is much more constructive and far less harsh.

    Also, why do you feel the need to test Linq2Sql classes? I test the partial classes that I create, but isn’t L2S generated code something that is redundant to test? Or am I misunderstanding what you are attempting to test?

  5. karl says:

    Artem: Not sure where you are having problems with FluentNhibernate : fluent configuration, or NHibernate itself?

    We are using NHiberante with XML mappings on our main software product. I’ve started a new personal project using FluentNHibernate, going as far as making their IRepository my own.

  6. Well, I guess then it’s a good thing Fluent’s not actually released yet ;) It’s no secret it’s not up to spec with NHibernate.

    I found myself also failing to get our rather large production application ported over to Fluent. I now find myself on the contrib team pushing patches, fixing the myriad of issues brought up, and slowly getting it closer and closer to feature parity with the current NHibernate trunk.

    Personally, it’s still got a long way to go, but rather than complaining about it to the inter-abyss, I’m actually doing something about it, because I believe in the project as a whole, and where it’s going to take NHibernate in terms of more mainstream acceptance.

  7. Artem Tikhomirov says:

    No, Andrew. You are right. It’s just… Arrrh!

  8. Andrew says:

    Artem, is anything on the internet worth getting so angry over?

  9. Artem Tikhomirov says:

    No, Karl, *awesomeness* of FluentNhibernate – that is a fake. I’ve tried to start using it on our _green-field_ NH app (not a huge one) several times and failed.
    For 3 times.
    Have you ever used it or just spreading hype bull shit as usual?

  10. I agree with you Karl, on pretty much every point. Thanks for saving me the time of checking it out, now I can spend more time working on a new Fluent NHibernate feature ;) .

  11. Kent Sharkey says:

    >And would it hurt Microsoft to release 1 application that uses Nhibernate? It’s as though ignoring it means it doesn’t exist.

    Sadly, their ongoing fear of non-MSPl open source licenses keeps them from using nHibernate, so I think you’ll have to live with L2S or EF (at least until the data team creates their next data access model).

  12. karl says:

    Because that grossly violates the single responsibility pattern – which means code will be harder to maintain and test. Controllers already have a very well defined purpose – to handle and respond to user action.

    Being decoupled from the physical Response/Request object doesn’t remove that responsibility.

    You’ll also have a hard-time re-using business rules across controllers.

  13. maxtoroq says:

    > No domain layer (I’m starting to think MVC stands for Microsoft values Controllers)

    Why can’t controllers be the domain layer, if you design them not to depend on Request and Response?

  14. karl says:

    Aside from testability, my real problem with Linq2Sql is that its one of the many moving targets from the ADO.NET team (or whatever team). DataSets –> Linq 2 Sql –> Entity Framework. They keep trying to invent patterns when better solutions already exist. The entire data access approach by Microsoft has resulted in developers getting fucked around.

    And would it hurt Microsoft to release 1 application that uses Nhibernate? It’s as though ignoring it means it doesn’t exist.

  15. Chris Hefley says:

    I’m curious, why don’t you like Linq2Sql? I prefer Fluent NHibernate, too, but I’ve been of the opinion that Linq2Sql is actually quite nice, for the app that doesn’t need the robustness of FNH, and can be gotten up and running faster and with less trouble. Not as testable, sure, but not “bad”, for the lightweight web app that only has a few tables in it.

  16. Philipp says:

    This somewhat reminds me of the initial ASP.net starter kits back in the day. I couldn’t belive my eyes there either, when MS officially published these apps full of horrible, horrible code.

    I really cannot understand why these reference implementations do not seem to get reviewed more extensively. After all, the quality of the code correlates directly with the perception of the targeted audience :/

  17. tawani says:

    >>Perhaps the idea was to release a “Worst-practices” and “How-not-to” project :)

    Best statement ever!

    It seems the Kobe team are the same yahoos who designed SharePoint

  18. John Watson says:

    The problem with claiming it’s not a best practice is that it is showcased in multiple pages on MSDN along with several videos going into detail on the planning, architecture and implementation. Guilt by association. If it was just a “whacky knock-off hacked sample” why not publish it with a single article in MSDN Mag or just release the code to the wild on CodePlex and call it done? This has the same level of exposure and advertising as other large examples in the MSDN REFERENCE LIBRARY – not the samples, not buried on http://www.asp.net, not on CodePlex, etc.

  19. Vasilio Ruzanni says:


    > “For someone who is currently trying to learn MVC and architecture, are there some examples or resources that you could point to as the ‘right way’ of doing things?”

    Sure. The Rob Conery’s MVC Storefront Example is much much closer to those ‘right ways’.

  20. I second Alan’s suggestion. I’ve heard many references to the improvements made to Oxite. It would be interesting to see how it fares in comparison to the last version and if any new issues where introduced.
    I agree with you on the lack of consistency. It makes my stomach hurt. I also wonder if the developers at MS use tool like R# or CR… Or if they at least run StyleCop.

  21. karl says:

    I will consider re-reviewing Oxite. Thanks for the idea. Oxite pretty much stayed the way it was for at least a month (maybe more, maybe less, don’t remember the exact timeframes). I consider this awfully reckless. But you are right that I’m not giving them enough credit for working hard through the negativity and ending up with something that I assume is better.

  22. Alan Stevens says:


    I agree with your characterization of Kobe. It is an embarrassment for Microsoft.

    I do wish you would give the Oxite team some well deserved credit. They did not “wait us out”. They immediately began correcting the issues raised by the community.

    Consider doing a followup Oxite post on the current state of the code base.


  23. karl says:

    I’m aware that Int32 == int (even on 64 bit platforms) and String == string.
    1) I think the common practice is to use the C# keywords.

    2) even if I’m wrong, they aren’t even close to consistent. I always use int and string, and I’ve *NEVER* (not ONCE) used Int32 or String. And I’ve NEVER had a colleague use Int32 or String because the standards were known ahead of time, and the team agreed on the importance consistency has with respect to readability and maintainability.

  24. Yngve says:

    Perhaps the idea was to release a “Worst-practices” and “How-not-to” project :)

  25. >Use of String instead of string in some places
    Hi Karl, as far as I know using String or string results in the same output. However sticking to a particular style – using String (the name of the actual class in the framework) or string (the C# language alias for the type) – helps organization and readability of code much better.

  26. Gunnar says:

    These HTML/CSS fragments are very similar to SharePoint ones by their names and hierarchy…

  27. Parag Mehta says:

    This is amazing. Makes me wonder if there is any sanity in some of the developer teams at Microsoft ?

    It’s funny though that several big names blogged all at once about this issue. Looks like everyone likes Microsoft Bashing. On this project though it deserves it. Kobe can’t be a reference application dished out to MVC newbies!

  28. NotMyself says:


    For an example of what the ALT.NET community has produced so far in the way of MVC guidance check out S#arp Architecture and Code Camp Server.


  29. Adam says:

    Karl -

    For someone who is currently trying to learn MVC and architecture, are there some examples or resources that you could point to as the ‘right way’ of doing things? Personally, I find that begin-to-end style tutorials such as Rob Conery’s storefront and the NerdDinner series are the most beneficial from a learning standpoint, as I am not yet knowledgeable enough to open up a complete application and figure out exactly what the programmers were trying to do.

  30. shawn says:

    the “it wasn’t intended as guidance” response to this kind of criticism is getting a little stale. to what purpose does microsoft release this type of software if not as guidance? if it’s not worthy of emulation, what possible purpose could it serve?

  31. I agree that int etc is more common. I think the reason for this is more to do with people’s coding history (Java, C and C++ syntax) rather than an established reason solely within the boundaries of C# (performance or compiler impact for example).

    I’m happy to buck the trend on this one because of this. It probably helps that I didn’t have heaps of time invested in C and C++ before my .Net days.

  32. James says:

    I think the people that wrote Kobe and the people that wrote ASP.NET MVC are sitting in different buildings (different countries, perhaps), the lack of “Getting It” is simply astounding.

    Lax hiring practices…

  33. karl says:

    From what I’ve seen int is far more common than Int32 – people find it improved readability. Either way,we can agree that they should be consistent (which they aren’t).

  34. Kane says:

    Three cheers for this article.

    Microsoft’s sample applications are generally taken by the community as best practice. Perhaps Microsoft should have run the code base through ReSharper (or even their own Code Analysis) which would have picked many of the issues you have observed.

  35. I agree with a lot of what you have said Karl, except for usage of Int32 and String.

    Using Int32 or int doesn’t matter to the compiler so it is really just developer preference. It should be a standard one way or ther other within an organisation though and definitely consistent within an applications code base.

    My personal preference is to use the framework types (Int32 etc) only because I find it helps to distinguish between types and keywords in the IDE.

  36. karl says:

    I added a link to your post.

    You can’t take 1 web 2.0 ASP.NET example and say that this is proof that ASP.NET is competitive in the field. The vast majority of high-profile applications (from digg, to slashdot, twitter and facebook, google, wiki, …) are built using php, python, ruby or perl. The only “big” one I can think of using ASP.NET is MySpace, and from what I understand MS pretty much paid for it.

  37. Hi Karl,

    Did not I deserve a reference of my Post.

    And Secondly I do disagree with this statement

    “ASP.NET is pretty far behind when it comes to frameworks for Web 2.0″

    Try pageflakes.com it is an perfect example of a Web 2.0 application which was written in ASP.NET 2.0 with 100% MS tooling.