Ones and Zeros: Cloud Castles
Once in a while I tell people I make invisible incantations and encode them in secret patterns that will be processed by specially prepared crystals. Of course, the incantations are software programming languages, the secret patterns are the files on the computer’s hard drive in magnetic patterns, and the specially prepared crystals are computer chips. It just depends if I’m feeling more fantastic or prosaic.
Software is a little odd. Software is to mathematics as engineering is to physics. But like all analogies that’s not completely accuate. Manufacturing software isn’t like manufacturing a physical item, it’s just copying the files. Making software is almost always an R&D process. But, it’s never a physical process, nothing to touch or handle. So, how to think about it?
After over twenty years of designing, writing, and debugging software, I’ve come to think about it as physical objects after all - like blocks and geometric shapes - in my head. We’re a species with hands and are used to manipulating things. So, I just imagine doing that.
I see myself as something like this guy in a 1950’s home laboratory building something with these various undefined but technical looking shapes. Of course, I’m not quite so 1950’s clean-cut looking and I don’t use that stuff to make my hair shiny either.
But all this is going on in my head. So when I’m staring out the window at the sky at work I’m really building these castles in my head. Or I’m moving things around and re-designing them. Sometimes I’m working through what I’ve built to see where bugs might be too. Then occasionally, I’m just looking at the clouds.
This is one reason why software people might be a little antisocial. It takes a lot of effort to set up all this stuff in my head and I lose the picture easily if interrupted.
Imagine visualizing all the parts of a bicycle in your head, keeping their dimensions and relative locations correct. Make this a complete visualization down to the bearings in the bearing races around the axles of the wheels. Don’t forget the crank with the pedals (and its bearings), nor the chain, the handlebar (and its bearings too) and the shifter cables, and all that.
Now, in your mind, put it all in motion and maintain that picture you had above. See the tension pull and release on the spokes as they pass over the axle. See the chain’s links working one by one.
Just by counting the parts of a bike and the parts (routines, or perhaps the branching points) of a piece of software, the bike is much, much simpler than software is. This is my job, and the job of many other people today, to keep all this stuff in our heads and see that one part not working right and to figure out how to make it work right.
Ok, it’s not quite this hard, I’m glorifying things somewhat. There are layers and modules. In a bike, once you have the axle and bearings figured out and in place, then you don’t have to concern yourself with them (most of the time) unless something goes wrong. In software, layered architectures (especially in networking) make it easy to concentrate on one thing at a time. Modularization (like the axles) means you can treat a complex set of things like a black box that does something for you when you put in the right inputs.
You can build the code, make it a module, debug it, and move on to consider some other set of details. There’s lots of tricks like that in software to make it possible to think about large systems without blowing your neurons apart. But these tricks can have their own risks too. Details can get lost. Every software person knows this, and has built up a painful sense of what details are relevant from being burned in the past.
Sometimes, we tend to carry that over into “real life” and normal conversation and annoy those around us by excessively focusing on what to “normal” people are miniscule details. It’s a job risk, I have to learn to shift gears.