isn't quite ashamed enough to present

jr conlin's ink stained banana

:: Building A Worse Toaster

Sadly, i'm rolling misses on my Google Fu this morning, but i believe that C.J. Cherryh wrote a short story about an elderly woman who wanted a new toaster. It being the future, the device delivered itself and promptly started doing the laundry, fixing the car, reprogramming the TV and all sorts of other wondrous tasks. The Matron, tutted, jabbed a fork deep into the machine. It sputtered, fell over, sparked and finally a warmed, lightly browned piece of toast popped out of a slot.

While the story is funny, it's also really useful to remember when building a tool.

Ultimately, you want your tool to be as simple as possible. This is the general theory of Unix. Little things that work well together. The problem is that building simple things tends to not be very popular.

As a software engineer, i am both subject to, and constant advocate of, feature creep. i want things that just do a bit more. i mean, sure i could have something that's just a front end to a database that allows me to enter a blob of text and then later display it,… but it could also have an inline editor, ooh, and a search function, and it'd be neat to have plugins… And, well, you wind up with WordPress.

Same with things like jquery, which started off as fairly simple and small, then became, well, jquery1. Even protocols go through that sort of progression (mind you, i already ranted a bit about "human vs. machine readable"). Darn near everything tends to start simple, but get increasingly more complicated.

As is usual, a number of things tweaked me about this point. One was an old rant about how even though people spend most of their lives in front of a computer now, most don't know how to use one. The other post talks about developer inequality and a longing for Hypercard. Both pretty much highlight the same thing, and i could argue against both equally.

For the first, i'll note that computers are media delivery devices and people tend to prefer to consume more than create, and that's ok. A fair number of people have no idea how to maintain their auto or understand the mechanics of municipal transit but use it to come and go. Granted, if they're taking an intro course on how to do car repair, probably a good idea to show them how to change the oil and rotate the tires, much like an intro class to computers ought to discuss programming.

Thing is, you can teach programming to kids. You can teach auto repair to kids. Hell, you can teach quantum mechanics to kids. You just have to make them want to learn about it. Javascript isn't hard. Packing it full of complex crap, frameworks and other stuff to make it "easy" makes it hard, but by-and-large most kids can grok the fundamentals pretty darn fast. No, they're not going to be able to understand using Promises to trigger component events in the Shadow DOM by the end of the week, but i wouldn't expect that.

Give 'em two weeks.

Likewise straight HTML is delightful because it's actually nearly readable. Pretty print it and it's pattern matching you can easily wrap your head around. Heck, explain to someone that The Web® really is basically a bunch of fancy telnet calls, and it's like watching a light bulb go off.

Sadly, that may go away with HTTP22 or SPDY, s/telnet/curl/ and you're basically back in the game again.

The final thing to note about all of this is that folks will surprise the hell out of you. They're not going to follow your arbitrary rules and will pretty much use whatever you hand them as a hammer. Done right, that's not a problem.

In fact, it could be a huge benefit.

Good Sir Tim Berners-Lee never expected people to use his protocol to do face to face video chats. Heck, he wasn't all that hot on documents having things other than links, but he was willing to let folks be creative with his toy. Heck, i've built stuff, given folks instructions on how to properly use it, and they've blissfully ignored me again and again.

This is typical (regardless of my continually trying to either ignore or change it), and should simply be part of any service you build. If anything, that sort of abuse should be lauded.

So, when you're building your next toaster (or library, app, interface, device, whatever), ask yourself:

  • Is this doing the least it can to be useful?
  • Can it talk to other things easily?
  • Does this tool make zero presumptions about the user or the way it will be used?

Answering those questions will pretty much tell you how successful your thing will be.
Otherwise, you're just making a worse toaster.

1i'm not knocking jQuery as bad, i'm just saying that people have decided that jQuery is how you write javascript. Javscript has evolved and adopted a lot of the things that jQuery started. The problem is that folks immediately turn to jQuery $(".foo") rather than use local commands document.getItemsByClassName("foo"). There are good reasons to use jQuery. There are good reasons not to. Ultimately, though, you should balance the decision on what you need to do rather than knee jerk use a tool.

2It's funny how long HTTP2

    What do you think, sirs?

    Advertisers! Be sure to read our
    Advertisement Policy!

    Blogs of note
    personal Christopher Conlin USMC memoirs of hydrogen guy rhapsodic.org Henriette's Herbal Blog
    geek ultramookie

    Powered by WordPress
    Hosted on Dreamhost.