Monday, January 9, 2017

Spaghetti of Things

Spaghetti software was a popular term in the 90s, when I just started to learn programming. When a tool is given to someone who does not plan for dimensioning, scalability and extensibility, the end result becomes a spaghetti. And I did create a couple of spaghetti-projects myself, with all my love to quick-fixes and limited time to hand in assignments at university. Spaghetti code requires shorter starting curve but is not future proof. 

Similarly, "spaghetti" can easily be created when Internet of Things solutions are put together. A couple of years ago my team at Ericsson Research has created a prototype of a fully automated logistics system that consisted of some 100 sensors and actuators and used a control algorithm that could deal with any number of resources (vehicles, cranes, cargo) and adjusted to new logistics tasks and resource changes in real-time. No spaghetti code here. And a very beautiful demo that we presented at Mobile World Congress'2015. Underneath, however, was a "spaghetti" of cables, simply because not all of our devices were capable of wireless connectivity at that time.


Another example could be found at our place 5 years ago. I called it "brain of our apartment". A couple of net disks, wireless router, and even a stationary phone(!). Now we don't have cables any more, all is wireless and in the cloud, and still, there is a risk of creating virtual spaghetti. Ordinary users of a home kits such as Apple's or Telldus' can now easily automate their homes without any knowledge of the underlying technologies as all the complexity is hidden. The invisible cables will however connect our fridges, tv-boxes, coffee machines and temperature sensors to different servers and when you ask your TV to check how your cigars are doing, your AppleTV will send a request to an iCloud server somewhere in the world to decode what you actually meant by this phrase, get back your request in a machine-readable form, send it to your Apple HomeKit, further to the HomeKit application server, back home, then to Telldus server somewhere in the world, back home to the cigar humidor where the humidity sensor is placed, and all the way back to your TV to deliver the answer to your question. No wonder that responses can take time. And the loger the chain of events the longer the response times. Instead, the involved cloud services could talk between themselves and deliver back an answer, and hopefully they can find a "close" friend to discuss.