Why is it that embarrassing code has a way of sticking around? The specific variety of embarrassment doesn't seem to matter (it could be hard to read, willfully inefficient, or just quirkily broken); all varieties live on equally well. Is it just that all code has a way of sticking around, and that we notice the embarrassing code more? Or is it that the embarrassing code is more likely to be written in those tough little corners that no one wanted to touch anyway, and still don't want to touch now? I don't know, but I do know every one of us has a few bits that we'd love to do over, if we could ever get the time to Do It Right.
I'm reminded of one of my most embarrassing bits every time I'm put on hold. The music comes on, I hear about three words, and then static. A couple of chords, more static. On and on.
The story of my embarrassment begins over ten years ago. The summer of 1999, I was interning at Lucent Technologies. It was my third summer there, and I was finally hacking on a product, not academic research (or IT upgrades, as my first summer had entailed).
The product was called Softswitch - an amazing new product in the early days of commercial IP telephony. The stack was some mix of C and Java, and there was a box humming somewhere with a connection to some corner of the phone system (at the very least the in-house ISDN). Interacting with telephones, over the internet, with software running on any old random box - wow! [1]
My main task was helping to flesh out the add-on module system. "Flesh out" may be the wrong term. The goal of my work was more to experiment with the extension API they had created (known as the Programmable Feature Server), and to produce a demonstration of its capabilities, as well as to provide feedback about what was missing, rough, broken, etc. In the Web 2.0 world, I'd probably have been labeled "beta tester".
Like most betas, the documentation was scarce. The rumor was that the lack of documentation was less intimidating for those that knew SS7 inside and out, but there was no way I was going to swallow that heap, and also produce something useful in three months.[2]
By late summer, I had implemented a fairly involved demo, boringly named ReminderCall. Dial in from any phone, navigate your way through Push-N-for-X menus, then eventually enter a time and record a message. At the time you chose, ReminderCall would dial your phone and play your message back to you. There was also a "web" frontend (either a Java servlet rendering HTML or a servlet talking to an applet; can't remember which) for doing the same, as well as canceling or rescheduling pending reminders, if I recall correctly.
ReminderCall was a success. They liked it so much, they used it to demo Softswitch's extensibility to MCI.
But it's not the success that I intended to talk about here. The embarrassing code happened along the way to ReminderCall.
As a way to learn how to deal with audio streams, I first implemented another application with a somewhat smaller scope. Much like beginning to learn any display-based system by printing, "Hello World," I began to learn this audio-based system by playing, "hello." A few more hours of tinkering after that, and my application could also read key presses.
Polish things up a bit, and the first app I had ready was MusicOnHold. Being 17 at the time, all geek and zero taste, my demonstration music was none other than Sabotage by the Beastie Boys (light defense: it also happened to be one of the few songs I could find for download at the time, avoiding the lack of audio hardware in my workstation).
The nice thing about Sabotage is that it sounds like noise normally. Piping it over 8-bit (or less?) mono mainly just seems to change the timbre of the noise. It wasn't until the boss asked me to find something more suitable for business-audience demonstration that it became apparent that the noise was part of the application. Glenn Miller's In the Mood sounded better on every warped vinyl it ever graced. Dee-da-da-dee-kxhxhxhxhxhxhxhx-dee-dee-khxhxhxhxh.
There was worry, and hand wringing. Email went back and forth between us and the core Softswitch developers. Was it just Java unable to keep up (this was the 1.1 or 1.2 days, and I was still a n00b, after all)? Was it the interface to the switch? The network between the boxes? It's true that the human voice requires less bandwidth to encode than something wide-frequency, high-dynamic-range like Big Band music, but I nevertheless tried re-encoding that song every which way. Things improved a bit, but still the static remained.
In the end, it was deemed more useful for me to press on and experiment with other features of the system, rather than muck about with this encoding trouble.
But there lies the perfect storm: an app no one really wanted to write, with a problem no one really wanted to touch, no one with the time to fix it anyway, and a flaw just embarrassing enough for me to remember it years later.
And now, every time I'm stuck on hold with static-filled music, I wonder whether someone just went ahead and packaged that MusicOnHold demo app with the Softswitch, and thereby forced my old, embarrasing code public. If that's the case, then, I'm sorry, so kxhxhxhxhxhxhxhx.
Footnotes
[1] I used the department's mail server for a time, to the chagrin of not only the admin, but another user trying to use that server to host their Netscape Navigator process. ⤣
[2] My mentor was also probing the reaches of the API, implementing the required wiretapping features, as I recall. She also gets credit for being the first person to introduce me to Emacs and OOP (by way of Java), not to mention a host of other enlightenment. Many thanks if you're reading this by some chance! ⤣
Categories: Miscellaneous
Post Copyright © 2010 Bryan Fink