Most unreasonable development assignment

Question

What's the most unreasonable (programming) task you've ever been given as a developer? I think everyone at some point get's a variation of a travelling salesman assignment, but is there worse? For instance, I was once asked as a contractor to make a system that would take in marketing data and use it to predict the outcome of any future marketing campaign X based on the performance of past marketing campaigns (I politely declined to pursue the project).

What's the worst you've gotten? How did it work out?

Answer 1

When I was at university (back in 2000), there was one particular course that involved writing an application for an "actual" customer. Our team consisted of 10 people.

We were asked to write a client/server application to access and maintain the entire MRI/CT scan database of a particular hospital, which was somewhere in the double digit terabyte range at the time. Of course, without any information on the actual tape robot hardware or specs on the online storage.

While we were at it, they asked us to communicate with the scanners themselves, using the DICOM (at the time) draft standard, which was about 3500 pages long. Without having any chance of testing that of course.

Here comes the kicker though: since all this would be far too easy for 10 fresh students that would be spending 160 hours each on this project, they asked us if we could make the client application diagnose fractures and tumors on scans without actually involving doctors. Without any medical knowledge on our side of course.

Needless to say, that didn't work out. We just focused on writing a C++ server application with a platform independent (that was a requirement) client app to view images and meta-data.

Answer 2

Every single one i have been paid to do.

Answer 3

I have been asked recently to provide a "progress bar" for the running of individual pieces of code (we have written a simple interpreter).

I had to explain why this might not be very easy.

Answer 4

As my first task at a company, convert a badly written piece of procedural code hundreds of files large over to a huge OOP bespoke framework without any documentation on either, in two days. Needless to say, they didn't get that.

Answer 5

Variations on "Let's solve the halting problem" seem to come up pretty often for myself and my colleagues. This commonly happens when some multi-threaded code is suffering from deadlocks or thread starvation, and some bright spark pipes up with "can't we write a lock manager that will prevent deadlocks?".

I personally have been assigned a number of testing tasks that are equivalents of exhaustive combinatoric analysis of, for example, 10^50 combinations of elements. I'm getting pretty good at explaining how that's simply not going to happen, and suggesting alternatives that might be nearly as good, but finish in my lifetime.

Answer 6

Worker performance tracking--the objective being to see if tweaks in the operations made things go better or worse. The problem was they wanted to see in a half-day if the change was good--but the data points generally came in only about every 45 minutes with a high degree of variability--the program had no concept of the difficulty of any given task, in most cases it's job was simply to tell the user what needed to be done and provide the reports or labels they would need to do it. A few stations actually provided item by item data to a machine that would do the actual processing but those were pretty much limited either by the feed rate or the mechanical limits of the machines, getting detailed reporting on them wouldn't tell you anything.

It took me hours to convince the boss that the task was inherently incapable of producing meaningful data.

Answer 7

Here is one that comes back to haunt my coworkers occasionally.

Due to a history of acquisitions and subsequent product discontinuations by my company, one day we were given the task to implement a custom data export for a large number of customers. We wanted to transition these customers from an acquired and discontinued product onto our main product. These customers need the custom data export to submit orders to some other third party company lets call it Company T who required this custom data format.

Despite our repeated attempts no one from Company T would give us a spec for their data format. No one from Company T would give us a testing account to test their order entry so we could at least, you know, test our eventual software. In fact I don't recall anyone from Company T even returning our calls.

There was no code from the discontinued product to look at. The only way to guess at the data format was to reverse engineer it from doing a hundreds of exports and trying to surmise patterns.

You can imagine how well this data export worked the day shipped it.

(It wouldn't be fair to end the story there. Company T now works more closely with us but we still don't have a spec. I don't think they even have a spec ...)

Answer 8

All the projects that weren't used by more than 5 people.

Answer 9

I am now supposed to fix our code base so that it can work without any reliance on Sybase. For fourteen years Sybase has been the backbone of the system, and Sybase is to remain the official data storage. Why the change? Because our DB has some problems, and sometimes can go down for 30 minutes or more. Why fix the DB if we can hack the code?

Answer 10

I was forced to implement an extremely convoluted API for reading an in-house file type that used struct instances (in C) but had all data backed by global variables (by design). If you tried to read from a file, or seek in the file, all buffers would change underneath you.

Oh, and I had already implemented solid support for the file type in both C++ and C# and was actively using it in the tool chain. If he wanted C, I could have just made it use that code by porting it...

Answer 11

Back in the early 1990's, I was assigned the task of debugging a piece of undocumented and poorly written real-time communications software written in C++ and running on DOS. (Yeah, I know, you couldn't really do real-time on DOS, but you could sort of fake it.) I'd already been working there a while, and my employer knew my skills, which did not include any C++ (beyond C, which I did know), or real-time development, and I didn't know DOS or communications software all that well. I was supposed to learn all this without any training or materials supplied by my employer. Oh, and there was no one else around who had any knowledge of the code. I didn't get it done (and later I heard no one else did either), and I was working elsewhere shortly thereafter.

Answer 12

My first job out of college was a programmer for a company that made multimedia CD-ROMs. They would travel around the country to industry conferences for various professions, record the presentations, and put the recordings and associated PowerPoints onto a CD-ROM.

My boss (the owner of the company) had a great idea that our software could have a "sync to PDA" button that you could just click and it would send the presentations and audio to your PDA for on-the-go listening.

Now, this doesn't seem so impossible, but at the time, MP3 players had just come out, iPods were brand new, not widely adapted, and still prohibitively expensive, and the iPhone was still years away.

He didn't understand that there is a wide variety of PDAs out there and there is no possible way we could get drivers and specs for them all so that we could just zap everything over to a PDA. Plus, even if we could have solved the software/hardware issue (we couldn't), most PDAs at the time maxed out at about 64 MB of memory. In other words, a whole week or weekend's worth of recorded speeches and PowerPoint slides would NEVER fit. We'd be lucky to get a couple minutes.

I told my boss this, and his response was "well, I need you to try anyway, since I already told the customer we could do it."

So I tried, and needless to say, I was unsuccessful.