See title, but I am asking from a technical perspective, not
Take my 40 year old virgin niece on a date or you're fired.
To market Neal Stephenson's sci-fi thriller Snow Crash, I was asked to write a "benign" computer virus. It would "benignly" pretend to take over the user's computer and replace the screen with snow, a.k.a., a "snow crash." After a minute or so of snow, the snow would fade out and be replaced by an advertisement for the book. This would be "benign," you see. The virus would spread through normal means, but nobody would mind because after taking over their computer "you'd just get a fun ad and then be relieved that nothing bad happened to your computer."
I was actually told to do this at a major worldwide corporation. I had to write a memo explaining all the laws this would break and all 17 bad things that could happen if they really made me implement this.
My brother and I were working on a multimedia heavy-website for a very famous rock star many years ago.
When the client saw the site he noticed some compression artifacts on some of the JPEGs and asked what was wrong with them. We explained that images need compression for bandwidth purposes and that the images were currently compressed at about 80% quality. He was offended and said something to the effect of
I haven't gotten to where I am today by doing things at 80%, set it to 100%.
We tried to explain how it would affect users, but he would have none of it. It resulted in the slowest "virtual world" website ever. This actually happened.
Obviously after reading some business magazine on an airplane about how XML was the hot new technology (this was circa 2002), one of our executives asked me if our application used XML, when I said no he asked me if we could add it.
Now, I'm not talking about a feature to import/export files in XML format, he simply wanted it to be part of the architecture for no reason other than it was popular at the moment and would lend credibility to our app.
About 7 years ago I worked at a bespoke software shop that decided to sell one of its products. It was an end-to-end operations suite for some industry. Well, this industry wasn't known for being super technological, so somehow we ended up providing third-party technical support for their servers and IT infrastructure instead of farming it out to independent small business IT consultants.
One day, a customer's server encountered disk corruption. The server we had sold them was configured with an Adaptec RAID controller, set up for a RAID 1 mirror. Their application database was toast. They hadn't performed backups in months. The backups they had performed were unusable. They ended up losing 8 months of data. They hired an IT consultant to handle this investigative work.
Phone calls ensued, and the sales manager (known for promising impossible features) apparently told them it would be taken care of, and wrote it up in a contract.
The sales manager promised the customer that we would ensure that the application database and any other application-related files would never be replicated by RAID controllers if the files were considered to be corrupt. No configuration should be necessary either. Yep. We were told to deliver this functionality in 2 weeks, or the customer would fire us.
So the program manager -- who had some large enterprise CRM products, and other serious development successes, under his belt -- and I had a meeting with the COO, and the sales manager. The program manager was detailing how insane, impossible, and insanely impossible this was. The sales manager (military background) would simply scream in his face (literally!), "I don't care! How hard can it be to make the RAID thing not RAID?! Their data would be fine on the other drive if the RAID thing hadn't screwed it up!"
At the end of that meeting, the program manager quit with a zero-day notice. So I was now tasked with this. Over the next week, I petitioned both Adaptec and LSI Logic to provide an engineer for a conference call, simply to laugh in the face of the sales manager.
Ultimately, they obliged, and held up their end of the bargain. And they went into detail how ridiculously unfeasible it was. The guy from LSI was particularly harsh - he didn't sugar coat anything.
I didn't have to implement the feature. One I did have to implement was a custom security scheme requested by a customer, that would allow them to toggle any of the application's controls - on a control by control basis - as visible, disabled, enabled, read-only, or read-write. In theory, there were 146,000 combinations. And if you accidentally screwed up by say... disabling a control group, you'd have inadvertent side effects. Needless to say, when I was given the ultimatum that it had to be implemented, I also quit with a zero-day notice.
I once had a client specification that literally called for code capable of traveling backwards in time.
My employer harvested data for the client, and we were to deliver it in file format X at ten-minute intervals between 9 AM and 5 PM, save for the final delivery, which was in format Y (just X with a different footer). I did just that ... and they freaked. We were collecting low-volume data, and really only had one or two data points to deliver on any given day.
"QUIT SPAMMING US WITH EMPTY FILES!!!" they cried. "FIVE K'S EVERY TEN MINUTES ENCLOGULATES OUR BANDTUBES!"
Okay. So, my code checked every ten minutes, and only delivered if there was anything to deliver. Fair enough.
"BUT THE LAST FILE MUST BE IN FORMAT Y!!!" they screamed. "MODERN TECHNOLOGY CONFUSES AND ANGERS US! FIX IT OR WE WILL BEAT YOU WITH A MASTODON FEMUR!*"
(* -- It is possible I'm misremembering portions of the conversation.)
"So, I'm only to deliver the file if there's fresh data to deliver."
"And the final delivery for the day is supposed to be a different file format."
"Except I have no way of knowing which file will be the last of the day until the end of the day."
"So the only way for me to implement this is to write code that goes backwards in time at the end of the day to redo the format on what turned out to be the final delivery."
"COULD YOU HAVE IT REPORT SPORTS SCORES? WE SAW BACK TO THE FUTURE II. BIFF TANNEN MAKES US HAPPY."
I refused, in part because violating causality is an unethical programming practice, in part because CPAN.org didn't have a module that would let me do it. (I checked.) In the end, they allowed me to send a file in format Y at the end of the day, regardless of whether or not it had any actual data. I'm pretty sure their bandwidth survived the hit.
Without any discernable cause, I was brought into a private meeting, and told not to check if my computer was being monitored - including, never ever checking my task manager for any reason. I asked if they were monitoring my computer, and was told (roughly) "this is just a preventative thing -- you know, our lawyer told us to tell the employees about this -- but you know, we can't really say -- but I'm not monitoring it now."
(nudge, I think they were monitoring my computer, just not while they were telling me not to look for any monitoring programs. In fact, a few weeks later, I came in early and literally watched the mouse moving around my screen as if by remote -- so I looked through the window of the CEO and saw him remotely clicking around on my computer from his laptop.)
I once had a long "discussion" with a pointy-haired boss who insisted that we could store a 2 in a bit datatype because it was "only one digit."
The stupidest thing I've been asked to do is probably a ground up rewrite of a very large project. It was about 350k lines, all C (with a little perl mixed in for 'helper' scripts) and worked well no matter what clients did to it.
Almost a year later, we had:
Basically, we accomplished nothing that sensible refactoring could not have accomplished. But my boss was happy, we got rid of the helper scripts.
I consider it to be the most egregious waste of time and existing code that I've ever seen.
Client: We've been using your database software for a couple of years, developing our own applications with it, and calling you from time to time for help.
Me: Yes, we appreciate doing business with you.
Client: Yeah. Every time we call, you tell us how to use a new feature, or you help us debug our usage, or provide a workaround for some issue.
Me: Sure, we're always happy to be of assistance.
Client: Occasionally, your product has an actual bug in it, and your company fixes it and gives us a software update.
Me: We do our best.
Client: Well, what we need from you now is some assurance that we won't have any more issues.
Me: . . .
Write programs in C++
One major feature of an application our company developed was the ability to search large amounts of documents by the full-text of the document. A competitor made the following claim in a marketing presentation to one of our clients,
Our search technology is superior because it doesn't just search the text of the documents, it also searches the 'bits and bytes' of the actual file in binary form.
They gave a ridiculous example of how the decimal ascii repersentations of the words "boot" and "boat" were much less similar than the same words in binary form, when you compared the actual numeric digits in the representation. So searching based on the 1's and 0's more accurately reflected how similar those two words appeared visually, and thus improved recall.
Naturally I was tasked with researching this technique, which I assume was the result of a marketing guy completely misunderstanding a programmer somewhere, and drafting a response that we could include in our proposal.
Small team of programmers, boss wants us to do a ticket reservation system for a small airline (in a very short timeframe, of course). Team says:
-- as you can imagine, we will need some testers for this project
-- don't worry, learn from the car industry. They recall cars from time to time: users will do the testing.
I was a part of a mainframe support team that did shifts with other support teams in a data center. After the shift we would usually have a briefing with managers and the team of the next shift. One day our new director showed up and asked the question: "Why average CPU load during your shift was only 72%, while previous shift shows near 95%? I think if we try real hard, we could eventually achieve 100% CPU load!"
About 12 years ago when I was in college I worked on a data modelling application for Windows. The project was nearly complete after about 60,000 lines of Win32 code, you know, code targeting the Windows platform. Then the client said the application also needs to run "on the web". She had a hard time understanding how this one "minor little" requirements change could have such a big impact on the project. I started over from scratch in Java but ended up quiting the project before it was ever finished.
I was working on a big project in 1996 where we were scoring live sporting events. This conversation happened:
Boss: Go out to the venue for the next event.
Me: What do you need me to do.
Boss: Be there just in case.
Me: Just in case what?
Boss: In case the tech lead loses it. He's way too stressed out and I don't know what he might do.
Me: And if he loses it, what do you want me to do?
Boss: Just get him out of there so everyone else can continue working. I don't care how you do it.