Computing stuff tied to the physical world

Virtuality vs Reality

In Musings on May 23, 2012 at 00:01

The worlds I dabble in at JeeLabs are twofold:

  • Software – a virtual world, artificially constructed, and limited only by imagination
  • Hardware – a real world, where electrons and atoms set the rules and the constraints

I’ve long been pondering about the difference between the two, and how I enjoy both, but in very different ways. And now I think I’ve figured out, at last, what makes each so much fun and why the mix is so interesting.

DSC 3208   DSC 3209

I’ve spent most of my professional life in the software world. This is the place which you can create and shape in whatever way you like. You set up your working environment, you pick and extend your tools, and you get to play with essentially super-natural powers where nearly everything goes.

No wonder people like me get hooked to it – this entire software world is one big addictive game!

The hardware world is very different. You don’t set the rules, you have to discover and obey them. Failure to do so leads to non-functional circuits, or even damage and disaster. You’re at the mercy of real constraints, and your powers are severly limited – by lack of knowledge, lack of instruments, lack of … control.

Get stuff working in either world can be exhilarating and deeply satisfying. Yes! I got it right! It works!

All of this appeals to an introvert technical geek like me, and all of this requires little human interaction, with all its complex / ambiguous / emotional aspects. It’s a competition between the mind and the software / hardware. There are infinitely many paths, careers, and explorations lying ahead. This is the domain of engineers and architects. This is where puzzles meet minds. I love it.

The key difference between software and hardware, when you approach it from this angle, is how things evolve over time: with software, there is no center of gravity – everything you do can become irrelevant or obsolete later on, when a different approach or design is selected. With hardware, no matter how elaborate or ingenious your design, it will have to deal with the realities of The World Out There.

So while after decades of software we still move from concept to concept, and from programming language to programming language, the hardware side more and more becomes a stable domain with fixed rules which we understand better and better, and take more and more advantage of.

In a nutshell: software drifts, hardware solidifies.

Old software becomes useless. Old hardware becomes used less. A very subtle difference!

The software I’ve built in the past becomes irrelevant as it gets superceded by new code and things are simply no longer done they way they used to be. There’s no way to keep using it, beyond a certain point.

Hardware might become too bulky or slow or power-consuming to keep using it, or it might mechanically wear out. But I can still hook up a 40-year old scope and it’ll serve me amazingly well. Even when measuring the latest chips or MOSFETs or LCDs or any other stuff that didn’t exist at the time.

Software suffers from bit rot – this happens especially when not used much. Hardware wears out, but only when used. If you put it away, it can essentially survive for decades and still work.

In practice, this has a huge impact on how things feel when you fool around – eh, I mean experiment – to try and to learn new things.

Software needs to be accompanied by documentation about its internals and it needs to be frequently used and revisited to keep it alive. Writing software is always about adding new cards to an existing house of cards – assuming I can remember what those cards were before. It’s all virtual, and it tends to fade and become stale if not actively managed.

Hardware, on the other hand, lives in a world which exists even when you don’t explore it. Each time I sit down at my electronics bench, I think “hm, what aspect of the real world shall I dive into this time?”.

I love ’em both, even though working on software feels totally different from working on hardware.

  1. thanks for another interesting post! are we going to have any introductory software lesson like the ones you recently provide us on the hardware side any time soon? I am anxious to have something about Tcl and how you use it as a good partner of your hardware projects…

  2. Nice post. Actually “bit rot” is also a more a hardware then a software thing.

    • Actually, if you follow JCW’s link to Wikepedia, you see it’s allegedly used for both data loss due to hardware degradation (e.g. demagnetisation of HDDs; and for “dormant code rot” where software that is not maintained gradually or suddenly loses functionality because of broken dependencies or dormant bugs that suddenly surface.

  3. “super natural powers”, mixed with the fact that you have to “obey”. Didn’t you just now discover a slight SM inclination ;-)

Comments are closed.