There's much, much more to follow from this past weekend. This just happened to be the section I managed to get done first. Please don't get the impression that all we did is sit around and bash Mort, because that's very far from the truth. Most of the time was spent trying to learn how to build software better and more efficiently. We did spend a couple sessions on how to make the community as a whole better, and this reflects a piece of those discussions.
I'd like to take this time to remind everyone that the term "Mort" was coined by Microsoft itself and not by me. I first heard the term four years ago from a recently converted Java developer sneering at the barbarian hordes of VB6 developers doing .Net -- which, after removing a veneer of OO fundamentals, was basically me. His complaint, and one that I unfortunately still agree with, was that .Net developers put more emphasis on knowing technical details and API's instead of learning programming and design principles. In his and my value system, the fundamentals like separation of concerns are more important.
Yes, I know that some of the elitists among us have been know to bash Mort from time to time and I'd be a wealthy man if I had a quarter for every time I've propagated or witnessed Mort-bashing. At ALT.NET, I would have been able to get a soft drink from the proceeds, but Starbucks would have been out of reach. Anytime you talk about spreading the usage of Agile techniques in the .Net community or raising the awareness of OOP principles someone inevitably raises the concern that "Mort won't get it" or "Mort doesn't care" or even "Mort shouldn't have to care about any of that, Mort should get to go home at 5 and play softball." Does it have to be that way though? More importantly, is any of that really true? Can we be a little more optimistic about other developers?
Before I go any farther, I'm going to paraphrase Microsoft's original persona definition. Mort is a developer who only learns just what he needs to complete his project, on the project. The positive spin is that Mort is a perfectly pragmatic fellow that's only focused on adding business value as opposed to a pinhead that's too wrapped up with internal trees to see the forest. The pejorative usage is simply a bad developer or a 501 developer that just doesn't care. You, myself, ALT.NET, INETA, and the entire blogosphere can't do much about a lack of motivation, but we can all do something about providing more opportunities for learning and exposure to other ideas outside of the MSDN canon.
Why does it even matter if a developer is content to be a Mort? I think that one of the reasons that our profession is lacking in skill across the board is how easy it is to write code. The only ingredients you absolutely need is a compiler and basic "if/then" or "do/while/foreach" constructs and your set. Just pump in energy, late nights, and pizza and you've got some code that'll do what you need it to -- as long as you don't try to reuse it or modify it later or heavens forbid, change your mind about what it's supposed to do. We've generated a great deal of lore well beyond simple programming constructs to foster better productivity and create sustainable codebase's. To make software development finally be a truly respected profession, we need to start internalizing the lessons we've already learned.
Back to the question about whether or not Mort can get the stuff we're talking about like separation of concerns and TDD. The typical Mort has managed to acquire a working knowledge of DataSet's, data binding, and the WebForms event lifecycle, the things that comprise what I call the "MSDN way." These topics aren't all trivial, and the WebForms lifecycle machinery is outright complicated. Mort has learned these tools quite successfully because:
- He's probably a smart fellow anyway, or he would have been weeded out. Or made into a manager.
- He's learned the things that have been put in front of him. He isn't necessarily out there looking for new or different things and might not have even heard of TDD or IoC tools or mock objects. The topics listed above are the things that a typical .Net developer is likely to come into contact with in the course of his career in an average shop.
After the conference I had an interesting exchange (over a plate of Chicka Chicka Boom Boom enchiladas at Chuy's) about whether or not there are, or could be, Morts in the Ruby on Rails community. We decided pretty quickly that it was a moot point in a way. There probably are 501 developers doing Rails, but anybody doing Rails is automatically exposed to what I would call better software practices. Separation of concerns, unit testing, and automated build scripts are all baked into Rails. A Mort working in a Rails shop who only learns what he needs for a project just has to open his or her eyes to take in many of the things that Mort in .Net can easily miss out on. I'd rather that more and more of our .Net community invest in their knowledge and look around outside of .Net a bit more, but we can do more to give the average Mort a chance to learn by exposing him or her to solid software development principles.
We've got a golden opportunity to make the exact same thing happen in the .Net community with the advent of ScottGu and co's new MVC framework. I'm sure the usual suspects will jump in front with conference talks about the new technology that focus on the libraries, but let's make sure that at least some of the articles and presentations about the ASP.NET MVC framework discuss the underlying principles and the advantages of those principles.
Just for fun, here's some Mort related quotes from this weekend:
"Mort is just an Elvis-in-training"
"I'm the Mort-iest Mort, Mort, Mort..."
"...long live American .Net Idol, where everyone gets a chance to be Elvis..." You've got to picture the speaker waving a hot wing with sauce running down his chin to get the full effect.
And one last time, ScottGu needling Bellware: "Scott, it's Morts like you..."