It’s just data

Generation e-gap

Jim Jagielski: My son asked me if I thought that, in 30 years or so, my generation would have the same problems with that future technology that the older generation of today has. I don’t think so; sure it will be more advanced than what we have now, but we’ll understand it, at least the core principles of it. It will be an evolutionary change, not a revolutionary one, and the former is much easier to handle.

The more I look at generational changes, the more I am astonished by the ability of people to simultaneously (1) accept the rage of change in the past, and (2) presume that what is now ubiquitous will remain so.

First an anecdote similar to Jim’s.  Several years ago, my mother wanted to be able to record shows on her VCR from another source.  I assured her it could be done with the equipment she had.  She wasn’t so sure.  I went over to her house to survey her setup.  What I found was a tangled mess of wires.  While it mostly worked, I found it difficult to determine what component was connected to what.  After a few minutes, I gave up and decided to pull every cable out and start over.

You should have seen the aghast look on my mother’s face.  This quickly changed to amazement as I quickly and confidently connected the output of this to the input of that; etc.  Within a few seconds it all was working.

Since then, RCA plugs have given way to S-Video and then to HDMI.  But conceptually, the same, no?

Yesterday, a hard drive on my Linux server stopped responding.  I checked the cables, and everything seemed secure.  As I have an identical machine running Windows, the next thing to do was to swap parts until I could isolate the problem.  In this desktop, the hard drives screw into a cage which simply slides into the box, so it is a simple matter to unplug and pull up the entire cage.  Four devices in two cages gives me two hard drives, a floppy drive, and a DVD/CD-ROM drive.  In a matter of seconds the transplant was complete, and the drives worked in their new home.

Except eth0 was now eth1.  And the fixed IP address was no longer fixed.  And the clock was off by four hours as Linux prefers GMT, and Windows prefers local time.  Am I done yet?  I honestly don’t know.

I suspect the future is going to look a lot more like this.  And this.

Imagine yourself as of 10 years ago trying to fix your mother’s VCR setup 10 years in the future from now. No cables except for power - where would you start?

I had a break from computers for a few years, on the occasion I got back to the keyboard I still had some clue about the core principles of programming. I confidently started typing in upper case...

I’ve a feeling that it isn’t the rate or style (r/evolutionary) of change that is significant, just continuity of learning & familiarity. Even a small change can trip you up if you haven’t been following; you can cope with a big change if you have. There’s a pretty clear parallel with regression testing. Figure out how to apply that to VCR clocks and we’re sorted.

Posted by Danny at

I actually used to keep duplicate el-cheapo hardware components around just for this kind of testing.  The $15 video card was especially helpful for determining whether things like computer fires (no, seriously) had fried only the video card, or were the rest of the components ok?  I would kill to have every component in my system have a little button that you push when the computer is off that does a little self-diagnostic.  Fried components would obviously do nothing, and non-fried components could light up a little LED or something that tells you that your hardware problems aren’t their fault.  Alternatively, do something like they did with automobiles once they started picking up internal computers.  Give every computer component a standardized diagnostics plug that you can hook a simple testing device up to.  That way you can have the device power for doing the diagnostics come from the tester instead of the power supply, thus eliminating an extra variable.  A testing device like that could pay for itself in no time at all.

Posted by Bob Aman at

Links - 09.26.2006

Allen Holub: Just Say No to XML The TSS discussion on this article is far more interesting than the article itself. The consensus seems to be that XML “programming languages” work well enough for what they do. Deconstructing Databases This is a bad...

Excerpt from discipline and punish at

Add your comment