Putting the 'soft' into software
By Sean Mc Grath
It used to take me about 25 minutes to walk to the bus stop from my place of employment as a part-time software developer in Dublin in 1984. Being a geek, I used to work late sometimes and leave a wafer thin margin of error to catch the last bus home.
One night I missed the bus. The reason being, I had walked most of the way to the bus stop before I had a horrible thought. I could not be absolutely sure that I had unplugged the soldering iron in the office! My imagination full of flames and pink slips, I walked back to check on it and subsequently missed the bus. An expensive taxi-ride for a penniless student ensued.
What was I doing with a soldering iron I hear you ask? In those days, there was more hardware in software than there is today. By that I mean that software specialists were expected to know a thing or two about DIP switches, RS-232 pins, centronics interfaces and so on. Indeed, it was difficult to function without some knowledge of these things back then. We worked with the backs of our machines slightly ajar with a Philips screwdriver always to hand.
An RS-232 cable had been my nemesis that night. I was writing communications software and used to spend an inordinate amount of time cooking up cables that used some subset of the 25 pins available on an RS-232 cable. I was terrible at it but I am glad of the experience. For one thing, it removed all shadows of doubt in my mind that my future did not lie in hardware. Also, it planted the germ of an idea for the article you are now reading.
I think of that humble RS-232 cable as a good example of the relationship between software and hardware and how that relationship has changed over the intervening 20 or so years.
In those days as I have said, an RS-232 cable had 25 pins. Over the years, RS-232 has diminished in terms of hardware complexity and increased in terms of software complexity. Synchronous control for example, disappeared from the hardware through disuse and a 12 pin version of the RS-232 connector became popular. Synchronous behavior, which was lost in the downsizing to 12 pins, was emulated in software where required. Some of the remaining pins supporting flow control fell into disuse in our shop too. We used to implement it all in software, relying on the hardware for as little functionality as possible.
Somewhere along the line I remember noting that we were regularly implementing RS-232 systems, complete with fancy auto detection, flashing lights, compression, error correction and flow control all done in software. We only ever used three pins out of the original 25 on the RS-232 interface, namely, receive, transmit and ground. We used to call it a two pin interface. (The ground pin was purely electrical, it had no logical function.)
Why did we plumb for ultra-simple two-pin interfaces? Why do all the heavy lifting in software? One word - flexibility. Software is considerably easier to change than the soldering of an RS-232 cable. Even if the hardware solution is better in some technical ways than the software solution, software methods tend to win because of their added flexibility. Flexibility is a must-have in a crazy world as you may have noticed.
I see a similar pattern at work all over the hardware/software landscape. It seems to me that hardware interfaces are getting simpler and simpler in terms of "moving parts" with all of the smart stuff pushed up the stack into the software that drives the hardware. I think that is an interesting trend that is trying to tell us something. Perhaps it is trying to tell us to look again at our software concept of 'interface'? What is the software equivalent of an RS-232 connector? It is its object interface. How many pins does a typical software interface have? Gee, lots...
A traditional object from object-oriented programming might have anywhere from 2 to 400 individual pins. Each with its unique function, each of which will need to be lovingly soldered (metaphorically speaking) to a pin on a receiving object.
What would a simplified software interface look like? Well, by analogy with the hardware world, it would be one that just supported the basic receive and transmit functions. A real world example? For 'receive' substitute 'GET', for 'transmit' substitute 'POST'. In other words, HTTP.
Am I stretching the comparison too much? Probably, but there is more than a grain of truth here in my opinion. Traditional objects, with their multi-pin interfaces have proven to be brittle, to lack in the all important area of flexibility. Along comes HTTP which is the software analog of a two pin interface and it takes the world by storm.
Conclusion? Maybe HTTP is onto something here. Maybe before we buy too many soldering irons (WSDL's are a common brand), we should take a closer look at how we can avoid soldering altogether? Maybe we need to put more 'soft' into software.