An Interesting Development: Oxite
Back when the Earth was still cooling, and VB was still the best way of creating Windows applications, if Microsoft released a sample or bit of development guidance, it frequently found it way into many applications. Development managers looked for "DNA" applications, spread across three (or more) tiers. Duwamish (in all its versions) clones multiplied. All of this was with good cause - who else should know best how to create Windows applications, but the people that wrote Windows?
Time moves on. Developers today look at more sources for development wisdom: design patterns, TDD, DDD, BDD and more. In addition, more developers have looked at, developed in, and learned from other programming languages: Java, Python, Ruby, PHP. In short, developers today are generally more aware of good technique, and demand it.
Enter Oxite: a simple blog engine written using ASP.NET MVC. This is a sample written by the same team at Microsoft that is responsible for Channel9, Channel 10 and MIX Online. That last site being most appropriate, as it runs using Oxite. Wait, you say, I thought you said it was a blogging engine? Isn't MIX Online a content site like MSDN? Well, the line between a blog engine and a content-management system (CMS) have certainly blurred lately, with WordPress running many of the popular Internet news sites. In addition, if you think about both a blog and a general news site, they tend to have similar needs: they both provide multiple authors with the ability to add content, possibly at multiple locations on a page as well as on multiple pages, and to enable comments and feeds of changes. After building the Oxite engine, the team decided to release it, to encourage awareness of what they did, as well as to demonstrate generating good, clean XHTML from an ASP.NET site (a frequent complaint about ASP.NET is it's generated markup).
The Internet press immediately jumped on it with their usual hyperbole:
In addition, I saw a number of people post about switching their blogs (or sites) over to using Oxite.
All of that seemed normal. What caused me to notice however, were some less complimentary reactions:
- Some Thoughts on Oxite - "It's hard to write a post like this without sounding negative"
- On Oxite - "There is no excuse for this."
- My Quick Take On Oxite - "Oxite should be pulled immediately until the larger issues (including and especially the major security vulnerabilities) can be addressed satisfactorily."
- Oxite - Oh Dear Lord Why?! - "Let's be clear: Oxite is a poorly executed application that'll have a profoundly negative impact on the ASP.NET community at large."
Not the usual response to a Microsoft sample. Now, many have said (including myself, and the product team itself) that the intent of the application wasn't to be a great sample of architectural guidance. However, many of the architecturally minded folk in the community have correctly noticed that all too many developers would have jumped on this as "Microsoft's solution", and used it as canon, to their detriment.
So, is there a point in all this, and a lesson to be learned? Of course there is: don't take a block of code as gospel, whether it comes from a vendor, a consultancy or any other source. It may run, but is it worth running, or will it become a nightmare later on? Each and every developer needs to know enough of their job that they can 'sniff out' bad design before you start investing time and lines of code. You should be able to answer common questions (at least for your own development): Is a 3 tier system better than a monolithic application? Should you be doing TDD (or DDD, or BDD)? Should I use an ORM or other framework? Read up on the alternatives, learn new programming languages or methodologies, look at code from other applications.
Every developer needs to find the process to good code their own way, and that doesn't mean copying a sample from MSDN or elsewhere and shipping it.
I tend to (only half-jokingly) say that there are only three characteristics of good code:
- Does it do what the customer needs?
- Is it (reasonably) secure?
- Can you understand it in six months after not looking at it?
While that may seem a little flippant, I stand by it, especially the last point. Maintenance is the most important phase of development, and the more you can do to make it easier to update/fix/extend an application now means you have a better design. Much of the goals of OOP, Agile, TDD etc. are designed to help, and therefore they are worth looking into.