I've gotten quite a bit of feedback on my previous post, and there are a couple of things i'd like to address. It seems that some people kinda took offense to my statements about the rarity of .NET developers with knowledge of certain practices/principles. First of all, i would like to state that i have been working in the .NET world for about 4 years now and have worked with quite a few .NET developers during those years. Most of you already know this and i feel stupid for even mentioning it, but apparently there were people who read the previous post thinking i didn't know anything about the .NET world and that i had based my statements on just the one .NET developer that i mentioned in the post.
Anyways, back to the topic at hand... the quality of developers in the .NET world. As some people mentioned in the comments of the previous post, Microsoft itself thinks of developers in 3 categories: Mort, Einstein and Elvis. I couldn't really find an 'official' Microsoft link about these personas but they are pretty well known by now. Here's a quick summary:
Mort, the opportunistic developer, likes to create quick-working solutions for immediate problems and focuses on productivity and learn as needed. Elvis, the pragmatic programmer, likes to create long-lasting solutions addressing the problem domain, and learn while working on the solution. Einstein, the paranoid programmer, likes to create the most efficient solution to a given problem, and typically learn in advance before working on the solution.
I believe that Mort is the single most influential individual in the .NET world. Everything revolves around Mort, and this is where a lot of the strengths and weaknesses of the .NET platform in general come from.
People who are new to .NET can usually be productive in a pretty short timeframe. The tools are often relatively easy to use and there is plenty of documentation and Getting Started material available. No matter how you turn it, that is a strength of the platform. However, what is generally lacking here is some kind of follow-through on the fundamentals of healthy, maintainable software development. We've all seen the countless simplified, hello-world examples that are often demonstrated at Microsoft events. Some people consider me arrogant when i say this, but i truly believe that this kind of Drag-N-Drop Development is generally unhealthy. Does it have its place in the right context? Sure, as much as just about anything else has within its context. Take it outside of its context and things can get messy pretty fast.
Getting Mort hooked on this kind of development, without following through on Mort's education is like teaching construction workers how to quickly put up a wall without educating them about making sure that wall is gonna hold up over the years through all of the forces that will act upon it. But hey, the wall is there, right? Time to move on to the next wall! Or better yet, let's have Mort do some electrical work while he's at it. After all, we already know he's adept at construction and he finishes his work quickly. Whenever he has a few minutes time, we're going to have him work on the plumbing as well. He's got a great set of tools at his disposal, so he should be able to do all of this pretty quickly without investing too much time in his educational process.
There are tons of Morts in the .NET world. And Microsoft is constantly building and releasing more and more libraries and tools to make sure that Mort can quickly complete any task that is assigned to him, no matter how fit or unfit he is to complete that task in a sufficient manner. I think we all know that there is a lot of horrible .NET code that has been written over the years and i truly believe that a lot of that could have been avoided if more effort had been put into properly educating Mort.
Steven Smith left the following gem in his comment on my previous post:
In the Microsoft space rather than respond to the increasing demands for greater productivity by always seeking more productive and powerful development practices, that is how can we use our tools more effectively, the general mindset seems to be that Microsoft is bringing out a new version of .NET or some new visual tooling, what we perceive to be a more powerful tool and will solve our problem. But a powerful tool misused can cause a great deal of damage. Developer’s continuing professional development seems to consist of learning new Microsoft or third party APIs or attending Tech Ed rather than learning development principles and practices that are language and provider independent.
I think i can safely say that this will sound very familiar to a lot of you who are reading this.
So, is all hope lost? Certainly not. In the past 2 years, we've seen some tremendous improvements in the .NET community, mostly brought on by the ALT.NET movement which focused more on writing clean, maintainable code using proven design practices and software development principles in general. Regardless of what you (or me) personally think of the ALT.NET movement in its current form (or lack thereof), there is no denying the impact that it has had already. Microsoft appears to be focusing more and more on the topics that are typically associated with ALT.NET. All of a sudden, Microsoft has libraries for Inversion Of Control, for MVC web development, Object Relational Mapping, and more. These tools might not appeal to everyone who's already used more mature/powerful alternatives, they are still a very good sign. It not only shows that Microsoft is willing to invest more effort into this, but it also increases the exposure of these principles and practices to Mort. It's a slow process for sure, but the wheels do appear to have been put in motion.
If we can combine this with a more concentrated educational effort, we might be able to get to where Steven Smith and myself would like to get:
I would love to work with kindred spirits, people who consider their effectiveness as a developer is largely based on the power of the practices they employ and are always seeking more powerful practices that are being developed in the wider development community and apply them in their .NET teams.
Perhaps someday the majority of us, instead of a very small minority, will.
