Stop Whining And Get Over Yourself

A Disturbing Theme

There has been a recurring theme in programming blogs over the past decade or so that continues to get my ire up each time I encounter it. Some entries tiptoe around this theme without ever coming out and state it. Others state it so boldly that I am left with no choice but to roll my eyes or to fume at them and leave a nasty YouTube-style comment. Many authors with incredibly wide readership and influence have repeated this theme using different words.

Can you guess what the theme is?

Maybe a few quotes will help:

• "I think all software is crap" - Steve Yegge
• "all my software is shitty" - Jeff Atwood
• "Software is Crap" - davmac
• "it's all a mess. Everyone sucks, equally and completely." - Scott Hanselman

Shall I go on?

It seems that everyone with an opinion and access to the internet is writing a post bemoaning the sad state of affairs in the world of software. They complain that every single system is utterly flawed at the deepest level and is at risk of crashing immediately if we dare even look at it the wrong way.

A Dose Of Reality

Now, don't get me wrong. There is software out there that is crap. I've even written some of it myself. I feel, however, that saying that all software is crap, or even that most software is crap is far from the truth.

In the process of creating this post I have already interacted (both directly and indirectly) with many different software systems. I used my operating system, its user interface, and various hardware drivers to launch and control a web browser. I used my browser to search for and visit many different websites. Each of these sites is running at least a web server, and most have additional scripting and database systems that work with it. All of that data passes through multiple systems in transit over the internet. Guess what? I have not encountered a single noticeable error up to this poin...NO CARRIER

...

To my readers old enough to get the above reference, I apologize for subjecting you to such a terrible joke. To those younger readers who are scratching their puzzled heads, I apologize for subjecting you to such a terrible joke that you did not even understand.

The fact of the matter is that most of us use a wide variety of software each and every day. Occasionally we encounter a problem that interrupts us or prevents us from accomplishing the task at hand. It may be the blue screen of death disrupting our career-defining presentation to a high-profile client, or our browser freezing halfway through a video of adorable cats diving head first into slightly-too-small boxes. The rest of the time, our software is quietly plodding along in the background and doing its job so well that we barely recognize it's doing anything at all.

It's like that old caretaker at your company that most people were aware of, but nobody could quite tell you what he did. He worked after hours when everyone else had gone home for the night. You might have run into him that time you returned to collect something you had left in your office. Maybe he vacuumed the hallway outside your door that time you stayed late to finish your essential project before the deadline. When he retired, everyone suddenly noticed how so many subtle niceties around the office had changed . When a system is working well, we may not even realize how much we take it for granted until it is gone.

Most software that gets noticed is like the annoying guy at the office who all the managers praise, but nobody wants to work with. He feels the need to add his input on everything and boasts about his "expertise". Trying to integrate his work with the rest of the team sets everyone back as they struggle to correct all of the problems he's caused. He manages to assign the blame to the soft-spoken fellow who sits by himself in the lunch room. When he manages to take credit for the eventual success of the project and parlay it into a promotion, everyone else on the team breaths a grudging sigh of relief that at least they don't need to deal with that guy anymore. This is the bad kind of getting noticed.

The fact of the matter is that for every annoying software system that stands out in the wrong way, there are dozens of others that you barely even notice. You don't notice them because they perform their designated task in silence while you're busy watching groan-inducing videos of skateboarders landing crotch first on the railing instead of stylishly grinding down it.

Professional Pride

I don't know about everyone else, but when I step back from a challenging project that required lots of hard work, time, and energy, I take a certain amount of pride in it. I enjoy seeing efficiency improve as people use my system to accomplish tasks that used to take an order of magnitude longer and require tedious, manual effort. I enjoy creating new software realities out of mere ideas and possibilities.

In any system large enough to be proud of, there will inevitably be some problems. When the bug reports roll in, I don't just throw in the towel and bemoan the fact that I've created yet another crappy system. No, I roll up my sleeves and get to work. I fire up my IDE and get started debugging my code and developing a fix. Depending on the operating environment and the nature of the bug, I can have a fix ready and deployed within hours - delivering a working solution to an eager customer who is (hopefully) pleased with such prompt resolution for their issue.

