Spaghetti Code

My first computer experience was with a friend’s Altair do-it-yourself kit.

My first formal computer experience was the TRS-80, Model 1. We couldn’t wait to play with the brand new Model II, which had a floppy drive.

The first we owned was the Commodore VIC-20, then the 64. I remember typing programs in letter for letter from the back of “Compute!” magazine.

Back in those days, you didn’t have the space to be inefficient. And manual debugging was a pain in the rear.

We used to refer to “Spaghetti Code” as those programs that were patched together here and there, with no clear flow or documentation. As young programmers, we’d noodle around until we got something to work, even if we weren’t sure why. But you could pretty much forget about diving into someone else’s program and understanding it.

We’re several generations of programming since then, and orders of magnitude in terms of capability and utility. Yet we are still prone to forgetting the documentation here are there.

The universal concept behind Spaghetti Code is lack of communication.

  • The programmer doesn’t talk to himself, leaving breadcrumbs about how to fix future issues
  • The programmer doesn’t talk to the users, by ignoring well-written or descriptive error messages
  • The programmer fails to communicate to other programmers, who might tie into the code or the product of the code.

Spaghetti in the Cloud

Cloud computing has taken us away from the need to be our own programmers and debuggers. We’re several generations away from the computer as a thing you programmed — it’s now a thing you use. You have applications that do things, and your only interaction with the people who made the software is through those error messages.

Other than browsers, the trend is now getting away from programs. We’re moving to the cloud. But before you think that’s going to put an end to the legacy of Spaghetti, just look at how intertwined and interlaced our services have become.

For data to live on the cloud and be useful, it needs to be open in two ways: open for transport, and open for translation. There are several technologies that do this — RSS (an offshoot of XML) does most of the former, while APIs handle much of the latter. The results are what we call Mashups. If you’ve seen data taken in real-time and posted on a Google Map, you’ve seen the powerful blending of RSS and APIs that do wonders. We’re expecting more and more from our cloud services, including social networks. Which is why Facebook’s recent addition of video chat is such a problem.

All or Nothing

Facebook has become the thorn in the side of many corporate IT departments. It has become too big too ignore, and too ubiquitous to banish. The constant waves of new features are fantastic for us as users, who find new and better ways to share. But it’s not a party for Information Technology professionals, who get little-to-no notice that new things are appearing.

Many corporations operate under compliance guidelines that dictate what can and can’t be shared. Proprietary information and sensitive customer data must be retained with a level of security. Most every attachment that’s sent in an email or dragged onto a thumbdrive gets scanned for such secrets. (In those companies where you are even allowed to attach a thumbdrive.)

When Facebook suddenly added attachments to its Messaging platform, some hailed it as a wonderful competitor to Google Docs! But IT departments were caught with a quandary — can we shut it down for compliance, or do we have to kill access to Facebook to get it?

To its credit, Facebook has given enterprise-class organizations tools that cut out certain modules. You can cut out Messages, and anything connecting to Zynga, or Games, or Chat. Sadly, few IT departments know how to do this and are stuck on YES or NO for all of Facebook.

The Bigger Picture

Which makes the Skype-Facebook integration more puzzling as it was announced. Within an hour of the live stream, you could click on the chat interface and there was the video option. Hints to the coming feature were already embedded in Facebook’s chat code the day before. Yet there was no communication to corporations about how to deal with the implications. In this case, it wasn’t just a matter of whether the code plays well… it’s the impact on a whole system.

Video sucks in a lot of bandwidth. Just ask your ISP about Netflix. Imagine the effects of hundreds of your employees suddenly engaging in short little chat sessions. In some respects, it could be a revolutionary communications tool. It could render expensive video-conferencing solutions obsolete. It could cut down 30 minute conference calls down to just a few minutes, because visuals and face-to-face communication could provide shortcuts in the conversation.

But there’s still the issue of all that bandwidth. Some corporations just can’t handle that load.

It will be interesting to watch the 48 hours since the announcement, to see if Facebook can quickly answer some of those questions. Is there a way to disable video chat within a firewall? Can it be as simple as blocking access to the Skype servers? Is there something different happening to those packets, since Skype has traditionally used peer-to-peer packet switching for load balancing?

Will there be any communication at all? Or is this just going to be another movable feast of Spaghetti in the Clouds?


Share Button


  1. Something tells me THIS spaghetti monster will NOT be benevolently touching us with His noodly appendage.

  2. Bandwidth at the corporate level is almost free, corporate IS depts complaining have simply lived in the dark ages too long. It is a clear sign that they have way under invested in their basic infrastructure. As to the security issues,, that is another matter but points to the need for way better and nuanced security thinking. Of the two the security one may need the most thought, but that is really the IS dept problem, not Facebook’s. And of course Gchat has been available for ages in the browser. Since FB chat requires a Java plug-in it is easily blocked.

    • GChat is accessible through, which is blocked at the URL level. (We can access Google Docs and Google Calendar, for what it’s worth…)

      As to your assertion that corporations have “lived in the dark ages,” it’s not that easy. Bandwidth scales with the needs, as dictated by a business case. Back when it was determined that every employee got their own phone, and eventually their own computer, it didn’t just magically happen. There was a business case that made the numbers work, and there was funding allocated to make it happen.

      Video uses SO much more bandwidth on an internal network, that you can’t just throw an application on top of it that promises to blow out regular levels by factors of 10.

      Which goes to the larger point… if Facebook really DOES want to play in the enterprise, and be a viable alternative for collaboration, then it needs to act like it. Running off half-cocked with technology with this sort of impact doesn’t cut it. IT departments will adapt to change, but they have to be careful about it. There are too many critical systems that could fail.


  1. Ike Pigott says:

    Facebook's latest feature didn't come with enough documentation. Spaghetti Code |

  2. RT @ikepigott: Facebook's latest feature didn't come with enough documentation. Spaghetti Code |

  3. Ike Pigott says:

    Why some companies aren't cheering Facebook's video chat |

  4. Why some companies aren't cheering Facebook's video chat |

  5. Ike Pigott says:

    Facebook needs to be more conscientious about how it deals with corporate IT |

  6. Karen Bice says:

    Spaghetti Code | Occam's Razr: #fb #IT via @ikepigott