jump to navigation

Old School Email November 19, 2008

Posted by Chuck Musciano in Technology.
Tags: , ,

Technology matures, and expectations change.  Email, designed to be a slow, reliable messaging system, is now expected to be instantaneous.  I’ve seen people send an email and then pick up the phone to call to see if it had arrived!

Twenty-five years ago, email was a hodge-podge of technologies, linking wildly different systems using all sorts of connections.  Getting a message from here to there often required knowledge of your system, the recipient’s system, and all those in between.  Email might take days to arrive, and never made it in just a few seconds.  A well-connected site could get a message in a few hours, which was considered really good performance.

Our modern person@place.com addressing scheme masks a huge amount of complexity.  Your message may actually travel among many nodes on the network to get to its final destination, and individual pieces of your message may take different routes before being reassembled at the end.  You don’t worry about all of this, of course; you just click “Send” and magic happens.

This simplicity didn’t exist back then.  Instead, your email address changed depending on where the message originated.  In essence, your address was the route your message would take to get to where it was going.  Each stop along the way was named, separated by exclamation points (known as “bangs”).  Thus, the “bang path” for my email back in 1984 looked something like this:


When the message arrived at the Georgia Tech server, it would be sent to the MIT server, which sent it to my server (trantor), which delivered it to me.  The “…” was important; you replaced it with whatever you needed to get from your machine to the Georgia Tech server.

You were expected to know what to put in place of that “…” and if you didn’t, tools existed to help you figure it out.  A vast database (ahem, “flat file”) listing every node in the network was sent around every so often.  For each node, you could see what other nodes they would connect to, and from that list you could construct a route for your message.  If your path to Georgia Tech was through kremvax and wustl, your address for me would be


You may wonder why every node didn’t just connect to every other node.  Another historical fact comes into play: phone calls used to cost money, charged by the minute and varying by the length and distance of the call.  Given tight budgets, each site would only call to other, nearby sites.  Cross-country calls were rare, especially for lengthy data transmissions.  Sending email overseas was almost unheard of.  Instead, you built a route of short hops, constrained by local phone charges, and hoped for the best

To further reduce costs, sites only dialed out every so often, and sometimes only at night.  After your message arrived at a site, it might sit for a day before the next scheduled transmission.  If that transmission failed, it would sit for another day before a retry occurred.  Mail moved, but it moved slowly.

As the modern internet began to grow, addresses began to merge.  You might use part of a bang path after sending to an internet host:


Networks were not completely interconnected, so you might route through a gateway between two networks:


It was confusing, constantly changing, and not for the faint of heart.

In comparison, email today is easy. Back in the day, email had to go uphill, through the snow, both ways, all the time. But when mail got through, you felt like you had accomplished something!  So be thankful, and be patient. Try to wait at least ten minutes before calling to check on your latest urgent message.

Lazy Developers November 17, 2008

Posted by Chuck Musciano in Technology.
Tags: , , ,
add a comment

You see it all the time on web forms: the little bit of “advice” next to entry fields for phone numbers and credit cards: “No dashes or spaces.”  This drives me crazy!

Let’s understand this: the developer is asking you, the unfortunate user, to make sure you enter data correctly to match what he needs.  Because… it’s so hard for computers to get rid of characters that aren’t numbers?  No.  Because the developer is too lazy to write the code to get rid of the unwanted characters you may type.

Ever type in a phone number with dashes, only to be dinged with an error popup chastising you to not type the dashes?  Ever put spaces in a credit card number only to be similarly admonished?  If so, you have been the victim of a lazy developer, one who deserves to have their keyboard seized and their pocket protector revoked.  That’s shameful coding, and it should be punished.

In case you were wondering, it is trivially simple to automatically remove non-numeric stuff from numeric fields.  Actually, it’s trivially simple to configure the field to keep you from typing them in the first place.  It actually takes a lot more work to check for the errant characters and pop up a window to irritate you that it does to fix the $%&^# field in the first place!  Bad developers will spend more time writing bad code that irritates the user than they will writing good code that makes life easier for the user.  Go figure.

All software development is about the end user experience.  Period.  The user experience should be natural, easy, forgiving, and rewarding.  It should not be filled with pedantic errors and foolish activities better left to the machine.  Developers who develop anything less should be ashamed, and user should complain vociferously when they are forced to use such systems.  Stand up and demand better!

Software and… Elvis? November 5, 2008

Posted by Chuck Musciano in Leadership.
Tags: ,
1 comment so far

I once learned that some paintings are mass produced on assembly lines, with each person applying a single color in a single spot.  At the end of the line, a complete painting has been “assembled.”  Much of the art in hotel rooms is produced this way.  The epitome of the genre is, perhaps, the Velvet Elvis: the perfect blend of kitsch, style, and subject that anyone would be proud to hang in their home.  It may not be art, but it sure is a painting!

A lot of software is written in the same way.  There is a common belief that you can completely control the development of software, planning each step of the process, deciding when the builds will be ready and the final product will roll off the line.  We all work to such tight project deadlines that there is little choice but to manage the development process this way.

Unfortunately, writing software is not a process.  Writing software is an art.  Just like singing, dancing, painting, or sculpting, certain people are born to write beautiful pieces of code that other, lesser mortals simply cannot produce.  For those who can dig in and appreciate a piece of code, there is true beauty inside the very best software.

Like any other art, beautiful software does not happen in predictable, scheduled ways.  It happens in fits and starts, when the muse strikes.  I can remember many times when the solution to some problem, the perfect algorithm or data structure, would suddenly pop into my head in the middle of the night.  You can beat your head against a problem all day, but the elegant solution only arrives when it is ready to be revealed.  Regrettably, it’s tough to put milestones like “Muse Strikes” into your project plans.

Now that I am on the management side of this process, I have true sympathy for the developers that struggle to deliver results when they know that the muse has not yet struck.  Lesser programmers are content to produce a Velvet Elvis, a pedestrian piece of code that gets the job done in a brute force way.  Programming artists seek to deliver art, something they and their peers will consider and appreciate.

As managers, we have to decide when we need art and when we need Elvis.  All great artists can produce a Velvet Elvis with little effort, but their spirit will be sapped if they are not allowed to create true art every so often.  Keep that in mind as you plan your projects and determine your schedules.  Know who your true artists are, and make sure they get to produce that occasional masterpiece.  And when you do, they will certainly come to you and say, “Thank you.  Thank you very much!”