When I watch users struggle to control my software, I don't just sit back and whine about how I've created yet another clunky user interface. I go back to the drawing board and come up with new ideas on how to make the user interface easier and more intuitive. I perform usability tests with ordinary folks who are trying my software for the first time. I iterate over new designs until I find a solution that is user friendly and simple to understand.

What They Really Mean

Perhaps I'm taking these people too literally. If their point is to acknowledge that most software has bugs and it's nearly impossible to create "perfect" software, then they've got it right. Developing software is challenging. Just when you think you've achieved a new level of competence, a new bug rears its ugly head. The bug mocks you as you sweat and furrow your brow, struggling to figure out what has gone wrong. When you finally figure it out, panting and exasperated, you smack your forehead for overlooking such an obvious flaw.

The good news is that with each boneheaded bug you create and fix, there's actually a chance you might be able to avoid making the same mistake again in the future. If you keep your head down and work hard for many years, you may just learn to create software that isn't a flaming ball of garbage. That said, even the best of us have days when our brains are just not on their game and we write a fancy version of while( 1 ) fork(); Don't lose faith. Keep going and continue striving to become a better developer. In time, you will gain a new level of competence and, at very least, you'll know enough not to let your guard down the next time you're feeling like a project was too easy.

Cheers,

Joshua Ganes

Is It Easier To Write Code Than To Read It?

The Premise

A recent Programmers Stack Exchange post reminded me of a seemingly widespread belief among programmers - writing code is easier than reading code. In his post, "Things You Should Never Do, Part I", about not writing software from scratch, Joel Spolsky writes, "It’s harder to read code than to write it". Most other posts I have found on this topic seem to reference Joel's article. They nod along in agreement as if to say that, once revealed, this premise is gospel truth and cannot be denied.

Horror Stories

Any programmer who's been around the block a few times can remember some godawful snippet of source code that warped their minds and nearly broke their will. Foreign (AKA not mine) source code may be difficult to understand for a variety of reasons. It may be oddly formatted, use poorly named variables and functions, have confusing organization, or seriously lack comments. Other than code full of "clever" tricks (why multiply by 8 when you can just use the bit shift operator?), I believe the most difficult code to read is simply at a level of complexity beyond the expectations of the reader.

Since everyone seems to recall a story about an undecipherable code base from their past, it becomes easy to latch onto Joel's premise. We know that if we aren't careful about our code choices, it can grow into an unholy mess full of badly-named functions full of side effects that run over multiple screens. It's easy to get code into this state and it's difficult to deal with maintenance once the damage has been inflicted. In this sense, Joel's premise is correct.

Defining Difficulty

If we ignore "bad" code and focus on "good" code, I believe that the picture changes. Writing good code is hard. Choosing meaningful and descriptive names for variables and functions is difficult. Structuring and documenting code so it's easy to understand and modify is a constant struggle. Self-documenting code contains all kinds of clues about the purpose of each component and demonstrates how each piece interacts with the other.

I think that part of the problem comes with the vague way we define difficulty. What makes one task hard and one task easy? There are several ways to measure difficulty. Some are more meaningful than others.

I think some of us choose to define difficulty based on our interest in performing a task. Clearly, watching TV is easier than washing the dishes. This measurement breaks down when a task is both challenging and interesting. I'd much rather climb a rugged mountain trail than take out the garbage, but scaling the mountain provides a much bigger challenge than dragging the trash to the corner. Programmers love writing code because of the intellectual challenge and the joy of creating something from nothing. Understanding the work of another coder does not generally hold the same appeal.

When it comes to business, a much better way to measure the difficulty of a task is in the cost in resources. In this case, we're talking about the time and effort of a programmer. It may not be fantastically interesting to decipher someone else's code, but given a well-written code base, understanding comes with perseverance. Rewriting the same piece of code (larger than a few hundred lines) to the same level of quality will require an order of magnitude in extra time.

Discipline

