Parity Check

Virus from KidzBop?

I recently purchased KidzBop 10 for my 5 year old.  I plopped it into the computer and got a nasty dialog box from AVG.  Looks like this one comes with a virus - Clicker.BHL.  Anyone ever heard of it? 

AppRocket - Another memory pig

I'm a big fan of AppRocket.  I love the way it flattens my hierarchical file system and makes all files under its purview available within just a few keystrokes.  I find it especially useful for any large music collection.

My gripe with it is... it too is a memory pig.  I've maybe indexed 7500 files and to do what app rocket does - it takes up a colossal 20 megs.  2k per file.  Crazy.  Since it runs in .net, I'm sure it was written in C# and dines away at the memory buffet like a long lost member of the Donner party.  :-<

Of course, it doesn't help that its been completely abandoned.

Launchy isn't ready for prime time yet. 

Yahoo Messenger Beta - Memory Pig

I've been a long time user of yahoo instant messenger.  So I've upgraded it a few times through the years.  The performance of the application has slowly degraded through time.  Microsoft doesn't have a monopoly on that phenomenon.

So why did I upgrade to the beta?  Well, I had the false hopes that the latest version would do a better job on my laptop, which constantly bounces between a wireless  and wired connection and the constant docking and undocking that I go through at work.  The version I used could be counted on to repeatedly hang and just lock up.

So I upgraded!  Dumb.

The UI feels substantially slower.  I can see the repainting as I scroll around in the contact list.  It's not like I'm running an old school pentium at 50 MHz.  I have a respectable thinkpad thank you.  When I was looking at the task manager process list in Windows, I noticed that my process takes up a whopping 40 megs.

That's more than IE and Firefox combined!  Good lord.  Do the programmers have no pride?

Your programming language might be able to do all that, but I'd be grateful if it wouldn't eat so much of entire computer in the process.  I'll bet you dollars to donuts that buried in the brains of yahoo im is a cute little dynamic language interpreter ala javascript or ruby that devours everything in sight.

Comfortable for the programmer.  Just not for the user.

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.

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.

Published!

I've been lucky enough to be included in Joel Spolsky's latest book - The Best Software Writing I.

The essay you see in the book is an edited version of the draft.  The draft lacked a conclusion which left the reader unclear of whether I considered C++ a good thing, which I actually do despite the imagery.

My very own copy arrived earlier this evening and it was pretty neat to see my name in print.  I've only read the first essay in the book, but I'm itching to read the rest. 

I've got at least one more essay brewing, but as an incurable introvert, I'm loathe to share half baked thoughts.

C++ - The Forgotten Trojan Horse

I find C++ interesting.  No, not because my compiler can spit out an incoherent set of errors if I fail to include all of the right headers to appease the angry STL gods.  And, no, not because its population of practioners has reached a steady state and is now beginning a slow decline.

I find it interesting because there's a lesson to be learned about how it conquered an existing community.  The tactic it took was deceptively simple yet its one that technologists, especially the "system architects", rarely learn.

To understand what happened, we need to fire up the way back machine.  Before P2P, before spam, before the web, before the Internet was even close to being mainstream, we need to go back to a time when the Macintosh was still running on those old school 68k Motorola chips.

C++ was born in a world that was clearly on its way to being dominated by C.  In the late 1980's, C had become the language of choice for many CS graduates.  It was just respectable enough to be taught, and fast enough to be useable for that degrading domain of problems known as "the real world".

The only real competition that C had faced was from such powerful threats as Pascal, Basic, Fortran, and Cobol.  Pascal briefly flirted with fame but flamed out.  Basic won its market share, but could never shake the stink of its backwater roots, undeserved as it may be.

With that, we're left with the only two real contenders.  Fortran was for the slide ruler crowd and Cobol was, well, it was Cobol.  C found the then perfect balance between respectable programming language and reasonable business tool.  From there, it took over the development scene.

Now yes, of course I'm aware that there are many other languages out there.  There was Ada, but it had all the sex appeal of a 800 page requirements document from the US Department of Defense.  Nothing was as entrenched as Fortran, Cobol, and Basic across such a large swath of development arenas.

