Would You Add Easter Eggs To Software Produced At Work? 747
Mr. Leinad writes "Do you add Easter Eggs to the software that is produced at the office? I mean, if you have complete control over the final product, do you spice it up with that little personal touch, which, as unlikely as it is that anyone will see, carries with it an 'I was here' signature? I've just finished the development of a large software product, and I have a couple of days left to try to add my own personal Easter Egg code, but given that the software is quite professional, I don't know if I should. What do you think? Should we developers sign our creations?"
I would (Score:5, Insightful)
Of course! (Score:5, Insightful)
Shit happens (Score:5, Insightful)
Sure. But you had better be careful. (Score:5, Insightful)
If your "easter egg" causes bugs that end up costing the company money, your ass is grass.
God, no (Score:5, Insightful)
These make for great legends, but as much as I hate to admit it, I've gotten very serious about my work. Easter eggs are not generally appreciated by the Powers That Be, or by clients paying big cash for a product. My personal reputation, and producing a quality product have become important to me.
There's also the fact that that more code == more bugs. You can't get around that. Why open up a professional product and your reputation as a developer by making it more likely that you'll screw up?
I can see certain exceptions to this - for instance, games with easter eggs (approved, of course) can add to the charm of a product. An easter in egg in Quicken would be less cool.
Comments. (Score:4, Insightful)
Re:Professionally Signed (Score:5, Insightful)
Re:More for the Testers (Score:5, Insightful)
That's just good practice. You should put in a handful of bugs and see how many your QA department finds.
If you put in 10 and they find 8 of those plus 24 other bugs, then you can roughly estimate that there are about 30 bugs in the code that you have to fix.
Test your testers.
Ask yourself one thing. (Score:5, Insightful)
How are your going to be able to explain NOT fixing a bug that got through in your code when you had time to include an un-spec'ed Easter egg?
This isn't about charm. This is about having to explain to management why a customer is unhappy.
Re:Professionally Signed (Score:5, Insightful)
Speaking as a Software Engineer (I consider myself a professional); you are undermining the customer's trust in your product simply to massage your own ego. Customers are naturally concerned about integrity and security (more so today than ever before). Once you've demonstrated a desire to hide "secret features" in their products, they may start to wonder what other (perhaps malign functionality) is lurking in the code.
Thank you. I was starting to think that attitude was entirely missing from the Slashdot crowd. "Easter Eggs", bah. Programmers and engineers should make their mark in the world by designing and implementing quality products and not, as you say, massaging their obviously-inflated egos.
My Easter Eggs are comments and error messages. (Score:4, Insightful)
A humorous error message often brightens the day of the poor guy in operations who has to report back to the developer.
Re:Well.. (Score:3, Insightful)
Easter Eggs? No, funny comments/error messages, and bizarre variable names, absolutely.
I will never forget the day a student who was using my software for a project asked during a meeting what an 'out of cheese' error was. The poor kid was so confused :)
Nothing really tops the Amiga's "Guru Meditation Error".
No problem if it's small and unobtrusive. (Score:2, Insightful)
Re:Well.. (Score:2, Insightful)
No every product deserves one... (Score:3, Insightful)
but if you are proud of what you have achieved, go ahead, it is a human right. I did it a couple of times when it seemed appropriate, and it was never a problem. If you are in a position where you are responsible for creating the system, it is just your decision.
If you need a rational argument for doing it: It might make the team more proud of the product, more productive for future releases, projects or products. A company is about people, and it is a people issue.
And when even weapon designers can put easter eggs into missiles, I can't imagine anything to be too serious to pull it off; a product just may be too boring or suck too much to deserve an easter egg.
An easter egg is just a sign that the people who made the product did care about it, and are proud of it. An easter egg is like a medal or decoration for the product.
p.
Re:Ask yourself one thing. (Score:3, Insightful)
If your application broke because of an easter egg, you did everything wrong. If your application is buggy it should never be because of the egg, even if the egg itself is buggy.
Re:Ask yourself one thing. (Score:5, Insightful)
Ugh. I've seen this comment (more or less) all over this thread and I just have to say: Why are so many of you living with such FEAR of your management? It can't be healthy! Lighten up, people! How can you even work for your management if you can't even think of them as *humans* who might like a joke as much as the next guy? Geesh. </rant>
Re:Professionally Signed (Score:5, Insightful)
I am a robot. I do only as instructed. Beep beep. Bloop Bloop.
Be insulting if you wish. If you're a programmer or a software engineer, one day you may get involved with a project that has a serious penalty for failure (and no, I don't mean a bank or e-commerce Web site or something equally safe.) Believe me, when that happens you'll change your tune and get pretty damn serious. "Easter Eggs" and other irrelevancies suddenly become significant liabilities, and you don't even think about them anymore.
I'm happy when a customer notices that the software functions well, is easy to work with, and is solid. In other words, if get noticed it's because I did my job right, not because of some childish desire for attention.
Still, if you work on trivial applications it's okay to treat them like toys, I suppose. I don't, on either score. In any event, I agree with Burnhard. It boils down to whether you want to satisfy some psychological need, or want to earn the trust of both your employer and your customers. The latter is usually more satisfying.
You decide.
You should already know (Score:2, Insightful)
Pass for now, and perhaps look for more fun projects in the future.
Re:Ask yourself one thing. (Score:3, Insightful)
Re:Of course! (Score:1, Insightful)
Of course, not! Go and have some quality time with your family or friends instead. Empty your head. Come back to the office and compare the customer requirements to your implementation.
Re:No. (Score:2, Insightful)
Re:Well, yes (Score:5, Insightful)
Authority is never worth respecting merely because it's authority.
Yes, but keep it simple! (Score:5, Insightful)
I was working on a Web App that has date fields. There is an example of how to format the date next to it and I put my wedding day. The spec did not call for any certain date. I can look at it years from now and see where I left my mark.
I do not get any more adventurous then that. Once were were going to make a database table called WEGAS, which stood for Who Else Gives A Shit, it was a list of people who wanted to be notified when the issue/ticket was updated. We chickened out and called it Notification.
Also if you have a small shop, then it is fun, but in a larger shop it is usually frowned upon. then you also may have to explain it in a code review. So just stay light like I do.
Once I wrote in the document about paging I put "Example page 7 of 9". to me this is an Easter egg. I could have but page 3 or 10, but that means nothing, and 7 of 9 works just as well.
Re:Well.. (Score:3, Insightful)
Wrong approach, hand him a Terry Pratchett book and tell him to look for the answer, his life will be better.
Re:Well, yes (Score:5, Insightful)
Uhm, RAID 10 on databases has for a very long time been the defacto way of doing things (mirror and stripe everything). And your comment below about it being a raid 5 raided over 5 makes little sense - to me it seems like you have no idea what you are talking about.
Granted these days you would most likely opt for RAID 60 if you got the money for it, but RAID 10 is still the best price/performance for databases.
Re:Ask yourself one thing. (Score:5, Insightful)
could end up costing your ability to supply roof and food.
in theory. Even if he got fired, he'd almost certainly find a new, and probably better job.
However the effects of stress are real and demonstrated. Humans tend to overly guard their immediate downside risk at the cost of the long-term downside risk.
Re:Professionally Signed (Score:4, Insightful)
Re:No. (Score:3, Insightful)
You are just upset because you know in your heart that he is correct.
Re:I would (Score:2, Insightful)
Link or it didn't happen.
(And no, I'm not implying that links are a sufficient condition for truth, just a necessary condition of truth)
Re:Professionally Signed (Score:5, Insightful)
But that's not the choice you're being given. I'd say a better analogy is choosing between a doctor who gives you an EEG with regular white pads and a doctor who gives you an EEG with pads that are colored like nipples (or polka-dots at a family doctor). You're getting the same quality of work (or at least the quality is unaffected by this particular variable) with only slight change in aesthetic.
I'm not disagreeing with your main point about software integrity, but your analogy struck me as disingenuous.
Re:Ask yourself one thing. (Score:5, Insightful)
Both of which can be had with a walmart job. So your excuse has no merit.
Quit treating your management like they are your lord and king and treat them like the people that should be thankful you are working for them.
Cripes. Grow a pair.
Re:More for the Testers (Score:3, Insightful)
Re:Well, yes (Score:3, Insightful)
You bet. Anyone who's working in this industry also knows that some programmers think they're God's gift and know more the the entirety of the rest of the organization.
I care about keeping the business running.
Kinda contradictory.
Re:I would (Score:3, Insightful)
The inspection process may have found it but just considered it an innocent footnote/program info page.
Surely there isn't something malicious about having a buried feature to display some info about the software's developer(s)?
Re:My Easter Eggs are comments and error messages. (Score:3, Insightful)
The reason people post these statistics is they're true and they're useful. If we're starting a project, and I've got a rough idea how many lines of code or how many hours it'll take to implement, how do I work out how much time to allocate to defect fixing? If it's a new team, and a new technology, and I don't have any historical figures to go on, all I've got is industry average figures and some careful weighting. It's either that or gut feel, and most people's gut feel is terrible.
The links you posted refer to lines of code per unit of functionality, not defects per line of code. The defect rate of a language is not the inverse of its expressive power. That's because the majority of programmer-introduced defects are from one of three sources:
These are all independent of what language you're using, and they're all just functions of time (see below). That's why defects/KLOC or defects/hr are useful metrics.
Yes, of course the language you choose affects your productivity, and probably your defect rate too; consider that the move away from C++ to Java and C# probably eliminated 80% of the memory leak defects at a stroke. Of course, that still leaves the unchecked null reference defects...grrr.
I would, however sound a note of caution about that study. It's not at all clear that their productivity measure includes defect-fixing time. Remember, code's not done until it's done and working. Over the years, I've come to believe that in the hands of a talented programmer, dynamically typed, dynamically structured, interpreted languages can be orders of magnitude more productive. The only problem is, there aren't that many programmers of that caliber. Most programmers need all the help that the compiler can give them.
When I say they're all functions of time, consider:
Re:Ask yourself one thing. (Score:2, Insightful)
The best way is to have written solid code with no bugs or very very few bugs.
Perhaps you included the easter egg as a "hook" to test other code.. I.E. Your easter egg hooks an API procedure, allowing you to more easily test a specific portion of it or troubleshoot any problem that might arise, than otherwise.
The easter egg might display some general info about the application primarily of interest to developers or support people, hence the reason it is hidden.
Re:Well, yes (Score:3, Insightful)
If you had said "most of the time", I would agree. But I cannot accept that it is always in my best interest.
Re:Of course! (Score:2, Insightful)
Re:Ask yourself one thing. (Score:2, Insightful)
Even if he got fired, he'd almost certainly find a new, and probably better job.
Maybe. When I hiring software engineers at Razorfish San Francisco, we interviewed http://en.wikipedia.org/wiki/Jacques_Servin [wikipedia.org] around 1998 I think. Google was fairly new to me, and I checked his name. We did not hire him.
No doubt he found a much better job.
Re:Well.. (Score:3, Insightful)
Yeah, but as a former elementary school computer lab volunteer, please, do not code error dialogs like, "out of fucking memory" or "something fucked up" in your otherwise kid-friendly game. I can guarantee, no matter how unlikely you think the error is, it WILL come up in a classroom setting.
Re:I would (Score:4, Insightful)
what's offensive is very subjective. and as history has shown, people can get offended by just about anything. the SimCopter easter egg [jokewallpaper.com] sounds like it was meant to be more humorous than offensive. but i guess some people are offended by the sight of homosexuals, or perhaps just think that video games should not acknowledge the existence of homosexuality (after all, it might turn our children gay!).
for those interested, the guy responsible [afterelton.com] for the SimCopter easter egg is now a member of the culture jamming activist group, the yes men [theyesmen.org]. but be warned, if you're offended by the sight of pixelated men in kissing in a video game, you might want not want to click on that link.
Re:Ask yourself one thing. (Score:4, Insightful)
Then you're a slave.
You set the conditions of your employment, your employment does not set conditions on you.
Re:No. (Score:3, Insightful)
*WRONG* You guys are the reasons why software sucks in general, the damned cowboy attitudes. Professional developers leave the need to "leave their mark" at home. You're not a fucking dog needing to pee on a tree to show "your mark".
Re:I would (Score:3, Insightful)
Easter Eggs are unprofessional (Score:5, Insightful)
An easter egg is: a) extra code that could introduce a new bug (accidents happen, even in easter eggs - I've seen a screwed up easter egg crash a program and leave the machine locked up)
b) something that is not part of requirements and if caught during client code reviews or after installation, would put your employer in a complicated position since your spending time on such an unallocated task could basically be considered a form of fraud if the client is paying for your services
c) a sign of vanity - professionals do the job, do it well, and move on, not write silly-ass amateur crap just to amuse themselves and stroke their egos
d) something some other poor software engineer might have to fix or remove and they might not find so darn funny
A professional should take satisfaction in a job done well.
Do civil or mechanical engineers leave easter eggs? Do nurses? Do doctors? Grow the hell up... people bitch about software folks never being given the same respect as other engineering fields and it is the attitude of the average programmer that has a sizable part in explaining this.
Would you want your doctor leaving an easter egg? Would you want your dentist? Or would you find it funny if your phone dialed random numbers on some developers birthday? Or if your traffic light flashed all green every summer solstice? I think not.
I suspect the gulf here between those respondents who manage programmers and deal with clients or who work in any form of mission critical software or professional services and those who write shrink-wrapped software or less critical applications when it comes to easter eggs is probably sizable. All it takes is seeing a co-worker having his ass kicked because a manager had his chewed off by an angry client to understand that, in professional environments, this kind of stuff doesn't fly (and shouldn't).
You're not paid to be an artist. If you were, they'd cut one copy of your code and display it up in a museum. You're paid to implement requirements as defined by your employer and possibly your customer. When you aren't doing that, you're basically screwing the pooch and exploiting your employer. Some may feel justified doing this, but that's a crock. If you don't like the job, GTFO. If you do like the job, be a professional and leave the high-school hijinks behind.
(And yes, I've worked for 15 years in mission critical software for the police, the military, air navigation training systems, cell phone portals, VOIP and call processors, HR systems, and so on, so it does colour my view on easter eggs...)
Other Engineers leave Easter Eggs of sorts as well (Score:5, Insightful)
Although I agree with the general gist of your post (not the tone mind you) this need to leave something personal in a major work is not a new thing.
Workers in cathedrals of all times always took a bit of time to leave personal marks, from signatures to most complex features (faces, figures, etc) to sign a piece of work well done.
Electronics Engineers nowadays make minuscule engravings in the circuits they design.
Civil Engineers and Architects very often leave an small sculpture, signature, aesthetic feature that is not in the specifications but that adds a final personal touch.
I can't imagine that a client paying for a service that is delivered in time and budget would object in the terms you are putting to a silly joke, but I tend to agree that in the case of software, unlike an added feature to a bridge or a building, a joke can always bring a system to its knees (even if it is coded carefully and cleanly, software is exponentially complex, so it is almost impossible to foresee all the possible conditions under which an Easter Egg could cause havoc).
Oh for bunnies sakes. (Score:3, Insightful)
In civilized countries only junkies and alcoholics don't eat or have a roof over their heads (if the US is civilized is open to discussion, they don't even have socialized health care).
If you live in Somalia, Ethiopia or Sudan then yeah, your are fucked if you lose your job, but an British, German or Japanese person worrying about going hungry or homeless is frankly ridiculous, I don't know about the US, but I did not see any shanty towns the few times I was there (although it seems some are goring outside some towns in Texas....)
Re:Ask yourself one thing. (Score:3, Insightful)
Sadly, I think point (b) is a significant cause of point (a) in the first place. :/
Re:I would (Score:2, Insightful)
So I had to look up "culture jamming" and it appears to be justifying being an asshole by being arrogant. Is that about right?
Re:I would (Score:5, Insightful)
Surely there isn't something malicious about having a buried feature to display some info about the software's developer(s)?
No, but it raises the question: what else is buried in there?
In fact, if I were trying to bury something malicious in code, I might consider hiding it in a seemingly harmless easter egg.
Re: A WORK FOR HIRE (Score:3, Insightful)
Re:More for the Testers (Score:1, Insightful)
Newsflash - QA don't exist to find your bugs.
They already have more possible tests to run than they can actually run in the time allocated. The QA role is one of risk management - test planning is used to select tests that assess and eliminate as much risk as possible in that time. That selection is based both on experience and assumptions. One of those assumptions is that the developers aren't being jackasses. Believe it or not, but a lot of QA comes down to trust. If QA ran a full performance test suite and code audit against revision X of your code and found no performance problems, but on the other hand found a bunch of functional bugs, then when you are developing revision Y, QA are likely to prioritize functional testing not performance testing. The regression test suite may include some performance testing, but basically QA will make the assumption that this code is unlikely to contain performance issues and plan testing accordingly. By deliberately introducing bugs you are screwing with those assumptions - and those bugs may not be tested because of those same assumptions.
Your statistical analysis is also flawed.
1) Since you don't get to determine which test suites are being run, you don't know which of your bugs the test suites couldn't have caught. You cannot use the percentage of found deliberate bugs to extrapolate anything.
2) Even if you had intimate knowledge of the test suites and test plan and introduced bugs accordingly, it would only tell you that 2 of the test cases either weren't run, were run incorrectly, or had results misinterpreted. It would tell you nothing about how completely or accurately the other test cases were executed, nor how completely the test suites covered the code. You'd still be wrong to extrapolate.
3) Even if you _could_ extrapolate this number, you'd still be wrong. So, you've estimated 30 bugs. What are you going to do with that number? Hunt down 30 bugs, fix them and declare the product bug-free? Wrong. There's always more bugs.
4) Assuming for a minute that you live in a parallel universe where there aren't more bugs. Now you've got to find them. Finding the first 10 might be fairly easy, but after you've run every test scenario and test suite related to this code, and implemented and run every unit test possible, and delayed the release by several weeks (if not months) you still will not have found all 30.
5) Assume for a minute the impossible has happened. You found them all. You won't fix them all. Each will be triaged and the risk of fixing it versus the risk of not fixing it assessed. The risk of fixing it now versus the risk of fixing it later, etc. Most of them won't get fixed now (that's why everyone has a long bug list). You have no way of predicting what ratio will get fixed.
6) Even if everything else that I've said so far is completely wrong, you are still wrong. You have 40 bugs to fix, or were you planning to leave the deliberate bugs in the released product?.
Since you seem to have plenty of time on your hands, perhaps you could use it to a more productive effect by (a) spending it on design, code review, documentation, unit test development etc, ie one of those things that often get neglected but are actually useful in developing good software, (b) giving the code to QA earlier, (c) squashing another bug from the ever-present bug list, or (d) if you're really so fantastic that you've already done all of that, maybe you could help one of the more junior developers become a better coder.
Just about the only thing that you shouldn't be doing is adding non-required unspecified code (easter eggs) or deliberately introducing bugs that will later need to be fixed (if you remember). The only effect of both of those behaviors is to add unnecessary risk. Let me repeat that in case it didn't sink in the first time.
The only effect of both of those behaviors is to add unnecessary risk.
Grow up. Be professional. Start treating your QA folk with courtesy and respect. They are not 'testers' and do not need to be 'kept honest' nor tested. They need to be able to trust you so that they can help you produce quality software.
Re:I would (Score:3, Insightful)
Yes, but you generally don't remove something known to be innocuous just because you suspect there is something buried deeper.
You keep looking into the code, or ask the developer.
Removing stuff that you don't know isn't a good solution, it might break the code too.
If you don't trust your programmer, better you write your own code.