<< St Paddys Day In Iraq - And A ... | Home | What Is Microsoft's Project Q? >>

If You Cut A Mort, Does He Not Bleed?

Lazy Coder Scott snickers when he reads blog entries decrying the existence of “Mort”. As he points out, we are all Morts to some degree or another.

I snicker when I read these posts because they dont get it. The entire POINT of writing code is to abstract away the difficulty that is inherent in using computers.

Which is true. The history of software development has been all about heaping one layer of abstraction on top of another.

However, I don’t see many blog entries decrying the existence of Mort. What I see are blog entries from “Not-So-Mort” upset about what happens to their programming tools and languages when tool and language providers accomodate Mort. Perhaps we see these tools as being made for the “Not-So-Mort” set, when the reality appears that these tools are being built for Mort. Perhaps the “Not-So-Mort” set would like separate tools.

Consider this, all abstractions are leaky. However, when an abstraction is well implemented, it hardly matters for the majority of the population. I believe I drive just as well in an automatic transmission car as I would in a manual transmission car, though my car has reduced the leak in the abstraction a bit via its sequential shift so I can switch to a manual-like mode, but that’s beside the point.

But many times, an abstraction is created in haste and causes problems for those of us who need finer grained control. A classic example is WebForms designer in Visual Studio.NET 1.1. I'm fine with the webforms designer. It is a great productivity tool and makes it quick and easy for Mort to build web pages using RAD techniques.

But now, take a Not-So-Mort who wants to use something like Microformats for example, which requires clean markup. He marks up his pages just right, but the pages get all FUBAR because the designer decides to rewrite his code. That's problematic.

The problem here is we’ve exchanged long-term productivity gains (the maintenance cycle) in exchange for short-term gains in initial productivity.

Because these abstractions are leaky and poorly implemented, they convolute the implementation details they are meant to hide and make long term maintenance that much more difficult.

Whereas well implemented abstractions tend to promote good code. I’ve read several people state that a developer would have a difficult time writing more optimized Assembler than a good C++ compiler generates in this day and age, especially on a grand scale. It can still be done, but the fact that it is so close shows that C++ is a great abstraction on top of Assembly.

I’ve written about Mort too, but I am not hating on Mort. As Scott says, we are all to some degree a Mort. However one characteristic of a Mort as I have seen commonly defined is that Mort does not care to constantly learn. Mort isn’t striving to improve.

I do still think we should expect more from Mort. Understand that though the tools we have at our disposal make computing easier every day, computing at its core is a complex problem. Be sure to gain some small understanding of what these tools are doing for you and a general idea of what happens under the hood.

Back to my car analogy, I couldn’t take a wrench and fix my timing belt for the life of me. But I do have a general idea of what an automatic transmission is doing and what limitations it causes on my driving (I can’t seem to redline!). I would never ask Mort to understand assembly, but do take the time to understand some general principles.

What others have said

tod Mar 17, 2006 8:27 PM

# re: If You Cut A Mort, Does He Not Bleed?

I didn't know the name for myself, but I suppose I'm 'Mort.' :-\ A year ago I was writing whatever code (through the IDE or off the 'net) I could just to get stuff to work. Fortunately, I've been learning and improving my skills over the past year to where I now have a plan before I start and a lot less spaghetti when I'm done, but apparently the 'serious' developers out there would still call me 'Mort' based on my experience. Oh well.

In all fairness, I think I'm getting a handle on this OOP stuff. ;-)

Ian Griffiths Mar 26, 2006 4:29 AM

# re: If You Cut A Mort, Does He Not Bleed?

The sequential shift doesn't reduce the leak in the abstraction. Quite the opposite - it's an admission that automatic transmission is the wrong abstraction, dropping you back at the lower level abstraction. In this case that's an improvement as manual gear selection is better than automatic, despite what Joel Spolsky thinks. I'm guessing he's a bad driver. :)

(Why's it better? More control, better fuel economy, and most importantly, none of the aggravating constant drain on your attention required in order to anticipate what the gearbox is going to do next and work around it in the rather high proportion of scenarios where it does the wrong thing. The only situation in which an automatic gearbox is less mentally draining is when your engine is heavily overprovisioned for the kind of driving you're doing, in which case it barely matters what gear you're in, so long as you're within 2 or 3 gears of the theoretical optimum. And actually for run of the mill driving that's a reasonably common scenario, particularly if you're unfortunate enough to live somewhere without interesting roads. But personally, I like to *enjoy* my driving - I try to avoid mind-numbing drives. And for any remotely engaging driving, automatic transmission is a special kind of hell.)

The only problem I have with Mort is not that he wants higher levels of abstraction, but that in my experience he tends not to want to think about the abstraction at all.

Abstractions are a code thing, and code isn't where Mort's interests lie. Higher levels of abstraction are only interesting to him to the extent that they enable him not to engage his brain with the code. (The popular presumption being that his brain is engaged with business logic instead. As a developer it's sometimes hard to believe that the brain was engaged at all judging from the code...) High level abstractions increase the probability that random hacking will lead reasonably quickly to a result that approximates what Mort thinks he wants well enough that he'll call it a day.

After all, Mort's in it for the results. The code is just a means to an end.

But this leads to exactly the kind of problem you describe.

There's nothing wrong with high-level abstractions if they are clean, and well-thought-out. The simplest possible solution is often beautiful to behold. But it typically belies how much thought went into its creation - the simplest looking solutions tend to require the most effort to achieve.

But Mort doesn't care for that - he's not interested in the quality of the abstraction per se. He's only interested in how little he can do before stopping coding.

This only affects me when either (a) I have to fix some monstrosity created by a Mort, or (b) a beautifully designed library is broken in order to reduce the initial cognitive overhead required to use it at the expense of simplicity of use from within mature code.

(And is there a way of turning off live preview on your comments? This is like typing in mollasses!)

Haacked Mar 26, 2006 9:37 AM

# re: If You Cut A Mort, Does He Not Bleed?

Thanks for the comment Ian. I'll probably add a checkbox to allow commenters to disable live preview. However I don't see how it affects typing in the comment box if you ignore it. Perhaps you need a faster machine? ;)