Slashdot Mirror
Would You Add Easter Eggs To Software Produced At Work?
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?"
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.
Here's one of those legends where a well-executed easter egg of sorts served to corroborate one's professional reputation:
My old boss spent some time writing statistical analysis packages for the Archimedes. One of them got fairly popular for Archie software, and he started a small business selling it. For those who don't know, Archie software usually came as source code and was executed through an interpreter.
One day at a scientific meeting, he noticed that another company was showing Archie software with remarkably similar functionality to his own, so he wandered over. The longer he watched, the more familiar it looked. Eventually, when the sales representative had gathered a good crowd, he asked in a loud voice:
The screen displayed my boss' copyright notice. All they'd done was remove the front end.
It widely accepted as the biggest laugh of the show.
Why are you assuming the question is in regards to a website? The text mentions the project as a "large software product". There's not even an implication that this is product a website.
Time to broaden your horizons methinks.
The
[ ] You know what Raid 10 is
[X] Your original post was talking out of your ass
HI O WISE PRINCE. WHT TOOK U SO DAM LONG?
It's called a roof, it stops rain from falling on your loved ones.
It's called food, it stops hunger.
Having a job and being secure in said job helps with this. Pushing easter eggs into the code when you should have fixed #00314224 Critical could end up costing your ability to supply roof and food.
So, you compromised the security of a piece of software to put your name in it?
If that pix was part of the "security" design then it's NOT an Easter Egg. We're talking about adding something NOT part of the requirements - NOT a good idea, and never is. If it not part of the requirements, it never gets into the test plan, and is never evaluated. Two people died from radiation burns in a Texas hospital cancer treatment center during the early 1990's because engineers added an undocumented shortcut so they could simplify their personal unit tests. (Therac-25 Radiation Deaths linked to AECL Computer Errors So no Easter Eggs from me (unless it's a requirement).
Never be afraid to try something new, remember ametures built the arc, professionals built the Titanic.
That's only because its Java, had it been an executable such a game could take up 10K or less incl graphics
from 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
to 45 2F 6E 40 3C DF 10 71 4E 41 DF AA 25 7D 31 3F
http://www.folklore.org/StoryView.py?story=Stolen_From_Apple.txt
My take would be the bogus waste of time for the testers. Each known, introduced bug consumes resources that would go to actual testing.
But if that actual testing is insufficient in the first place, those resources wouldn't make any difference in the end. By consuming a comparatively trivial amount of resources, you gain either assurance that the program really is stable or improved stability from issuing additional directions to the testers based on what wasn't found.
Add to that, it's not the programmer's responsibility to test QA, it's theirs to test him/her and if they find a shit load of bugs, he/her might start seeking employment for being a crappy programmer.
Of course, this isn't the sort of decision a single programmer on a team ought to be making (unless in the sense of suggesting it to the development manager and getting it officially approved). And nobody's talking about adding a "shit load" of bugs.
And I sincerely doubt anyone will believe or be humored by the revelation they were purposefully introduced.
That's why you clear things beforehand.
Why shouldn't I top post?
878659 - yep its prime.
Turn in your geek card!
Try this (run it a few times; the output should be different each time):
(Apologies for the rather messy use of grep and sed.)
That only works if you assume all bugs are equally likely to be found. Clever idea though.
Give me Classic Slashdot or give me death!
Bebugging math isn't that simple, according to the studies. Bugs you add on purpose do not necessarily have any representative similarity of findability to bugs that nobody knows about yet. This is by definition true unless you have specific knowledge about things you don't yet know.
Further, I have always found bug counts to be only partially useful. Plenty of us have seen one bug that we gladly would have traded for a hundred other bugs of the garden variety.