My good friend Sam Gentile pointed to me Nick Malik's post on "Tools for Mort", in which Nick responds to some comments made by Sam a few days ago. I don't particularly agree with Nick's point of view. Several things bothered me about this post.
Why are we talking about Mort again?
First of all, I've said in the past that I don't particularly care in the Mort/Elvis/Einstein personas. Besides the fact that they tend to split users/developers around what I believe are the wrong areas, they are way too misinterpreted all around. Just bringing up the whole Mort topic is a sure way to turn a discussion in an unproductive direction.
What's worse, Nick apparently thinks Morts are the great Agile developers fighting the corporate world. Frankly, I have no clue where he got that idea from, but what do I know.
Look, it's great that there are people leveraging office and other platforms to solve business problems and get work done. There's a lot of really good use cases for that technology. However, it doesn't mean all software projects should be solved that way. In some scenarios, these kind of tools are great for solving immediate issues, but many times they are not suitable for building long-lasting, scalable solutions. Both sides of the software spectrum have different needs and deserve different solutions.
However, let's be clear about why the term Mort got a bad reputation: It was typically applied to people who didn't quite understand the tools/environment they were working on, creating half-assed applications that while did the trick initially, were a living hell to maintain because they didn't respect the most basic principles of good software development (in many cases, were not even aware they existed). Hey Nick, let's be honest here: your "Mort" friend was definitely no Mort if he was doing continuous integration and automated unit testing [1].
Sam doesn't get Agile?
Nick goes on to say:
"Do you really mean that Microsoft should make a priority of serving top-down project managers who believe in BDUF by including big modeling tools in Visual Studio, because the MDD people are more uber-geeky than most of us will ever be? I hate to point this out, Sam, but Alpha Geeks are not the ones using TDD. It's the Morts of the programming world. Alpha geeks are using Domain Specific Languages."
From this sentence alone it's clear to me that Nick is obviously not aware of Sam's extensive and continuous efforts talking about "agile architects" and railing against BDFU. Really, you might want to look a bit around before making those kind of comments.
Now, Morts are the ones doing TDD? Wow. color me surprised. Alpha Geeks use DSLs? Really? AND THEY DO NOT DO TEST DRIVEN DEVELOPMENT? WOW.
Hummm...not quite. Most of the so called Morts have no freaking clue what Test Driven Development. People like the Code Better guys, Ayende and a lot others are precisely doing that: Trying to raise the level of awareness in the community about TDD/DDD and improving the way they write software. They are the ones trying to improve our field by making developers more aware of how they work and get them to write better software that not only works and solves the business problem it is intended to solve, but that is also maintainable. At least grant them that much.
I think Nick is also a bit confused about the whole Alpha Geek business. A lot of them do use dynamic languages and yes, a lot of them use them to create domain specific languages. But what makes you think they don't need TDD? Quite the contrary, Nick, they are far more reliant on TDD and automated unit testing.
Nick then says that "We [Microsoft] are the singlehanded leaders in the space of bringing BASIC developers up to modern computing languages.". Humm.... certainly true, you moved them over to VB.NET. It's certainly possible to write Object Oriented code in VB.NET. That, however, doesn't mean they are. Let's face it, there are millions of developers out there using VB.NET and (yes) C# that are still writing essentially procedural code (if they are lucky). Just because you declare classes doesn't mean you're doing OOD.
It's the tooling
But that's all mostly irrelevant to the discussion. I got the chance to speak about this with Sam and others during the past MVP summit, so I do think I have an idea what the fuzz is about (and because I happen to agree with the consensus). See, none of us are arguing that Microsoft has not done significant contributions to the community and even to the Software Developer profession, because they have.
What we do argue about is the tooling coming out of Microsoft and the way it is meant to be used. A lot of the software coming out of DevDiv these days seems to be very focused on building something quick. That's not a bad thing by itself, we all want software could be developed faster and that we could deliver it to the business as soon as possible.
What is a problem is that the tools enable that quick result at the expense of something else; something fundamentally important if you're not writing sample applications or "quick-n'-dirties". They are fundamentally non scalable (and I'm not talking about performance here), and unmaintainable if you just stick to the whole straight from the db databinding and drag and drop style of development Microsoft is so proud about. Better people than me have argued this more vehemently that I ever could so I'm not going to repeat it here.
I think that, at a fundamental level, there's a significant disconnect here. What some part of the community spends its efforts in is to try to raise the awareness, knowledge and capabilities of developers everywhere as a means. For them this is a key point in getting better software, with better and faster results. Instead of dumbing down the tools to suit the unwary developer, they are trying to smart up the developer to use the available tools more effectively.
[1] Somehow, I can't imagine Nick's Mort doing TDD while writing Excel macros, but maybe I'm just being cynic...
