Less Is More

Imagine if you had a simple programming assignment.  Your task is to modify a few hundred 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 and you're good to go.

But what if I gave you a choice for your network connection?  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 550ms and the modem's effective latency was 90ms?  Now which one would you choose?

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.  Coder's high.

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 increases, my personal productivity bandwidth decreases.  My typing deteriorates significantly as my development no longer feels interactive.  In fact, 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.

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?  If that's what you were faced with you'd drive very slowly!  Right?  If you're shaking your head no, please let me know when you hit the road so I can stay off.

Software engineers rarely think about latencies until they suffer from frag lag.  I think that's because we're surrounded by things that improve by growing.  Our cpus get faster when the clock cycles go up.  Memory increases.  Same for hard drives and bandwidth.  Up up up.  Big big big. More More More.  Good good good.

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 gets 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.  It lowers the latency for a developer to see their changes.  Code goes in and binaries come pouring out within hours.  The faster it comes back at you, the faster you can put it in.  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 multi-million dollar product with 50 cooks in the kitchen.

Thoughts in.  Product out.

Software development is a conversation.  At least it can be.  For the individual 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.  The talking becomes more focused when it can be fed feedback in near real time.

I think all of the hullaballo about extreme programming and the agile family 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. 

In the end, it's not about having people type faster at their keyboards, it's about finding
the things in your process that prevents your software development efforts from becoming a conversation.

It's not the bandwidth, it's the latencies.  Less is more.

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

Comments

[Ben]

Ah, monospaced fonts... They can be such a love affair. My current mistress is Bitstream Vera Sans Mono, found at http://www.gnome.org/fonts/. Try it, I think you'll like it.

[the Grinning Fool]

Do you know that you're the only other person I've encountered who used the phrase "coder's high"?