Less is more : Latency is more than just a network thing

Could you imagine driving a car where the steering wheel wasn't very responsive?  How good of a driver would you be if you had to make your steering adjustments 30 seconds in advance?  Driving on a highway would be nearly impossible, as you and everyone else around you would have to plan for the actions and reactions of everyone for the next half minute.  You would have all the finnese of a 7 year old kid at Disney's Tomorrowland Raceway.

More to the point - what if you had a simple programming assignment.  Your job: Modify a hundreds files that are stored on a remote server using your favorite editor.  The only limitation is that you can't transfer the files to your local computer.  Edit them remotely you will.  Put on the noise cancellation head phones, spin up your favorite playlists and you're on your way.

But what if I gave you a connectivity choice?  You can go with the fancy pants T1 or an old school 56k modem.  Which one would you choose?  Well, duh, everyone is going to choose the T1.  How could you not choose a T1?  I mean, come on, a T1 vs. a modem?  That's not even a fair contest.

But what if the latency of the T1 was 250ms?

I don't know about you but I *have* to go with the modem.  When I type I can see that I'm doing the right thing, so I keep going.  If I'm doing well and the typing is smooth, I'll type faster - rising to the challenge of keeping up.  The clicks of my keyboard  can match the clicks of the crisp monospaced characters that I see on the screen.

The synergy from the interaction of keyboard to screen is wonderous.  It's The Flow, the zone, that moment of productivity when there are no roadblocks, only typing.  The only "thing" discernible is that of forward motion.  Zip zip along.  No interuptions.  Just you and the machine.  No discrete steps.  Just motion.

My fingers slip every so often, but that's ok, because the feedback is instant.  I know I've typed the wrong thing.  I back up, edit it, and keep going.  I compensate.  If the code is tricky, I slow down.  It's the instant feedback that allows me to adjust.  The speed of the response is what enables me to move ahead as quickly as possible.

When the latency gets worse, my personal productivity bandwidth goes down.  My typing deteriorates significantly as my keyboarding no longer feels interactive.  I start to stumble as my typing runs ahead of the clock of reality.  I fall off the tracks and my typing runs amuck.  I'm off in the weeds.  My thoughts jumble together.  I get lost.

We live in a world where we are inundated with the idea that more is always better.  Clock cycles go up (at least they used to).  Hard drives, monitors, camera megapixels, version numbers of our favorite programs... more more more up up up.  Not that there's anything wrong with that.  But
we're so conditioned to living this way that we short sell the kind of numbers that should go down.

I think we're so used to thinking about "bandwidth" that we overlook "latency" in all of its forms.

For example, Paul Graham and the lispnicks derive some of their smug superiority [1] from their beloved REPL because it removes the latencies inherent in the edit, compile, link, run, debug cycle.  If the cycle takes too long (ie: if the latencies get too high), you stumble and lose momentum.  Or better, you alt-tab away and spend time in bloglines.   

Joel makes a solid case for a daily build  - which lowers the latency for a developer to see their changes.  Code goes in and hours later - binaries pour out.  The faster it comes back at you, the faster you can put it in again.  You can make adjustments in real time or close to it.  Those automated mechanisms reduce the roundtrip time of thought in and product out.

And that's what software development is really about.  Right?  Thoughts go in which are translated into code and then "product" comes out the other side.  So simple.  This happens at all levels of development whether its an inhouse class framework, a project on sourceforge, or a million dollar product with 50 cooks in the kitchen. 

Thoughts in.  Product out.  Software development is a conversation.  Which leads to a curious trait about latencies - latencies change the sturcture of a conversation.

What you say, and how you say it changes based on the mode of communication.  How you structure a written letter, or even a lengthy email is fundamentally different from an instant message conversation.  You can express the same ideas in all mediums - but how you do it, and how quickly you can get to your end goal is heavily influenced by the latencies involved.

You can see this effect even when making a phone call to a far away place.  There's just enough latency in the conversation to break up the flow - both parties move ahead with the graceful walk of a potato sack race.

For the developer working alone, it's just you and the machine.  But if you working as part of a group, you'll have a set of folks surrounding all of those coders.  Those folks sit at one end of the idea factory and the compiler sits at the other end.  What happens in the middle is a lot of talking,
frequently too much of it in hushed mumbles.  The talking becomes more focused when it can be feedback in near real time.

I think all of the hullaballo about extreme programming and its less rigid extended family - agile practices - was about lowering the latencies in the development cycle.  Most of their good practices focus on just that.  That's when the structure of the development conversation changes - it becomes real time and it becomes interactive. 

And don't forget that long latencies are a great way to drive engineers out of an organization.  I think that's another way of looking at what was bugging Marc Lucovsky at Microsoft.  Engineers puts code in.  Long pause.  Long pause.  Long undramatic pause.  And then stuff goes out to the users.  How completely unrewarding.  What's the point?  There's no payoff.

Software developers may seem like an introverted crowd with a disposition towards anti-social grooming practices, but like everyone else, they want feedback.  They want a sense of impact on the world.  Software is such an abstract craft that getting a real tangible payoff can be elusive. 
Latencies only add to that ephemeral nature.

One great way to improve software development is to squeeze the longest latencies out of your development conversation.  It's the best way to keep you zipping along the great competitive highway and avoid those nasty concrete dividers.

[1] Well, lispnicks have lots to be smug about.  Market share isn't one of them though.

Update:

Originally submitted for Joel's second book of essays, but since that's been shelved - I'm curious to see how the reddit.com crowd rates it.

Comments

[Bron Gondwana]

Funnily enough, I do a large part of my work at 250ms, and there's not much I can do about it. I work in Australia, and my servers are in New York. If I'm doing a lot of coding at once then I'll set up a bunch of fish:// URLs pointing to the files and edit them locally, but it's certainly possible.

Reading this has prompted me to think again about spending more time in a local editor with a copy of what's on the server and a good synchronisation system though.

[Apoch]

Absolute truth.

This becomes more disruptive - and less noticeable - on larger timescales. A quarter-second latency on typing is obviously a visible annoyance; but what about all those little ten-second pockets of idleness? What about ten or twenty minute build cycles that leave us surfing the web, usually until well after the build is done?

I like to think of this as the "downtime is deadly" principle:
http://www.gamedev.net/community/forums/mod/journal/journal.asp?jn=345337&reply_id=2678039