Jak Charlton - Insane World : TDD, Architecture

Oxite - An Example of How Not To Write MVC Applications

Jak Charlton — Fri, 19 Dec 2008 17:56:00 GMT

You may have missed the release of Oxite recently, and some of the hype and comments around it. Having now seen some absolutely ludicrous comments on the web chiming in about how good it is, I feel compelled to write my own short appraisal. Lets start with some of the hype by the Oxite team about their application, as published on CodePlex:

Oxite is an open source, standards compliant, and highly extensible content management platform that can run anything from blogs to big web sites.

We heart you so much, that we thought of everything. Oxite was developed carefully and painstakingly to be a great blog sample, or a starting point for your own web site project with CMS needs. Its line-up of sexy attributes includes: provider-based architecture allowing you to swap out database and search providers (SQL Server DB, local and Live search providers included), built for testability and hence most likely to be voted "hottest in class" by TDD fans (repositories, everything has an interface, etc.)

That is the honest opinion of the Oxite team of the application they have written ... "hottest in class" by TDD fans

Now come on!!!! Firstly, to be admired by TDD fans it would have to have been developed using TDD, which clearly it wasn't - it's test coverage is pitiful, seriously pitiful.

But even forgetting picking on specifc ridiculous statements, it only takes 10 or 15 minutes of digging through the source to realise how poor this codebase is - really poor.

Now this has sparked a large number of web responses - one of the first was Rob Conery. Rob is a good guy, a very talented developer, and with his MVC Storefront application he has provided a very good example app for ASP.NET MVC. He took on Storefront as a learning excercise, and although he has had some problems, and has changed things a few times, overall the app is pretty damn good. Rob is pretty restrained in his comments, understandabl as that is the kind of guy he is, and this was an application from his own company, Microsoft. Although not officially endorsed by MS, anything they release will obviously be held up as an example to others of "the right way"

This mild rebuttle was followed by Karl Seguin, who was far less restrained in his comments, with good cause. And that's where the furor began. For some peculiar reason, many people popped up out of the woodwork to say how good Oxite was, how it was really good of MS to release it, and about how they were going off to start writing other sites like it.

Then another peculiar thing, Rob Conery decided to refactor the application to try and make it half decent - he also commented that people who said negative things about Oxite were making his job harder in getting the Oxite team to sort the mess out.

Chad Myers commented, and tried to be restrained in his remarks - but never the less, his conclusion was less than complementary about Oxite.

Scott Hanselman then decided to chime in, and fairly predictably so as a MS employee, urged restraint in critisism. Scott has always been the diplomat, and his post was definitely down the middle of the road.

But Scott was missing the point, Oxite was not only shockingly poor, but was being promoted as a some wonder application, highly testable, "hottest in class" by TDD fans ... ultimately the puff on the CodePlex site was making this out to be "the right way" to do ASP.NET MVC. Oren decided his commentary would be on the PR blunder this had been, and specifically about Scott's comments, which he felt were less than appropriate.

