What are easter eggs, and where do they come from? And I'm not talking about the physical ones in springtime, I'm talking about hidden features or credits in software.
The other night a rather nice writer called, and asked me "Where do Easter Eggs come from?". Other than the obvious answer, "From programmers silly!", there is a long a rich history that has lead to what we know today as Easter Eggs. After I answered her, I decided that it really would make a good article -- so now I'll put my spin on things.
Don't worry, I'm not ripping off her idea too much -- she was more writing on the philosophy of programmers and the sociological aspects of why Eggs keep getting added. I'm going to go much broader than that.
How far back do they go?
I remember Easter Eggs from before they were called Easter Eggs -- and they existed way before that.
When I started programming it was not uncommon to do "backdoors" into programs. The idea was that you could walk up to a piece of code you had written and always get through security using your own secret hard-coded password. This was especially common with networking or multi-user systems that had passwords. Backdoors were not uncommon and many passwords were time or date based (or had a time component) so you could tell them to someone the password but they would only be able to get in for a limited amount of time.
Sometimes backdoors were heavily frowned upon (and a violation of company policies) since they were security holes -- and fact a common way to break into systems was to hunt for the backdoor (often code snooping). Sometimes backdoors were accepted and condoned. Imagine the user forgets his password and the whole system is locked out -- of course having a "back door" in was an absolute necessity to help the customer of your system save lots of time. Tech-Support needed them.
Backdoors also grew into "non-networked" apps, and apps that didn't have a password. For them, some unusual set of steps (and a password) would often bring up special test modes, dump more information to a file, or add special features. Usually these were used by field personal to do some debugging or to figure out what was going wrong (when there was a problem) -- or they were at least ways for the programmer to do something that others couldn't.
Backdoors became especially common for games. After all, if you were going to make a program for fun -- why shouldn't you have a little fun yourself? Entering a "God-Mode" was always an way to torment your friends. Besides, it was good for a programmer to just be able to set any value he wanted so that he could test things thoroughly -- but once done, it was easier to just hide it than remove it. So these "cheat modes" became common on their own.
In 1982 I was working for a company (MITS / Pertec), and was doing Q.A. (Quality Assurance). I wrote dozens of programs to "exorcise" the systems and find bugs with each build. Well, one of the programs I wrote (on off-time) was an electronic version of the dice game Yatzee. It turned out to be a big hit with the other QA People and the night-crew which did Data-Entry. It became even more popular when I made it play "network" mode so that people on multiple terminals could play against each other. There was one hot little "co-ed" working the night shift that I had caught my eye (and nearly pulled it out of my skull). But I only saw her on shift changes since I was working days. So I decided to add "high scores" -- and to do that you needed to enter your name (before you played). If the name was Colleen, then I had a whole little routine that said, "Hey baby, if you give me your phone number, I'll let you cheat". She could have more dice than normal, load the dice, change scores and do all sorts of things -- and it wrote her phone number to a file which I later called. This was the geek equivalent of roses and love-letters. And it turned out to be a very good idea as we dated for about 6 months -- and it was one of my more enjoyable experiences with an Easter Egg (Back Door).
Now backdoors and cheat modes were actually functional -- or at least they had a purpose in there somewhere. But they were still usually there "unofficially" and little "extras" added by programmers. Programmers see themselves as highly creative people (Code Artists) -- even when they jobs they do are terribly mundane. Often Big-Buisiness (or any business) is trying to be professional, and so stifles the creativity of their programmers -- since calling the customer "dolt", or having dancing menus is not what you want in an accounting program. So usually the business people in a company, is at odds with the programmers.
Of course actually, everyone is at odds with the programmers -- in many of their minds. Marketing is always putting in stupid features, since marketing doesn't have a clue about how to program computers (and what that feature means to the code). Sales are always promising ANYTHING if it will mean a sale -- so programmers would get requests like, "we need the special 'go back in time' feature implemented ASAP because we promised it to our customer". Management doesn't appreciate the programmers, and usually passes on the requests of marketing and sales (proving that they are stupid and in on the conspiracy). And so on. And of course businesses are always trying to operate like they don't really have programmers, since these back-room geeks will either come off like unwashed, well, uh, "Geeks" -- or worse, they will come out and tell a customer exactly what they are thinking (which may be that all users are idiots, that management is stupid, or them may sketch out on a whiteboard the next 5 generations of the product with all sorts of proprietary information that either bores people into slitting their wrists or gives away the farm -- or both). Of course management does do (or allow) really stupid things. I remember working at Rockwell, and having Q.C. (Quality Control) demand that when we submit our code, not only give them source code listings, but all object code listings as well. After arguing about the uselessness of that, we were told to shut-up and comply. When I left (3 1/2 years later), I mentioned to Q.C. and management that all my Object Listings had been printed in Septa-Decimal (base 17 -- on an octal based computer), and that if anyone had ever looked at the listings, just once in the last 3+ years, they should have noticed (the "G's" in the listings were a giveaway) -- I gave them the real stack (that was a couple feet of paper-wasting tree-mahem) on the way out.
So what do you do programmers do with all this stifled creativity -- surrounded by techno-cretins (besides ridicule them mercilessly behind their backs)? The answer is obvious -- slip things into the code that only they are aware of. The best technical pure features that are free from managerial controls which validates their technical superiority. This is best done when programmers have code-reviews and others breathing down their neck trying to find such things (it makes victory that much more sweet).
So Easter Eggs really nothing more than geeks "tagging" or marking their turf. The software equivalent of "Kilroy was here". Artists sign their paintings -- and programmers have unusual ways of doing the same.
Comments as tagging: Easter eggs are a common way of tagging, another annoying way is the programmers that tag every line of code they ever touch with their initials in comments. Do you have any idea how annoying it is to look through pages of code with some guys initials buried in comments all through it? After you find the third or fourth bug (with their initials), at least you know who to curse at -- and for some reason the people that initial their code that heavily also have a preponderance of bugs. Fortunately, other programmers usually figure out how to write simple programs to strip that guys initials from the code -- or I've seen one or two listings where they just added to the initials (unless the author really did go by name of "FLB -- the moron!").
Easter Eggs and backdoors are thumbing your nose at the establishment. The fact that the "establishment" is signing their checks doesn't seem to enter the programmers minds. What the programmers remember is all the super-cool features they added on their spare time that someone in management made them pull out. They remember stupid policies, countless boring meetings, and the challenge of slipping this in. They know that they will one day be gone from the company (maybe sooner if caught). But that also know that their "secret feature" may live on, and they will be able to walk up to the program, years from now, and prove to someone that "they wrote it", because they can pull up their name, their picture or some special sound.
Of course once the Egg is in a shipping product, it is time to let the world know of your brilliance (unless it is at a company where it will mean your job -- then you wait until you have left). But all too often eggs are found on their own.
Other Creative Expressions.
Programmers are always looking for ways to express their creativity.
I've seen very creative use of variables -- like most of Apple's sample code (and others) that used "Foo" and "Bar" as variable or procedure names. This is all from the military acronym FUBAR (Fu... Fouled-Up Beyond All Recognition). But there are often variable names like "Boss_is_a_Jerk", or "CluelessMarketingFeature", and so on. (Those work best in companies that don't have code-reviews -- but I've seen them at companies with them). I can't tell you how many cartoon characters, or various other "themes" I've been subjected to. Often there are variable names that are "secrets" that have to be explained (but mean something to someone). All are just little creative outlets.
Another way for programmers to express their creativity seems to be in the test data they use to exercise (or exorcise) their programs. I personally got bit by one of those once. I was doing a maintenance trainer for the B-1B Bomber, and had all sorts of test data. Like if you lifted up the landing gear (while doing maintenance), it would proudly proclaim, "Congratulations Corporal-Cretin, you just squashed your ground-crew". Or if you did the same thing wrong, three times in a row, it would announce, "Read the Manual you moron!". Of course it was just to test the test programs and not real information yet, and I was thoroughly enjoying testing my own sample data, until one day (when I was gone) the Air-Force had requested a "Status Update" and someone sent them my disk-pack (without my authorization). I learned what a limited sense of humor an Air-Force General can have, when one managed to both squash his ground-crew, and do the same thing wrong three times in a row! Temper, Temper! I felt real bad for the guy who sent out my test disks, for about 5 minutes -- then I learned that shit rolls down hill, and consultants are always in the valleys.
Easter Eggs are just one of the many ways that the oppressed geniuses (in their own minds at least) can rage against the machine, and make little digs at the system (or the individuals that sign their checks). The old, "you paid for me, but you don't own me". Most of these "eggs" are fun an harmless -- and the majority go unnoticed. Unfortunately they are becoming more and more known (as a concept) -- and so management must make more and more official policies for handling them. Many are even starting to enforce those policies. At this rate, it won't be long before all the individuality is crushed by the drones and unimaginative dictators -- but honestly, my money is on the self-righteous know-it-all programmers. Companies can't currently afford to lose their best employees over something so trivial, and many are wise enough to know that. So a few official slaps on the wrist, and life will go on. And so for a while at least, I expect to get an occasional chuckle over hidden surprises in various programs.