On Enterprise Library
Having been a consultant for the last few years, I’ve been in many organizations, seen many application architectures, and met many developers. What saddens me is that far too few developers/consultants in the Microsoft space are digging the Patterns & Practices group in Microsoft. To a large extent, I think this issue is directly tied to how “easy” Microsoft has made the .Net development process. Certainly, it’s quite easy to learn .Net, especially with the visual designers and drag-and-drop controls, but to write an enterprise application involves quite a bit more than building some of the samples out of a book and calling it a day.
I’ve consistently found that companies will continue to roll their own data access layers simply out of ignorance. Ignorance of the Enterprise Library, which is designed to be pretty much plug and play in so far as providing some infrastructure to common application needs. The case for Enterprise Library is fairly straight forward, in my opinion, but I’m amazed that so few developers I’ve come across actually know what it is and how to properly utilize (or even at least offer some alternatives (I myself prefer log4net for logging, but it’s generally tougher to get companies to use open source projects vs. Microsoft products)). But even aside from Enterprise Library, there are a number of great solutions to the common problem of data acccess, including NHibernate and EntitySpaces (formerly dOOdads). While certainly, uptake and acceptance of third party solutions should expectedly be low, there’s no reason why developers are not utilizing Enterprise library, aside from ignorance, NBH (Not Built Here) syndrome, and arrogance (“I can do it better”). This isn’t to say that there is never the case for rolling your own solution, but you better make damn sure that you can come up with a convincing argument other than the three just listed.
On a more fundamental level, while .Net is generally considered a far more productive framework to utilize, as compared to Java or unmanaged code, it is also a lazier lanaguage that requires the developer to know less about architecture and designing software solutions. Combined with Microsoft’s history with classic ASP and VB6, you end up with a lot of “.Net developers” who continue to write VB6 style applications and only use classes to demarcate the boundaries for a function set. There is a tremendous lack of understanding of object oriented programming concepts in almost every single organization I’ve worked with (with the lone exception being Factiva, where two of the developers in my group were really top notch). Seriously, ask some developers what the C# keywords abstract, virtual, and interface mean and you are guaranteed to get either looks of bewilderment or some off the wall answers.
This frustrates me to no end; my mind simply cannot handle this type of development. I’ve always been fond of the saying: “Never wrestle with pigs. You both get dirty, and the pig likes it.” I feel an obligation to myself and, more importantly, to an organization that’s paying for my services, to introduce standard practices, design patterns, solutions, and libraries where appropriate. I think this has gotten me into trouble on more than one occassion, including my current situation. I mean, 12 months ago, the idea of unit tests (as in NUnit) were lost on me. I didn’t really understand the value of writing these tests and how to properly utilize them. I still do not feel that I’m solid on the latter, but I’ve definitely come to appreciate the value of unit tests and using a test driven approach to implementing code. I simply cannot write un-tested code nowadays as I find it inefficient and unprofessional. And yet, clients neither understand nor appreciate what it means to take a test driven approach. Instead, this type of development is actually discouraged as the front-loaded work is typically very far from the UI (at the class library level), which means that the business people and managers don’t feel progress. I mean, I can feel it in their eyes when they look at me and wonder what I’ve been doing and why I haven’t hacked together that WinForm yet.
Seriously, is there something wrong with me? Am I just being snobbish about this? I like to think not, as I openly admit that I myself underestimated the value and power of a test driven approach just 12-14 months ago and I’ve since undertaken the task of adopting it as SOP. But the thing is, very few developers, at least that I’ve worked with, take the initiative to learn technologies and software engineering practices beyond learning the base .Net framework. Mind you, I’m not talking about small time consultants with small companies. I’m taking about $150+/hr consultants working for multi-billion dollar companies. But then again, a lot of these consultants are not really in consulting positions; more accurately, they are really staff supplements, which typically puts them into a weaker position in terms of affecting change (myself included; this is what I really hate about so called consulting gigs, no one really wants to consult you on anything, they just want you to sit your ass down and write some code….now).
Enough ranting I guess. Understand that I’m not trying to come across as elitist in any sense; I simply expect developers to remain active in learning their discipline. I expect architects and consultants to understand the technologies in the relevant solution space before sending the devlopers off to write the code. I simply expect people to be educated and open to ideas, especially people in a technical lead role. In any case, Enterprise Library for .Net 2.0 is upon us. I’m actually fairly excited to put it to use and see how the team has improved upon the existing library. It’s worth checking out Tom Hollander’s blog (Microsoft’s product manager for Enterprise Library (Yes, it’s a full time project within Microsoft staffed by real life Microsoft employees)) for some of the dirt on the new features and changes in Enterprise Library for .Net 2.0.
On a closing note, I’d just like to make an observation. It always amazes me when I see people’s desks with stacks of books that were obviously never touched. It’s as if some developers think that they can learn by osmosis…keep that C# book close enough, and some of that info might just magically seep into your brain. I only wish it were so easy.
