Coding Horror

programming and human factors

The Cult of Coleco Adam

My second true computer, after the TI-99/4a, was the Coleco Adam:

The Coleco Adam

I remember waiting in line in the snow with my Dad to get our hands on one of the first ADAM computers. Oh, the awful SmartBASIC programs I would write! I spent hours and hours hacking away in that terrible AppleBASIC clone. And loving every minute of it.

But the ADAM had some serious drawbacks:

  • The world's loudest daisywheel printer. It was loud when powered on doing nothing. You know that's a bad sign. When it was printing, it was quite literally deafening. I kept a towel nearby to toss over it while it was printing, otherwise nobody in the room, myself included, could think straight. All this for a whopping 10 characters per second.

  • Cassette tape drives. Okay, they weren't technically cassette tapes, they were fancy 256 kilobyte "custom data packs". Man, were these things slow. I could handle the slowness, but they also had a very unfortunate tendency to unspool. And when you've spent the last week writing the ultimate tank combat game – which happens to be stored on that unspooled tape – you develop some serious tape surgery skills, stat. I must have reconstructed those data packs fifteeen times over.

As with so many computers of my youth, I quickly outgrew it, moving on to the Apple //c. Coleco discontinued the ADAM in 1985, barely two years later.

Though it was never a particularly good computer by any objective measure, some people never gave up on the ADAM. Richard Drushel delivered this incredible, poignant speech at ADAMcon 7 in 1995, nearly ten years after the official death of the ADAM:

In 1995, if you are an active ADAM programmer, like me, there is no way that you can be doing it for hope of financial gain – by now, there's none to be had. I'm an ADAM programmer because I'm intrinsically interested in the ADAM. I write software for me, and if other people find it useful, that's great, but I'll program whether anybody else cares about what I'm doing or not. For me, it's been fun (though often challenging and frustrating) to learn about how the ADAM works, and how to make it do interesting things.

Unfortunately, I have not found many other people like me in the ADAM community. There aren't many of us programmers left, for a variety of personal and professional reasons. I don't believe you need a Ph.D. in order to learn how to write your own software in SmartBASIC or even assembler, but most of you out there believe otherwise; and I can't overcome the strength of your belief. There are many practical benefits to doing your own programming, not the least of which is that you can make your program do exactly what you want it to do. More important nowadays, however, is that ADAM programming skills can be part of your maintenance toolkit. If all the ADAM newsletters disappear, all the ADAM BBSes go off-line, no more ADAMcons are held, and you can't find anybody else who has an ADAM, then you, like Robinson Crusoe, can be self-sufficient on your own desert island. For me, that is an important motivation – because I'm really worried that the ADAM is about to become a desert island.

I don't remember how I found that speech. It must have been in 1996 or 1997 that I stumbled across it in some random pre-Google internet search. But I was completely unprepared for the depth of emotion and attachment people had developed for what was, at best, a footnote in computing history.

It's sad and irrational, yet oddly inspiring. Perhaps, as Richard points out, it isn't about the ADAM, but the people:

The ADAMcons are a public service to the ADAM community. They aren't supposed to turn a profit, but they have to break even. In order to break even, there has to be a certain critical mass of attendees. In order to make it worth someone's while, or some users group's while, to put effort into planning and running an ADAMcon, you'd like to see a little more than the bare minimum attendance. But I'm not sure that it's reasonable to expect much attendance at all. Already, the evidence is clear that there are not enough dollar votes to support new ADAM hardware and software development. What's the attraction of yet another ADAMcon? There won't be much new to see, the sessions will be pretty much the same as they've always been, most of the big-name personalities from the first 5 years of ADAM have moved on to other things, so those of you who like to hobnob with royalty will find only Johnny-come-latelies like me. Unless this is your first or second ADAMcon, everything is as familiar as an old shoe, only the city and hotel are different. Is it really worth $250 US for the same hamburger in a different bun?

Well, it must be, since all of you are here now. Unless you are a first-timer just discovering that there is a wider ADAM world, like me at ADAMcon 04, you must admit that the ADAM per se is only a flimsy excuse for your attendance this year. The real reason you're here is social. At past ADAMcons, or via now- defunct newsletters, or through now-disconnected BBSes, you met people who have become your friends. The ADAM brought you together, originally for some concrete and practical purpose (such as, you wrote some software that I want to buy), but now the ADAM connection is a historical artifact. Some of you would keep in touch whether there were still ADAMcons or not, whether you ever used your ADAMs again or not.

In case you were wondering, ADAMCon 2006 is in Chicago.

Discussion

Sucking Less Every Year

Steve Yegge's whirlwind language tour is, as he points out, neither good nor complete, which makes it one of the best blog posts I've read this year. I'll spoil the ending for you: according to Steve, Ruby combines the best features of Perl, Smalltalk, Python, and Lisp into one bag of unparalleled goodness, while avoiding the pitfalls these languages fell into.

I really ought to look into this Ruby thing.

What's really remarkable about this article, though, are the many random gems of programming wisdom peppered throughout. Like this one:

When I started at Amazon, I could recite for you all the incantations, psalms, voodoo chants and so on that I'd learned, all in lieu of intelligence or experience, the ones that told me Multiple Inheritance is Evil 'cuz Everyone Says So, and Operator Overloading Is Evil, and so on. I even vaguely sort of knew why, but not really. Since then I've come to realize that it's not MI that sucks, it's developers who suck. I sucked, and I still do, although hopefully less every year.

