Managers at the company I worked for in Japan were surprised that I knew the term "Mado Giwa Zoku" (), or "window-seat tribe", which dated from the earlier economic era of the lifetime employment system, where employees who had proven themselves to be hopelessly useless were still kept on the payroll, and just given a desk by a window somewhere, out of everyones else's way.  Unfortunately, in software, there's just no way to keep someone out of everyone's way while still allowing them to touch the code base.  I was reminded about that recently, as I read about the tendency to trash "Mort", in at the first Alt.NET conference, recently held in Austin, Texas.

"Mort", "Elvis", and "Einstein" were personas defined in the developer tools group at Microsoft many years ago, to describe the three categories of developers that made up the target market.  "Mort" is the pragmatic developer who only studies engineering issues in the context of completing some assigned task, and learns JUST ENOUGH to let him complete that task.  "Elvis" consults a variety of development resources to help him improve the quality of his engineering, and expects tools to enable him to create custom controls and other alternatives to the canned solutions that Mort relies on.  "Einstein" is continuously seeking to expand his understanding of engineering issues, far in advance of receiving any specific feature request on which to apply that knowledge, and he demands tools that enable him to craft more sophisticated lower-level solutions.

Alt.NET is a reaction to what some Agile practitioners consider to be Microsoft's preoccupation with simple drag-and-drop development, at the expense of providing truly MEANINGFUL support for modern Agile practices.  Alt.NET supporters complain that Microsoft introduces its own, sometimes half-baked, alternatives to established, more fully-featured, open source tools, creating difficulties for developers trying to transition to Agile.  Although Microsoft's original definition did not imply any criticism of "Mort" developers (it stood for "mortal"), many participants at the recent Alt.NET conference seemed to take the position that the developer community needs to quit coddling Morts, and focus on how to integrate best-of-breed (presumably, non-Microsoft) tools and practices to support "true" .Net-based Agile development.  Other conference participants described Mort as an "Elvis in training", while some Microsoft attendees took issue with the overt Microsoft bashing.

There are certainly Good Morts, who may be junior developers overwhelmed with all the issues involved with real-world engineering projects, or developers who have only ever worked on trivial projects, or even non-developers occasionally "re-tasked" to write code -- such as the hardware engineer who picks up a copy of "Master .Net in 4 Minutes" and delivers a (surprisingly functional) FrankenApp in two weeks.  Good Morts can be mentored, or inspired, or simply replaced with more qualified resources when an application reaches a level of complexity or importance to justify funding the change.  But, for every Good Mort, there always seems to be a bench of Evil Morts, who are either unable or unwilling to make the effort required to bring their work up to an acceptable level.  Evil Morts suck time and energy from their peers, who constantly have to decypher and fix Mort's code, and who have long since given up trying to explain basic software engineering concepts like "separation of concerns", or "refactoring", or "WouldYouPleaseFollowSomeFreakinCodingGuidelines'".

The tough question is what to DO with Morts.  Its a little naive to imagine you can avoid or eliminate them completely.  The cost and scarcity of really good developers (whose fully-loaded cost here in Silicon Valley can top $150K), may have caused your company to settle for whoever it could get.  Maybe you got stuck with the bosses best friend's nephew (a story for another time).  And then there are all those other pesky real-world concerns liable to be raised by managers...

"We can't just get rid of Mort!  He's been with the company for fifteen years.  He's a nice guy, with a wife and kids and a mortgage... who spends his weekends delivering meals to shut-ins..."

or...

"What?  Reduce headcount in my section (and my perceived importance to the company)?!!!

or (I'm not making this up)...

"Yes, we know Mort's a problem.  But he's been here N years, and we have to be careful to avoid being sued for age discrimination"

Meanwhile, Mort still makes his all member fields public, passes eight separate parameters to hundred-line C# methods, unwittingly writes thousands of lines of code to duplicate capabilities baked into the BCL, sees nothing wrong with cutting and pasting the same ten-case switch statement into three different locations in the source, and will soon be writing reams of unmaintainable unit test code to accompany his convoluted implementation code.

Find some way to keep Mort out of your code base, because the situation is only going to get worse, as the learning curve associated with each new development technology continues to grow steeper, as new practices like Scrum shorten and intensify the development cycle, and make it ever-more-critical for developers to be able to rely on the quality of each other's code, as open source alternatives continue to inflate the size of the "standard" developer tool set, and as the PACE OF CHANGE to tools and practices accellerates to become almost continuous...

Maybe Mort has interests or talents that could be put to use somewhere else in the company.  Maybe you can offer him some financial incentive to leave (His fellow developers would probably offer to chip in -- and, if he goes to work for your competitor, you benefit TWICE!).  As a last resort, the closest developer equivalent to Mado-Giwa-Zoku would be to assign Mort a solo project... that you never plan to ship.