Why no Easter Eggs? (2005)
web.archive.org
web.archive.org
https://en.wikipedia.org/wiki/PRISM_(surveillance_program)
I'll take a flight simulator hidden in Excel over widespread, systematic violations of privacy any day thanks. Want to maintain trust from your customers? Don't spy on them.
Seems like there are a lot of other practices they do which are far more harmful to user trust.
It wasn't like this was an either/or situation... a manager wasn't deciding between prioritizing not participating in PRISM or not making an Easter egg.... in fact, I can almost guarantee this person wasn't involved in the PRISM decision.
However, that would seem to be based on an idea of valuing which is absolute, and which accepts no trade-offs. Conceivably they could value user trust (at least, instrumentally value it), but value what they would get out of doing [prism] more, per amount of lost user trust, then they value what they would get from [easter eggs] per amount of (somehow?) lost user trust.
(Words in square brackets are abbreviations for the activity relevant to the words in the square brackets)
Since they participated in PRISM-level trust violation, they can't improve trust at the level of guaranteeing no easter eggs.
It would be like cheating on a spouse and then building back trust by promising and delivering on a "no practical jokes" policy.
Well, it’s a start
They aren't being paid to implement Easter eggs. The job is to produce software that effectively helps users within bounds of the law. The government says they have to spy on their users, so it isn't like Microsoft can do otherwise.
Yes.
You must be trolling me.
The article as written is completely different than the article as written plus something like what I quoted from you pasted at the bottom.
The article is arguing that there is a proper engineering choice to be made (Do I include Easter Eggs? No, primarily because it is an unnecessary bug vector that erodes user trust). The root of this thread is an argument observation that users shouldn't trust the software anyway. Fair enough, that is certainly true.
But there isn't a choice for MS about whether they help with PRISM. The US government is going to force them to. In a framework of what decisions the developer makes there are no choices to be made - they have to implement PRISM.
It isn't reasonable to argue about something outside their sphere of influence when assessing what principles are good and bad. PRISM doesn't erode anyone's trust in the competence of Microsoft's engineering, it is just a general erosion of trust in American software. Nothing MS can do about it.
I'm arguing that the article should be seen as trust in engineering competence. Not trust in the abstract.
You can even make a point that anyone who ever worked for them has become significantly less trustworthy.
Yet here we are.
There are plenty of APIs intended only for Microsoft to use. There are significant features locked away by registry settings with zero documentation.
Windows itself even has entire APIs that were explicitly designed and intended for external that are effectively undocumented.
The real issue is easter eggs (or any code) that a developer snuck in without approval. Sadly, the post goes on to claim that even approved easter eggs should not be shipped (with the implication that them being undocumented is the problem), but that is absurd.
Better cease all development on Windows/Azure/Office for the next decade so that all the undocumented features can be properly documented.
I’m not against easter eggs though, you just have to be okay with the prospect of breaking expectations users may have in the future.
Uhhh, that seems perfectly sufficient to me. Play stupid games (like relying on undocumented APIs), win stupid prizes (like watching everything break when those APIs change). Private interfaces should be used as a last resort, and with the full understanding that - being private - they have no obligation to be "stable".
I'd imagine if the easter egg was a documented feature (eg, scoped by product managers, went through security review, etc) perhaps it would be fine.
I think the poster you replied to originally had this covered.
Developers still slip “undocumented features” into code all the time. I think it is ultimately a public relations and legal liability issue. If you add an undocumented feature, and you have a plausible argument as to how doing it serves the needs of the business (e.g “it dumps diagnostics useful in debugging customer issues”), it is much easier to defend yourself (and for your management to defend you) if that code later causes problems (whether security or performance or whatever) than if you embed a flight simulator. It is about the CYA of having a believable business purpose to what you did, which is helpful both in courts of law and the court of the media.
A lot of places nowadays you need at least one PR review from a peer to merge code. Still you can end up with a feature that only two or three people know exist (the author and the PR reviewers)
In my experience “undocumented features” often happen because the original specs don’t go into details about issues like diagnosability, etc, often because PM/design teams write the specs but only the implementing developers have a good idea of what useful diagnostics actually are. Maybe the developers should go back and update the spec but they very often don’t
Context is important here. As part of anti-trust deal, MS had to document all APIs and file formats, and there was a massive internal effort to do so. Basically it’s not allowed to call non-public APIs from one MS product to another. On top of that there was massive security push when entire Windows division stopped working on new version and concentrated on security of XP for many months.
After these traumas there was no way Easter eggs would survive.
Think of it more like "Ha ha, after it was QAed, I hacked a picture of my cat into the masks for the new Intel CPU; who knew it would mess up some capacitance and change some critical timing in the barrel-shifter? Oh well, the fix is easy, and all we have to do is send a new chip to everyone."
https://www.thinkwithgoogle.com/intl/en-gb/advertising-chann...
> Is this what MS developers do when they should be concentrating on security?
The presence or absence of an Easter egg is not an indicator of the time spent concentrating on security. Claiming the Easter egg can introduce bugs that impact security or erode customer confidence due to the presence of hidden features are legitimate concerns.
Why do I bring up the differentiation? Hyperbole attacks the credibility of the legitimate.
As for solving the Easter egg problem, the incentive would be diminished if credit was given where credit was due (e.g. a documented credits screen).
I don't know so much about that.
When I worked at Redgate the About boxes in all of our tools would, after about 30 seconds, fade from the product logo to a photo of the team that developed the product.
I always quite liked that - it added a personal touch to the software - but it certainly didn't stop the practice of Easter Eggs. Most were small but one of my colleagues did embed a complete version of the game Asteroids into one of our SQL tools. Doctoring the team photos also became increasingly popular for several years.
I haven't put an Easter Egg into an application in more than a decade (at the end of the day you have to know whether it's acceptable or not to your employer) - though there has been the odd somewhat on point symbol name - but I do think people get unduly bent out of shape about this stuff.
Lives depended on the sofware run by the Apollo Guidance Computer and yet it contains symbol names such as BURNBABY, POOH and (I think) POOHDOO. E.g., https://archive.softwareheritage.org/browse/content/sha1_git.... I think it's important that people experience some joy in their work, and put something of their personalities into it, because the overall effects are both higher engagement and higher quality.
Some will judge and say, "Well, if you had time to do $FRIVOLOUS_THING then you had time to do $MORE_SERIOUS_AND_WORTHWHILE_THING so why didn't you?" Maybe, but that's not really how many people work. These things aren't just vanity: they're often a sign that staff are putting some love into what they build.
But speaking in fun terms, probably the best fun I ever had with it was putting little "Waldo" images in levels I developed as part of a popular online shooter. It was my online nickname at the time, and it was a lot of safe entertainment, both for me and for the players.
Art is funny in that even it's most difficult to aesthetically appreciate forms are still, in fact, Art.
a) your software is used in critical operations involve real human lives or large amounts of money; AND
b) your company is developing a reputation for buggy and insecure products
Both applied to Microsoft in 2005! While the author is perhaps guilty of abstracting the concerns too much and avoiding MSFT-specific issues, I think it’s a fair point that Easter eggs are unprofessional and can blow up in management’s face for high-profile software.