Home » Thoughts and Musings » Thomas M. Tuerke on Design »

design: /di·'zin/

   n a deliberate plan for the creation or development of an object. vt: to create something according to plan.
   good design: /'gud —/ the product of deliberate forethought and careful understanding of the purpose of a subject, resulting in a subject which significantly improves its utility, allowing it to integrate seamlessly and naturally into the role for which it is intended.
false synonyms: fashion, decor.

Table of Contents [show/hide]

How much do you want to play Simple Simon?

I've often likened working on computers to playing Simple Simon: if you told a computer to "put your shoes and socks on", that's exactly what it would do: put its shoes on, then put its socks on... because that's what you told it to do. But of course, you have to say it in just the right way (that is, the "Simon Says" part...)

But nobody wants to be perpetually tied to a simpleton; that would be tedious in the extreme. Just like most people don't want to code in machine code (the most fundamental instructions the computer understands) or its only slightly more friendly derivative, Assembly, most developers would like to abstract the routine administrivia of problem solving. As Software Development is a living science, the line of demarkation continues to move on that one.

There's one world view held by some that there are Einsteins—the infinitely curious that want to understand (and to the same extent, control) everything that's going on—and there are Morts—who generally lack any deep understanding of algorithms and software development, but have wet their toes with some programming and can (thanks to some RAD tools) come up with perfectly adequate, if inelegant, solutions to problems. Traditionally, these labels have been applied rather crudely to C and C++ programers in the former case, and Visual BASIC (and other "toy" languages, as some would have you believe) in the latter.

This is a false dichotomy, as I see it, but one that plagued the software development field for quite a while, providing inflexible (if somewhat vaguely defined) labels to describe "who would use this software development tool?"

I find myself fully entrenched in neither camp, and wanting a little of what both have to offer. I want to express logic to solve problems. Ideally, I'd like to state the solution in logic, but not have to go into niggling details about how to implement that logic. So to me, a well-designed system has transparency: I can see and influence what the inner workings are, but it also allows me to easily and economically express solutions without having to twiddle every bit: it just does the right thing.

What do I mean? Well, take programming COM in C++ (yes, there are still some folks doing that.) In order to walk through a list, you need the following... and that's with smart pointers to help manage the reference counting that COM requires meticulous maintenance for.

    CComPtr<IMyCollection> pCollection;
    // Some loop control overhead...
    LONG lCount;
    VARIANT vIndex;
    vIndex.vt = VT_I4;

    for(vIndex.lVal=1; vIndex.lVal <= lCount; vIndex.lVal++)
        CComVariant vItem;
        // Now do your stuff on vItem...

Now there are people who chide Visual BASIC as a toy, but you have to admit, when VB allows you to do this very same thing in a quarter of the lines, that's goodness... most people don't want to be managing QueryInterface, AddRef, and Release (hence the smart pointers) and by the same token, it's no stretch that most people would rather code a nice, clean for loop than deal with all the COM goo shown above.

The problems aren't just restricted to COM. I think RAII is a good thing, but not every language has an economical means of expressing it. The resulting prolix is one of those irritating "Simon Says" things that I would just as easily not have to endure.

Does that make me a Mort? I don't think so. I know when I want to use a float versus an int versus a decimal type, or a hash table instead of a linked list. I don't, however, want to hand-stitch all the bits together to get fundamental collection classes, nor do I want to bang my head against an opaque set of template libraries that are theoretical things of beauty but in practice turn out to be more hydra-like beasts.

And the thing is, I don't think I'm alone. There will always be a few outliers that must know everything, or don't want to know anything, but most of us want the machine to be good at what it does best, freeing us to do what we do best: solving problems, without all that "Simon Says" stuff.