Saturday, 5 August 2017

On Interfaces

Swami Gulagulaananda said:
Every person is the same from the outside, and the insides are merely implementation details"

A long time ago, I was introduced to an interesting concept called The Black Box. A box that takes something in and gives something out - and what it did to convert the input to the output is not something that we are supposed to be concerned with… It is a black box, and its insides are opaque to us.

The black box paradigm can be used in a multitude of places and is very useful to simplify flows of thought processes. You move away from the so called 'Implementation Details’, the nitty-gritty details, the brass tacks if you will and assume that whatever is inside performs its duty.


In our electronics course, a cell was often connected to a load. The cell didn’t really care about the load - it’s job was to supply voltage and current. The consumption was the load’s job and not the headache of the cell. The load itself could have been a bulb that could glow, a motor that could turn or a buzzer that could make some noise… The load is a blackbox as far as the cell is concerned. Similarly, if you add a switch to this circuit, the switch itself can be treated as a blackbox. The ‘switch’ in this case need not be a mechanical switch that our minds immediately went to - Rather, a switch is a device that can be used to complete or break the circuit. The switch, thus, could be an LDR (Light Dependent Resistor) that could complete or break the circuit depending on the intensity of light falling on it, a push switch, a toggle switch, etc.

This way of thinking is interesting because the only aspect defined at the beginning is the behaviour. We can develop modules in this manner and stitch them together. Google’s ambitious project, Ara (is it dead yet or still alive?) is a great example of the blackbox idea. The phone has slots for you to add or remove pieces - camera, another screen, a larger battery - You could remove one piece to add a different one.

Amazon Web Services (AWS) has made good use of this concept in their data pipelines offering. Read data from a source, transform it and save it to a destination location. The source could be a database like Oracle, an S3 bucket, DynamoDB etc. and the desination could be… well, Oracle, an S3 bucket, DynamoDB etc. This means, you can read from Oracle and save to Dynamo, read from Dynamo and save to S3 etc. The source and sink are treated as blackboxes as far as we, the end users are concerned and the ETL happens internally by itself.

This kind of pluggable architectures makes engineering very easy. When we were in college, using an Atmega 16 microcontroller was a big deal. We had to solder together the IR LED, sensor, resistors and capacitors to create an IR sensor module, burn code into the chip, and do a whole lot of work ourselves. Now, all these sensors and other useful devices come as modules or shields. You just plug them together and they just work. You can swap one out and swap in a different one without any issues.

This concept is of course not new. In the world of programming, this is called an Interface.

By building standards, everyone should be able to make their products work well with one another. For example, a micro USB phone charger can charge a variety of phones irrespective of manufacturer (except Apple, of course) This brings down the cost of devices and spare parts and also opens up a world of choice. If I don’t like Company A’s camera lens, I can swap it for Company B’s lens in my phone. Imagine having Honda’s engine in a Hyundai body.

It introduces some limitations, but also opens up some opportunities… Do you think that such a world is possible? Do you see any immediate pitfalls?