Fast forward to today, when I was directed to a blog post via Twitter - in which Nigel Parker had swallowed the blue pill and repeated the ludicrous puff stuff from the Oxite team. (this link now appears to have been removed from Nigel's blog). More suprisingly he then went on to say how good this was, and how it as just what the development community needed. This prompted more than a few raised eyebrows - though clearly the post was written before Nigel had downloaded the code or read it - I can only hope he has now done so, and has come to the same conclusion that most of the developers I respect have done - Oxite is poor beyond belief.

I got narked enough to write this because I am stunned at ho many people thnk the Oxite application is "good", to be honest I am stunned by any developer who thinks it is of release quality, let alone to be released by Microsoft as an example application. Many many newcomers to ASP.NET MVC (an MVC in general) are going to pick this application up and copy it - consciously or subconsciously - and then we have the next generation of spaghetti mess that MVC is designed to eliminate.

And then these newcomers will find their MVC projects as f***ed up as the Webforms projects, and blame MVC, blame TDD, and generally blame anything but their own actions. And in this they would have some element of being in the right - if Microsoft employees release an example application, that in any way bears the Microsoft name - they have a responsibility to get it right.

And to round this off, Glenn Block posted the perfect response to Oxite - a piece of honesty and openess that elevates him even further in my estimation. The situation is summed up perfectly with:

There is no excuse for this. There are tons of folks both internal to Microsoft or external that can help people who want to learn good practices for developing software. The fact that the MVC team was not even consulted by the Oxite guys is literally stunning. Not to mention all the other folks we have internally like patterns & practices, folks in our evangelism team, and TDD and Agile email discussion groups which have hundreds of folks. I really wish the "Look what we can do" mentality would become a thing of the past.

Hallelujah, somebody gets it!

Is Alt.net Duplicitous?

Jak Charlton — Wed, 21 May 2008 09:54:00 GMT

Roy makes a number of accusations about the Alt.net community, particularly centred around their espoused ideals clashing with their comments and blogs. I respect Roy greatly, his blog was one of my first real sources for great TDD information, and he has consitently put out great blog posts and software. Largely his complaints come down to TypeMock (who he now works for) not getting an overly warm welcome by many people in the Alt.net world.

I don't for one second question Roy's sincerity, he really has shifted his view on how testing and mocking should work, for what he sees as all the right reasons, and now he seeks to convert others to the same cause.

I'm not what you might call a "paid up member" of the Alt.net movement, my blog address appears on altnetpedia.com, I frequent the Alt.net mailing list, but I have never attended one of the conferences, nor do I put the Alt.net logo on my site. I read a few dozen blogs, probably a third would be classed as Alt.net people, most would not be. I guess I have a foot in Alt.net but dance with the devil.

I am however one of the people that has commented a number of times on TypeMock and its suitability as a mocking framework (for my needs), and Roy's obvious frustration comes down largely to his perception that people are bashing TypeMock unfairly, or out of dogma, and not seeing his vision for a better way to write software that TypeMock can help with.

That is perhaps the case with some people. TypeMock has some fervent supporters, and there are some people that think TypeMock encourages bad practices and should be avoided - software for some reason is one of those things people become almost religious about. I suspect that most people, myself included, are somewhere in the middle.

TypeMock is to me largely irrelevant. It has some plus sides (debugger support, mocking legacy and framework classes easily), and it has some down sides (it makes it "ok" to couple your code, or to use concretions over abstractions)

But mostly I just cannot see the point of TypeMock as it exists. It is, if you exclude the plus and minus points I just listed for a moment, basically the same as Moq or Rhino Mocks. It does more or less the same things, in more or less the same way, except both of those options are free, and TypeMock is one of the most costly development tools you could own.

I'm certainly not against commercial software, I own personal licences for all the software I use on a daily basis, but those products I choose to purchase are the best in their class, or solve a particular problem I face. I also weigh up the cost to value benefit.

The best comparison would be against unit testing frameworks, which are all to the best of my knowledge open source. There are commercial tools which make them easier to use, but there is no need for a commercial unit testing framework, as they are at least 95% feature complete.

The same could be said of mocking frameworks, Rhino and Moq are at least 95% feature complete, and pretty much (in all day to day ways) the same as TypeMock. There is for me, no one "killer feature" that TypeMock has that justifies it's price or putting a dependency upon it within a code base.

So is Alt.Net guilty of the duplicitous charge that Roy has made?

Expecting all people who frequent the Alt.net world to be constantly flicking between technology and tool choices is not going to hold water. A typical software project may last weeks, months and possibly years. You cannot switch and change that frequently, you have to make choices and go with them. That doesn't stop Alt.Net people wanting to become aware of more options, but it also means that new options have to get compared to existing options, and even when a better option comes along, it is frequently not going to be used because of historical reasons. People still have their favourites, they still have their personal biases, and they still consider themselves as capable individuals who can evaluate these things.

I honestly don't think TypeMock in it's current form is that revolutionary that we should be sitting up and rushing to use it. The few new things it brings to the mocking party are different, not much better or that much worse. So picking the right tool for the job, means most of the time I prefer to write a wrapper or abstraction (a few wasted minutes) as opposed to changing an entire mocking strategy, all for the sake of a shinier toy. Others make take another approach. When I encounter a real world scenario where I need the power that TypeMock has, I'll re-evaluate.

Sometimes, the newer tool isn't the right tool for the job.