Here's the bad news: every field has unpleasant tasks. As a programmer, I prefer writing new code over maintaining old code. When someone proposes an unpleasant task, people tend to come up with all kinds of excuses to avoid it. This is as true for programmers as for anyone else. The excuses pile up until we talk our way out of doing the unpleasant task.

Unfortunately, as professional software developers, we're not being paid for pleasant. We're being paid for results. Great developers recognize this and exercise discipline. They buckle down and read the code carefully. They are able to understand it much more quickly than it could be rewritten. Once they understand the code, they make their changes and move on.

The good news is that if you follow this approach, you'll get things done quickly and be able to move on to new projects. Reading good code instead of rewriting it will result in a higher level of productivity. Your boss may just take notice and reward you for your efforts.

Cheers,

Joshua Ganes

Standard vs. Real-Time Unix Signals

Software Architecture

Imagine the following software architecture: a single parent process manages multiple child processes. The parent and child processes send Unix signals to manage and trigger activities between the two processes.

You've tested this basic functionality under reasonable load and all looks well. After initial deployment, everything is looking great. It's time to turn up the volume and bring more activity and clients on board.

After some time, a new bug report comes in saying that some requests are being lost in transit. Your logs show activity hitting the child process. You see the child signaling the parent to perform its next action. You see the parent handling a variety of signals from other processes, but the one from the relevant child process is lost to the mysterious void of /dev/null.

The Reliability of Standard Signals

It turns out that there are two classes of Unix signals: standard and real-time. Standard signals run from 1-32 and real-time signals typically run from 33-64 (Be sure to use SIGRTMIN and SIGRTMAX to avoid compatibility issues).

It also turns out that standard signals, while guaranteed to be delivered to a process by someone, are not guaranteed to be delivered by each process that sends them. This means that if multiple child processes send the same standard signal in a short period of time, the parent process may only receive one signal.

This is where the magic of real-time signals comes in. These signals can be queued and will be delivered for each process individually. Use sigqueue() to add signals to the queue of waiting signals. Be sure to check the return value for errors to prevent creating new bugs.

Cheers,

Joshua Ganes

When Advertising Crosses The Line

Exploration

After publishing my first few posts on this blog I became curious about all of the available options to control it. I ran through the list of tabs reading the options and thinking about which ones I might adjust or tweak. I got to the "Earnings" tab and suddenly perked up a bit. I know that successful bloggers with thousands of regular readers can earn a tidy profit by allowing advertising space on their blogs. Now, my readership is nowhere near those numbers. My earnings, if any, wouldn't add up to more than a few dollars a month. Still, in my ever-optimistic mind, I smiled at the thought of my blog achieving critical mass and earning me a steady stream of cold, hard cash.

Human Behavior

What is the number one extension or add-on for web browsers? Well, that partially depends on who you ask. Most top-10 lists will be sure to feature AdBlock somewhere, with many placing it in the topmost spot.

Do you fondly remember the early days of YouTube? Early on, you could view a video without the need to hover your mouse for five seconds before rapidly dismissing an advertisement. Admittedly, not all videos have this problem. Google (who owns YouTube) allows flexibility for channel owners to decide how invasive the ads should be.

Have you noticed that since PVRs have become commonplace, watching live TV seems, somehow, more painful than it used to be? Those commercial breaks we used to tolerate are now prolonged interruptions leading to impatience and frustration (unless you needed the bathroom break). Many people have become self-professed experts at fast-forwarding over the commercials and hitting play just in time for the show to return.

It seems, based on our behavior, that people don't like advertising much. We block it, we skip it, and we change our habits just to avoid it. Some of us have even begun changing our brains and started developing banner blindness. All of these facts start to make a person wonder how anyone can advocate advertising at all. Surely, those people must be trying to justify their greed for those shiny advertising dollars.