I've often thought that sucking less every year is how humble programmers improve. You should be unhappy with code you wrote a year ago. If you aren't, that means either A) you haven't learned anything in a year, B) your code can't be improved, or C) you never revisit old code. All of these are the kiss of death for software developers.

We all write shitty software. But only the best developers realize they're doing it. It'd be ironic if it wasn't so depressing.

(via Damien Katz)

Discussion

In Pursuit of Simplicity

John Maeda created quite a stir with his montage of the Yahoo and Google homepages from 1996 to 2006 in simple is about staying simple:

Yahoo vs. Google, 1996-2005

Although Philipp Lenssen has posted on this topic before (he calls it the portal plague), it's still striking. Altavista made the same mistake, and they didn't survive.

There's an interesting anecdote about Google's absolute focus on minimalism in Seth Godin's book Purple Cow:

It turns out that the folks at Google are obsessed with the email they get criticizing the service. They take it very seriously. One person writes in every once and a while and he never signs his name. According to Marissa Meyer at Google, "Every time he writes, the e-mail contains only a two-digit number. It took us a while to figure out what he was doing. He's counting the number of words on the home page. When the number goes up, he gets irritated, and e-mails us the new word count. As crazy as it sounds, his emails are helpful, because they put an interesting discipline on the UI team not to introduce too many links. It's like a scale that tells you that you've gained two pounds."

And of course, 37signals is famous for their mantra of less as a competitive advantage:

Conventional wisdom says to beat your competitors you need to one-up them. If they have 4 features, you need 5. Or 15. Or 25. If they're spending X, you need to spend XX. If they have 20, you need 30.

While this strategy may still work for some, it's expensive, resource intensive, difficult, defensive, and not very satisfying. And I don't think it's good for customers either. It's a very Cold War mentality -- always trying to one-up. When everyone tries to one-up, we all end up with too much. There's already too much "more" -- what we need are simple solutions to simple, common problems, not huger solutions to huger problems.

What I'd like to suggest is a different approach. Instead of one-upping, try one-downing. Instead of outdoing, try underdoing. Do less than your competitors to beat them.

Usability guru Donald Norman thinks the comparison between Google and Yahoo is misleading, and offers the truth about Google's so-called "simplicity":

Is Google simple? No. Google is deceptive. It hides all the complexity by simply showing one search box on the main page. The main difference, is that if you want to do anything else, the other search engines let you do it from their home pages, whereas Google makes you search through other, much more complex pages. Why aren't many of these just linked together? Why isn't Google a unified application? Why are there so many odd, apparently free-standing services?

I think this is a completely wrongheaded analysis, because I don't want to do anything else. All I want is to find what I'm searching for. Like Damien Katz, I believe features don't matter:

These people don't care about your flexible, brilliant architecture. They don't wish to tweak settings. They don't want to spend more than 10 consecutive seconds confused. They just want simple, they want to get their task done and move on. They don't want to spend time learning anything because they know they'll probably just forget it long before they'll need to do it again anyway.

We should always be in pursuit of simplicity, in whatever form it takes.

Discussion

Snippet Enumeration Macro

Inspired by my recent post on C# code snippets, I found a little console app by Francesco Balena* that enumerates all the snippets on your system along with their shortcut text.

I improved his console app and turned it into a convenient IDE macro along the lines of my keyboard shortcut enumerating IDE macro:

Code Snippet enumeration macro screenshot

Download the Snippet List Macro (3kb ZIP)

I found out the hard way that the snippet manager writes all of its changes to the registry. So I use the registry to enumerate all possible snippet paths (this picks up all the per-system snippets and per-user snippets) and also to locate the snippet XML index file that cross-references all the physical paths.

The macro defaults to enumerating the C# snippets, but you can change the _Lang variable to enumerate any available snippet library: VB, C#, J#**, and Xml.

This macro only works in Visual Studio 2005, obviously. Here's how to run it:

  1. go to Tools - Macros - IDE
  2. create a new Module named "Snippets" under "MyMacros"
  3. paste the macro code into the module
  4. close the macro IDE window
  5. go to Tools - Macros - Macro Explorer
  6. A new macro named "List" will be under "Snippets." Double-click it to run.
  7. The macro will take a minute or so to write a HTML file to your My Documents file, and open that HTML file in the IDE.

* One of my earliest coding heroes!

** Does anyone actually use J#? C'mon. Seriously.

Discussion

Making a Video Game out of your code

I just installed CodeRush, and now my IDE looks like this:

Visual Studio 2005 with CodeRush installed

From Mike Gunderloy's review of Refactor! Pro:

Refactor! uses the same drawing technology as CodeRush, making a video game out of your code. When you introduce an overload, for example, you actually see strikethroughs appear on parameters being removed; when you change the name of a method in one place, the typing appears in several places at once, and is highlighted everywhere. Things move smoothly and color and animation are used well. Some people may find this distracting but once you get used to this sort of thing it's hard to go back to a text editor that doesn't take advantage of the dynamic nature of Windows. The tool is utterly non-modal, and never interrupts your work with annoying dialog boxes.

A more interactive and dynamic IDE isn't an unreasonable thing to want. From Roland Weigelt:

It's kind of frustrating to see computers rendering 3D worlds with 100s of frames/sec, but source code editors advancing only in very small steps.

Amen. Just try beating my high score in CodeRush. Just try!

Discussion