In any given system that used any of these classic programming languages, one could achieve a semi-plausible detente between most of them.  Interoperability between any of them was never perfect, but it was certainly doable.  Depending upon your operating system, Fortran could call into Cobol or even Basic into Fortran.  Link level compatibility was possible

Let's not forget that the Mac had an early love affair with the Pascal community that resulted in its Pascal calling convention and prediliction towards Pascal strings.  Fortunately, the Mac was cured of that silliness.

The C programming language fit very naturally into this tranquil world.  On most systems, C functions could call into Fortran and vice versa.

Why is this so important?  Because for any new technology to take root, it must successful leverage existing legacy into which the contender wants to take over.  That's just a fancy way of saying that it has to not require an organization to rewrite everything from scratch.  Leverage what's already there, and you're a helpful contributor.

So C come as a helper.  What makes C++ so fascinating is that it first emerges as a helper, but with enough encouragement, its transformed into the conqueror and eventually the new master to which all must yield.

The C++ language was purposefully designed to subsume as much of the existing C language as possible.  Only the most observant C++ language lawyer can articulate the areas in which C compatibility was not kept.

So what does such subsumption get you?

Existing C developers could be dropped, almost entirely unaware, into a C++ compiler.  Yes, there were performance differences in those early days, and yes C++ compiler's have a cranky streak to them.

Most C developers could be guilted into accepting such stringency.  Even the high falutin talk of the wonderous powers of object oriented programming shamed them into using the compiler.

But in reality, all of this meant was that existing C developers would continue to write C and merely append a few more letters to their compiler invocations and their world wasn't different.  Not yet.  The trap was set.

C++ made the switching easier since it easily consumed all of the functionality in an existing C domain.  There was nothing to rewrite.  The only real code change to make was to declare those old school functions with their "extern C" magic and C++ could easily consume them.

In years before, interoperability between a C function and a Fortran function required a little bit of thought and some understanding of how the two worlds work.  C++ worked differently.  Heck, it just worked.

This gave considerable power to the C++ advocates who would arrive into an existing C organization.  They could easily develop new functionality by leveraging the existing code base.  They could co-opt the system.

On top of this, C++ at least made it feasible to declare functions such that the old school C geezers could still consume them.  Granted, the old C school couldn't get access to the new fangled classes or templates, but that was ok by both parties.

The geezers weren't entirely threatened by the C++ upstarts.  And if the organization was growing, the geezers were headed for management real soon anyway, so it was just a matter of time.

Its at this point in the infection process that C++ takes over.  Not only does it leverage the features of the existing code base.  But it offers a potpourri, a smorgasboard, a veritable endless supply of doodads and useful features that the willing and intelligent developeris able to use. 

The C++ language never rammed any features down your throat.  Let's not confuse the languages stance with that of the zealots in that community.  You never had to use those OO features if you didn't want to.

But they were so tempting weren't they?  They glistened like gold and were so much fun to use.  You were young.  You didn't know any better.  You needed the money.

At first, the changes start in small ways.  The comment style changes.  /* */ evolves into //.  Shortly thereafter variable declarations are sprinkled liberally in the middle of functions.

Then the inevitable happens.  References find their way into function declarations and structs turn into classes with multiple inheritance.  Classes pick up non-trivial constructors, and critical high level functions start throwing exceptions.

By the time the sickness has fully set in, its too late.  There's no turning back.  The beauty of the transformation process is that as the code base becomes more entrenched into C++ specific features, it becomes harder to get out.  The code begets further C++ addiction.

Given the difficulties created by the linkers on most modern operating systems, C++ has to go through extraordinary silliness to make its function overloading available to mere mortals.  But its the same silliness that serves as its defense.  Once you have mangled function names, there's no hope for the rest of the classic languages like Fortran or Cobol to feel like equals.

The trap has finally triggered.  There's no going home anymore.  C++ took a classic maneuever.  Embrace, extend, extinguish.  A trojan horse.

C++ used a time tested technique for conquering a community and setting it off on a new course.  Why do battle with a community when you can co-opt them into your mission?