Shed Metaphor

Almost every guy has a shed (or a garage, or at least a closet) where he spends time puttering around, fixing things (or more likely, taking them apart and forgetting how to stick them back together), but most importantly, for accumulating stuff. The stuff ranges from the probably useful (jars of metal screws, fasteners and string), to borderline trash (bits of wire, odd brackets, plasticky pieces broken off from equipment, and string), to absolute rubbish (dead batteries, manuals for obsolete computers, and string).

That string could be useful someday…. 

The bench in the shed is always covered with half-disassembled motors from haplessly disemboweled vacuum cleaners, yellowed clock-radios cracked open like crabs, little trays of parts waiting to be scattered, and cables with oddball connectors requiring adapters only found in surplus stores. If there is a peg-board with hooks and painted outlines of tools, the tools themselves are invariably missing or hanging on the wrong hooks. Drawers are full of sockets, screwdrivers, punches, hammers, goggles, paint brushes, rulers, squares, pencils (both worn-down nubs and the ones unsuccessfully sharpened on a file), “still good” spark plugs, tiny cans of putty, a rabbit’s foot grey with dust, and endless little pieces of debris, in other words, stuff fractally down to microscope junk.

There is reason and order to the shed, but you have to have lived with it for quite some time to comprehend the philosophy of the arrangement. Ask the owner of the mess where anything is, and he’ll be able to tell you. Mostly. Maybe. “Um, I’d better have a look.” Tubular widgets go there and electrical ones (up to a certain size) go there, but it will be impossible for the shed’s owner to explain precisely why. Someone coming into the shed to help out with a project will have a ton of trouble coming up to speed.

I argue that this kind of organization is what modern programming languages encourage: The willy-nilly scattering of functionality (and worse, mis-functionality and pseudo-functionality) through sets of “headers” and “sources” and “configurations” that more closely resemble a graveyard for unlucky lawnmowers and radios than an engineering effort. Cross-dependencies, strong coupling, “scripts” that run random pieces of code, you name the sin and modern programming languages are what make this possible.

For the most part we are still in the “toggle bolts go in that baby food jar because that’s where all the other toggle bolts already are” stage of software development.

Sometimes the best thing that can happen to a project is for an accident to happen. “Oh my gosh, we lost all the source code over the weekend when the bulldozers revolted and took out the shed we had the servers in.” It’s all gone, what do you do?  In such a situation, you should be happy.  Even overjoyed.

Most engineers will “lose” a project some time during their career. This has happened to me a couple of times; maybe a week’s worth of work vaporized for some stupid reason. What I found was that reconstructing the work went quite quickly, and that in the end I had nearly bug-free code that I understood more clearly. Things got better.

You can also get good results if you go on a rampage. Start throwing crap out. See how much you can remove from something and still have a workable product. Unused functions? Virtual methods and other forms of bet-hedging? Obsolete documentation? Ornate and useless comments? When in doubt, toss them out!

As for “shed” languages, I don’t know. Certainly things like COBOL’s rigid “DATA DIVISION” / “FROBOZZ DIVISION” are next to useless, procrustean at best. Maybe the answer is to have people on your staff who walk around simply whacking people on the head from time to time. Maybe the answer is long, God-awful boring design review meetings to act as flypaper in order to let the really productive people on your staff have undisturbed hours in which to type. I don’t know, but sometimes just shaking stuff up makes interesting things fall out.

Sheds aren’t all bad. I just wish I could find that #2 Spagthorpe standard spanner…

This entry was posted in Rantage. Bookmark the permalink.

2 Responses to Shed Metaphor

  1. Dude.. says:

    d:\>rem Okay… let me show you a simple COBOL program!

    d:\>type p.cbl
    display “Hello World”.

    d:\>rem… okay dude.. lets compile/link it…
    d:\>cbllink p.cbl
    Micro Focus Net Express – CBLLINK utility
    Version 5.001.0056 Copyright (C) 1984-2007 Micro Focus (IP) Limited.

    Micro Focus Net Express V5
    Version 5.001.0056 Copyright (C) 1984-2007 Micro Focus (IP) Limited.
    URN AXCGG/AA0/00000
    * Checking complete with no errors – starting code generation
    * Generating p
    * Data: 720 Code: 456 Literals: 128
    Microsoft (R) Incremental Linker Version 8.00.50727.762
    Copyright (C) Microsoft Corporation. All rights reserved.

    p.obj
    cbllds00001BDC.obj
    Creating library p.lib and object p.exp

    d:\>p
    Hello World

    d:\>rem dude that was really hard todo!

    d:\>cd tmp

    d:\tmp>rem Okay.. lets write something that interop’s with COBOL…
    d:\tmp>rem … here’s come C code…

    d:\tmp>type x.c
    int main()
    {
    printf(“Okay.. let’s interact with COBOL!\n”);
    P();
    }

    d:\tmp>cobol p.cbl omf(obj);
    Micro Focus Net Express V5
    Version 5.001.0056 Copyright (C) 1984-2007 Micro Focus (IP) Limited.
    URN AXCGG/AA0/00000
    * Checking complete with no errors – starting code generation
    * Generating p
    * Data: 720 Code: 456 Literals: 128

    d:\tmp>cl -MD x.c -link p.obj cblrtsmi.lib
    Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.762 for 80×86

    Copyright (C) Microsoft Corporation. All rights reserved.

    x.c
    Microsoft (R) Incremental Linker Version 8.00.50727.762
    Copyright (C) Microsoft Corporation. All rights reserved.

    /out:x.exe
    p.obj
    cblrtsmi.lib
    x.obj
    Creating library x.lib and object x.exp

    d:\tmp>x
    Okay.. let’s interact with COBOL!
    Hello World

    d:\tmp>rem so… COBOL is simple and interops with a load of stuff.. it supports COM, COM+, Java, OO, .NET, WinForms, WebForms, SOAP, XML. Web Service…

  2. landon says:

    COBOL is an abomination, superceded in complexity only by C++ and Common LISP. It does have a nice “crunch,” a kind of flavor-of-the-arbitrary that survives (in spirit) in modern SQL syntax (shudder). “MOVE A TO B WITH EXTREME PREJUDICE,” oh yeah.

    We spend a lot of time standardizing syntax and semantics. And that’s okay as far as it goes. But the best syntax in the world won’t help you do large-scale projects (admittedly, a bad syntax will cripple them, and I think that has been demonstrated, repeatedly).  Everybody has custom tools, every big project I’ve been on has done a lot of work around tools that was not transportable to anywhere else (or only with extreme effort).  This is like making your skyscraper with custom cement trucks, then tossing them because they ran on Malaysian Cocoanut Oil (“Hey, we were in a hurry, and we had a lot of it lying around…”) and doing the next building with trucks fueled with WWII surplus camo paint (“Hey, it was cheap….”).

    [By the way, can you turn off all that “Hey, I compiled 1280 bytes of code and 128 bytes of data, with 193 bytes of other wazoo that I know you don’t give a flying hiccup about, but I did it, I did it proud, and I just wanted you to know.” … I’m sure you can. But the last COBOL I typed any code into was just unbelievably miserable…]

Leave a Reply

Your email address will not be published. Required fields are marked *