(Un)commmon knowledge
Damian Murphy was a colleague of mine in Australia, before I came over to old blighty for a change of scenery. On his blog he talks about performance problems caused by the fact that “too much time was spent moudling stuff into design patterns and ‘best practices’”.
It brought to mind a conversation I was having with someone the other day, about the limitations and immaturity of .NET. I said that one of the major problems I have come up against is the lack of a ‘common knowledge’ among developers about which particuar cups of kool aid are worth drinking.
In the java community there is a shared understanding among serious developers that however many glossy pamphlets come across our desks selling the latest greatest app server, we will fight tooth and nail to avoid writing an EJB. We may host our webapp in weblogic if the company has shelled out for a site licence. But EJBs suck — they are slow, a barrier to refactoring, and complete overkill for most applications. Unless you really really really need clustered app servers (ie you are amazon.com) you don’t need EJBs.
Similarly with JSP — the first thing a good development team does is choose a good testable abstraction layer (like webwork or, if you must, struts) to isolate their code from the pain of JSP. MVC in web apps is about making the presentation layer as thin as it can possibly be so there is as little pain as possible.
So in java world we know which ‘best practices’ are just propaganda for app server vendors, and do what will actually make our jobs (delivering maintainable working software) easier.
In .NET world we don’t know which ‘best practices’ to ignore yet. One I do think is wrong is the data-driven code generated strongly typed dataset. That’s for another entry though.
Of course the sad thing is that even though I avoid them like the plague, I still need EJBs on the CV. Because marketing is not reality.