(...and don't call me Shirley)

The Other Side

Quick: What are the ingredients in a McDonald's Big Mac? Go!

(highlight to view the answer):

Two all-beef patties, special sauce, lettuce, cheese, pickles, onions on a sesame-seed bun.

Did you get it?

How about this one? Complete the following jingles:

Oh, I wish I were an Oscar Mayer wiener.
Plop, plop. Fizz, fizz. Oh, what a relief it is.

Each one of these marketing phrases was broadcast several years before I was born. How could I possibly be so familiar with them? It seems that some advertisements have a certain je ne sais quoi that allows them to endear themselves to us and become part of popular culture. They have become burned into the cultural psyche.

One of my personal favorites was Molson Canadian's "I Am Canadian" advertising campaign. This series of ads inspired a wave of national pride and fraternity for Canadians (this was before the Canadian Molson and US Coors companies merged). These ads connected with me personally and helped to fill me with pride in my country.

When I was a kid, say seven or eight, I used to like some of the commercials more than the television shows. I would play in our living room while my parents watched TV and I would perk up only to watch my favorite commercials. I loved to sing along with the catchy jingles. I loved the brightly-colored and animated commercials most of all.

I don't think you would find many people complaining that a restaurant puts a simple sign outside of its doors inviting customers inside. I certainly can't complain when they slap enticing pictures of their tasty dishes in the window. Some people love to window shop. They love just looking at the stylish displays in the store windows which beckon consumers to come inside and check out their other products and deals. Most people won't balk when an acquaintance offers them a business card if it suits the topic at hand. This sort of available enticement tends to be overlooked as a form of advertising.

It seems to me that it's not as simple as judging advertising as good or bad; right or wrong. Clearly, some ads bother people more than others. Some may even inspire them, or at least amuse and entertain them. Others manage to get their point across without ruffling too many feathers. How, then, can we know which are good and which are not? When does advertising cross the line between acceptable and questionable?

Crossing The Line

I think we can all agree that we don't want to be treated like a sucker. Nobody likes to play the fool. Advertising should not bend the truth, and most certainly should not lie to you outright. This sentiment is even built into our legal system. Perhaps most abhorrent of all is the ads that are misleading in their purpose. They entice you with an offer that sounds too good to be true. Those foolish enough to fall for the bait will be taken for a ride and dumped unceremoniously out on the curb, their wallets lighter for the experience. Don't forget web page ads that disguise themselves as content.

Have you ever met a salesman who won't take no for an answer? Did you enjoy the experience? When someone puts information out in plain sight for me to see, I can choose to engage with him or choose to ignore him (recommended). If that person then begins to hound me as if I just wasn't paying attention, it can really get my hackles up. Guess what, I saw you just fine the first time and chose to walk past you. How likely do you think you are to get anything good out of me now that I have been interrupted?

In much the same way, aggressive in-your-face advertising tends to receive very negative reactions. People begin to curse not just the products being sold, but the people who made them and their ads. Most people are content to ignore modest web advertising and continue browsing the site. When the advertising becomes more intrusive, the reaction becomes stronger. Who hasn't thrown at least a minor fit trying to find the browser tab with the obnoxious smiley face ad complete with sound effects?

My final guideline to avoid crossing the line is directed at service and content providers: don't double-dip. No, I'm not talking about the time George Costanza double-dipped his tortilla chip. I am talking about when providers try to accept money from both advertisers and consumers. This can be seen in various forms: a movie theater showing ads before the movie that patrons paid $12 a piece to see; magazines or web sites charging a large monthly subscription fee, but still cramming tons of ads between the content; DVD or Blu-ray discs that play unskippable ads when they start up. Why should consumers pay good money to watch your advertising? Who are you serving? Make up your minds already.

Getting It Right

It seems that the path to advertising with a clear conscience is fraught with pitfalls. With so many ways it can be done wrong, we will need some guidelines for getting it right. Where can we start?

If you're going to interrupt me, make it worth my time. As I mentioned earlier, some forms of advertising are more invasive than others. Some forms are a pure and unadulterated interruption. If you're going to interrupt me, please do whatever possible to appease me. Do something amusing, entertaining, inspiring, or compelling. Present your message if you must, but do not linger longer than the task requires. Your interruption will leave an emotional impact regardless - make sure it's positive and not one of frustration or anger.

Be forthcoming. Most advertising is trying to drum up business so that the advertiser can sell more widgets, or get more people to use their service. The bottom line is money. Most people understand that people need to make a living. They won't hold it against you if you make it clear that you're asking them to participate in a business transaction. It's not that complicated, really. I will give you X if you give me money. Don't try to hide the fact that you are asking to be paid.

My final guideline is to be accessible. We tend to accept advertisements that are intrusive but explain how the advertiser can meet our needs right now. While car ads at the movie theater may alienate moviegoers, ads suggesting that we all go to the lobby to get ourselves a treat are more acceptable. It's better to choose to advertise to consumers who are interested in your product or service now, than to those who have no need of it until the unforeseeable future.

I wish that I could say more on how to get it right. Frankly, it's not too difficult to find ads that avoid pissing people off. Inspiring them, on the other hand, is an incredible challenge. When everything comes together just right, a brief segment of airtime can transcend advertising and become its own cultural icon.

What Do You Think?

As I explained at the beginning of this post, monetizing my blog, given my current readership, would barely be worth my time. I'm pleased to find that the ads available to me from Google AdSense tend to be of the mild variety. They exist on the periphery of the blog and don't tend to interrupt the reader. They are even intended to be geared to the interests of the user and the contents of this blog.

Imagine with me, if you will, that you have a successful blog that could potentially rake in an additional $1000 every month. Would you enable ads? Would it be selling out? What would you be concerned about?

What are some things that advertisers do that cross the line for you? Let me know what you think in the comments.

Cheers,

Joshua Ganes

Backwards Compatibility II - Fixing Bugs

A Bug Report

Picture the following scenario:

You are in charge of maintenance for a system that has been deployed in production at many different locations for over a year. A new bug report comes in saying that one location is having difficulties with a specific request. This particular site has been running well for several months up to this point, but one new request has started causing issues. After a little investigation, you realize that the problem is due to a longstanding bug in your software that no one has encountered before. Your server application is sending an ampersand ('&') character that is getting misinterpreted by the client application. The client is simply incapable of handling this message and crashes every time.

What do you do?

Well, you can start by fixing the client application so that this is not an issue going forward for any new installations and for anybody who is capable of updating their application software. Sometimes, this is not good enough.

(By the way, why does software always go months without issue before receiving three bug reports in the same week?)

In certain circumstances the client application is outside of your control and may be impossible to update at all the sites for various reasons: the corporate policymakers have frozen the solution and will not sign off on any updates; the software is installed at a remote location and nobody has the necessary permissions or skills to perform an update; some hardware governing body requires a drawn-out review process for you to release your client application; or many other absurd reasons.

Now what do you do?

Fixing Your Own Bugs

The key to designing for backwards compatibility is to embrace the fact that you cannot change the past. Since you cannot change the software that already exists in the field, you need to update the software that you do control to compensate.

Before releasing your updated client application, add a new version indicator to the message format (if it doesn't exist already). Modify the server application to distinguish between the old client application (version 1) and the new client application (version 2). When the server is ready to send a version 1 response, it will replace any ampersands with a suitably-safe substitute. When it encounters a version 2 client, no substitution is required.

The following example C++ code snippet demonstrates this logic:

// Generate a new response object for the given request
Response* ServerApp::handleRequest( const Request& request ) {

    Response* response = new Response();

    ...

    string content = this->getResponseContent( request );

    // Remove ampersands for clients below version 2
    // See bug 19243
    if( request.getVersion() < 2 ) {

        content = this->replaceAmpersands( content );

    }

    response->setContent( content );

    ...

    return response;

}


This update allows the existing client applications to continue operating in a limited way (sans-ampersand) while allowing new clients to use the full features of the application.

Fixing Other People's Bugs

Not to spark a religious operating system debate, but I feel that I have to mention the fantastic efforts of Microsoft to maintain backwards compatibility when developing Windows 95. As described by Microsoft employee and blogger Raymond Chen, the Windows 95 development team went to great lengths to make sure old software still ran seamlessly on their new operating system. They knew that most businesses and even individual users have one or more deal-breaker application that must work when they agree to upgrade their software. If those essential applications failed, Windows 95 would not fly.

The engineers at Microsoft came up with a clever way to build backwards compatibility directly into Windows. They created Application Compatibility Shims - named, as I understand, after door shims used in construction. Just like a door shim allows for adjustments between the framing wall and the door frame, these software shims allow for adjustments between Windows and incompatible software applications. Microsoft wrote many custom shims to compensate for subtle and not-so-subtle bugs found when they tested old software running on their new operating system.

When Windows 95 finally launched, there were surprisingly few programs with serious compatibility issues. When issues were discovered, there was rarely a need to dig into the scary underbelly of the operating system. Instead, Microsoft could just configure an existing shim or whip up a new one to fix the bug. This design was so successful that very few people ever gave a second thought to upgrading Windows. This gave Microsoft market dominance of both the corporate and personal desktop - a position that other platforms are still struggling to pry away.

Something to Think About

As I explained earlier, the key to backwards compatibility is embracing the fact that you cannot always change what already exists. By cleverly designing new software to compensate for old mistakes, we can mitigate their issues and sometimes even pretend that the old mistakes never existed. All of this comes at a cost, but that's a topic that I will have to address in a future post.

Cheers,

Joshua Ganes


This post was the second part of a series on the topic of backwards compatibility. My next article on this topic: Backwards Compatibility III - Planning For The Future.

The Insta-Set Clock - Named For Its Worst Feature

My wife and I had a minor problem. It's one of those problems we acknowledged, but let linger for a long time. Whenever we were in the living room and wanted to know the time, we couldn't find a convenient clock. Sure, there is the clock on our PVR and a clock on my computer and clocks built right into our phones. Each of these required a small inconvenience as the time was not immediately visible and available. Several times we discussed how we needed to buy a new wall clock.

One evening a few months ago, we were in London Drugs and happened to pass by a shelf full of wall clocks. Since we were not in a hurry, we paused to browse through them. The most important criteria for choosing a clock, we decided, were aesthetics and volume. i.e. We wanted to make sure it looked good and that it was very quiet. Since all the clocks were turned off, we could only choose based on appearance. We decided that we would return the clock if it was too loud.

Based on its clean and easy-to-read style, we chose the Accu-Time Insta-Set Clock. Reading the packaging, we learned that it has another interesting feature we had not considered. The packaging explained that when you turn the clock on, it will automatically set itself to the correct time. It is also smart enough to automatically adjust itself for daylight savings time. All the more reason to give it a try, I thought.

By the time I got around to trying out our new purchase it was about 9:45pm. Being a stereotypical male, I dove right in without reading the instructions. I set the clock to a few minutes before the current time and was excited to see it set itself to the correct time automatically. The second hand started flying around the face and the minute hand progressed towards the correct minute - so far, so good. The only problem was that the flying hands didn't stop when they reached the correct time. Instead, they kept flying forward giving me the sensation that I was in some kind of time-travelling B-movie scene.

After trying and failing again, I finally conceded that I would have to read the instruction manual. The instruction manual informed me (among other details) that I would have to move the clock hands back to the midnight position and let the clock set itself from there. The only problem with this was that during the "Insta-Set" process, the second hand goes fully around the face about once every 5 seconds. This means that setting the clock at about 10:00pm requires it to go around 10 x 60 = 600 times. All told, setting the clock correctly for the first time took nearly an hour. This is a new definition of 'instant' that I was not previously aware of.

After our initial trouble getting the clock up and running, I am pleased to say that we are now very happy with it. It runs nearly silently and has kept accurate time for a few months. As of this morning (March 10, 2013) I am also pleased to report that it correctly adjusted itself for daylight savings time. I would recommend buying this great little clock to anyone. Just don't get it if you need a clock that actually sets itself instantly.

Cheers,

Joshua Ganes

Backwards Compatibility I - Presented In Color

Journey to the Past

Let's take a journey back in time - well before smart phones and buzzwords like "social media" (ugh). Before Nintendo (pick any version), before Atari 2600, and even before Pong. Turn back your mental clock to a time when people would listen to shows on the radio. It was in this period that owning a newfangled television set became something of a status symbol.

Television was a new phenomenon and a fascinating novelty. There were still many great enhancements left to discover. Nobody had yet figured out recorded video, instant replay, picture-in-picture, infomercials, reality TV, daytime talk shows, or re-runs. Perhaps most surprising of all was that viewers might like to see their shows in color instead of just black and white. Even while lacking all of these things that we take for granted today, television was clearly a hit. Consumers far and wide opened their wallets to buy one of these shiny entertainment machines.

How Televisions Work

Those readers who are familiar with how CRT televisions and monitors work will probably like to skip my simplified explanation in this section. Go ahead and we'll catch up with you in the next section. For those who are learning about this for the first time, pull up a comfortable chair and grab an icy-cold drink and read on. Readers who are truly in the know will find my description to be a slight oversimplification.

The earliest televisions used a technology called cathode ray tubes (CRT). This was the primary television technology for many years and you will still find them haunting the corners of basements, rec rooms, and man caves today. CRTs function very differently from the modern LCD, LED, plasma or other more exotic televisions available today.

In CRT screens, an electron gun fires a beam of electrons at the screen. A thin coating of phosphors are layered on the inside of the screen. When these phosphors are hit by the electrons, they glow for a brief time. A powerful electromagnet directs the stream of electrons in a zig-zag pattern across the screen and from top to bottom. The electron gun modulates the intensity of the beam from high to low. When the intensity is high, the phosphors on the screen will glow brightly (white). By reducing the intensity, the display can glow in shades of gray or even fade to black. A further, more detailed description is available here.

All of the above happens many times per second - 60 per second for North America and 50 per second for most of Europe. In order to determine how intense the electron beam should be, the television is tuned to a video signal. In original black-and-white televisions, this only indicated two things: 1. When to begin each pass. 2. The intensity of the electron beam at each moment. If your television is tuned in to a strong enough signal, this will result in a clear image on your screen.

The Trouble with Color

To those who skipped the previous section, welcome back. To those who chose to read on, I hope you learned something new.

Now, color was obviously a desirable feature. Inventors quickly began working toward this goal. Unfortunately, color added a whole new level of complication to the system. Achieving color television would require modifications to both the hardware used to display those colors and to the video signal that transmits them.

The very first commercial color broadcast used a newly-invented signal format. Televisions designed to receive these signals worked perfectly well with the new signal, but all of the old black-and-white sets already installed in viewers' living rooms were completely unable to view these broadcasts. Needless to say, this caused a serious chicken-and-egg problem. Consumers would need to buy new televisions to watch in color, but they couldn't watch black-and-white broadcasts. Broadcasters had to choose whether to broadcast each show in the sparsely-adopted color format, or in the well-established black-and-white format.

Backwards Compatibility

What if we could find a way that old black-and-white televisions could watch new color broadcasts (minus the color) while new color televisions could still receive old black-and-white transmissions? Broadcasters and consumers could stop worrying about the tired old question of black-and-white vs. color and move on to inventing and voting on singing competition shows respectively. As nice as it would be, surely this idea was just a naive pipe dream.

Amazingly enough, Georges Valensi found a clever way to make this dream a reality. He designed a new video signal that added additional information to the old format. The first part of the video signal indicated the overall light intensity (just like before). The second, additional, part of the video signal indicated the relative intensity of the red, green, and blue color components. This meant that the old black-and-white televisions could safely ignore the second part of the signal and still display a reasonable image. New color televisions were able to perform additional processing on the signal to fill in the corresponding colors.

This example of the color television signal format is just one of many thousands of examples of backwards compatibility. When implemented correctly, backwards compatibility allows old, existing systems to continue functioning while adding new, desirable features and capabilities to newly-designed systems. Sometimes protocols can be designed with future flexibility in mind. Other times, clever thinking is required to find a compatible new solution. In any case, backwards compatibility is a fabulous way to create something new without breaking a system that is already in use and working well.

Cheers,

Joshua Ganes

This post was an introduction to the topic of backwards compatibility. My next article on this topic: Backwards Compatibility II - Fixing Bugs.