Most Unpleasant Programming Task You've Had to Do

Question

What is the most unpleasant programming task you've ever had to do? This could be an assignment from a job, or a project or homework assignment for a class. Dimensions of unpleasantness can include annoying, boring, tedious, being uncreative, requiring no thought but lots of menial coding.

Answer 1

Trying to add functionality and debug code that is a mixture of php,sql,and html in the same file has been my worst experience thus far.

Answer 2

If I have an "annoying, boring, tedious, uncreative" task to do, I usually write a program to do it for me. Those kind of tasks are the kinds of things computers are best at doing! I don't believe programmers should ever have to do anything repetitive or tedious.

Answer 3

Actually, I can't recall off the top of my head any unpleasant programming task, except maybe having to go through all the administrivia in shipping a patch. It's sometimes hard to believe that you can fix and test the code in four hours, then spend three days going through all the source control, acceptance testing, validation, language translation and so on.

The hardest stuff I ever had to do was when I was managing projects. It's damn hard to fire someone for non-performance. Luckily (for me), I've moved back to a tech role.

Answer 4

Stepping into a project that's 95% done, full of bugs, no documentation or unit tests and the previous developer didn't have a clue what they were doing.

Answer 5

Debug Javascript without Visual Studio 2008...

Answer 6

Translating old and bad VBA code to C#, I didn't like it...

Answer 7

Cleaning all the buggy code my predecessor left behind when he was terminated. Some fifty VBScript apps that did basic menial tasks full of terrible recursive loops that never seemed to end, all without being able to port it over to something a bit more robust and more in my area of expertise, C#.

Answer 8

Coding a college project (simple board game) that would be done with Java or C# in hours in Haskell (recursion + no variables was nasty)...

Answer 9

Boring and tedious are fine with me. Bring them on; others don't want it so i can make the $$ doing the "boring and tedious" stuff.

No, the most unpleasant task i had was trying to figure out a big wad, or rather several big wads, of spaghetti code that was shoveled into a few poorly designed classes. This was a Windows app using C++/MFC. My job was to increase reliability, ease of use, make the error message more sensible, and add PPP dialing (this was a few years ago). It was successful, but took about a month to figure out the mess. Printed out source, used color pencils to mark out huge "if" and "else" blocks. Sheesh!

Made progress by refactoring little bits at a time, then took on particular features that wove through the whole mess. Never did clean up the whole thing, but enough to get the job done and move on to another project.

Answer 10

I once had to modify some code that talked to a serial port under DOS so that it would work with one particular client's (demonstrably broken) add-in serial port card. Their serial port would occasionally "lose" interrupts when characters came in.

The whole routine had to be re-written to use polling and busy waits. My suggestion that we just buy them a new card (would have cost less than $50, even at the time) was not received well.

Answer 11

Y2K fixes in a FoxPro for DOS application.

Answer 12

Getting a Java servlet to talk to a Lotus Domino database (really old version, this was back in like 2000).

There were a few ways of doing it:

• The native Java API. This wrapped the nasty C native API. It would cause the Domino server to crash every couple of hours - but it gets better. When it crashed, it would ALSO cause the J2EE server to crash. AND nothing would work until the OS was given a reboot (this was Windows NT 4).
• JDBC API. This basically didn't work.
• Java 1.0 level servlet engine built into Domino. This actually ended up being the easier. Do an HTTP call from the real servlet requesting data from Domino. Then serialize the results in domino into XML and send it back as a response. Real slow and nasty, but at least it worked, and didn't cause either server process to crash (much).

That and pretty much anything ever to do with Visual Basic.

Answer 13

I once had to write a neural network in Visual Basic 6 for a grade 12 assignment. Oh god, the horror...

Answer 14

Ex-manager: our web site stops working several times a day and we have to reboot the server to get it going again. Can you look into it?

(after some investigation)

Me: it breaks because database connections are not being closed. We need to fix the way the site accesses the database.

Ex-manager: create a windows service that reboots IIS every 4 hours.

I created the service and put in my 2 weeks notice the same day.

Answer 15

I once spent over a month working on an app to analyze sales and tips at a restaurant. It had to determine how to split the collected tips among all of the staff. The client's method for splitting tips was based of seniority, how many items from the check that a server had entered, and who was working during the check. Then the app had to put all of this into an elaborate Excel worksheet that did more calculations and had very specific formatting. It started off kind of interesting but testing all the special cases took forever! After the app was delivered I found out that they never used it. Apparently their sales rep didn't actually understand how they split tips and the calculations were wrong.

Answer 16

Stepping into an ongoing project for different customers where major changes where made to the single code base to try and satisfy one customers urges.
And after you ran code metrics the only one change you already made and considered as a quick hack came out as best written code.
You start bug tracking system and for every bug you squash 20 more are added, and you have to deliver new functionality as well.
There are no unit tests and no documentation. All this in the same project and you are the only technical person also running the support department.

Answer 17

Writing an automated tool to inject code drops into a proprietary, hand-rolled revision control system whose only front-end was a monstrous spaghetti MFC application.

It wasn't scriptable, and couldn't be easily extended for new features, and couldn't be separated out into libraries. I ended up spending a few weeks to reverse-engineer it (because, of course, it lacked formal documentation) and re-implemented its features in a library to use in my own tools.

Answer 18

Working on a college project where almost every single other person was too busy to help or when they showed up they were useless.
One of the few classes I didn't get an A in...

Answer 19

I think "unpleasant" is too harsh a label to put against these two projects, but in the mid 90s I was given the job of maintenance programmer for a large donations database app written in (drum roll) Summer '87 Clipper. Whoever it was who wrote the original app must have learned Clipper while writing the app because the code was a perverse mix of mature and childish code. The app was eventually replaced with an Access equivalent.

The second I'm still involved in: a friend is a chemist (in the Australian understanding of the word) and wrote all his dispensary, stock-control and cash-register software first of all in dBase III and then ported it to Clipper 5.3. I've been doing various amounts of maintenance programming for him for last three years. The amount of business logic is huge, and my friend's way of implementing it sometimes takes one's breath away (often doing in 100 lines what I can do in 10.) See my entry answering What are the things you do, in code, which you are obsessive about? for an example.

Answer 20

It was a buggy system that barely qualifies as a programming language--it was meant for use by non-programmers but any non-programmer (including their own trainer!) would have turned out a pretty bad mess with it.

All variables were global. Strings and strings to be parsed as numbers were it.

Flow control did not exist, period. (Note, however, that since the objective was limited processing of data, not a general purpose language, this lacking was somewhat tolerable.) Each object simply consisted of the lines needed to process it, although it could call for sub-objects. The sub-objects ran as separate tasks on a copy of whatever globals they wanted, return values did not exist, nor did parameters--in general a sub-object figured out what it was supposed to be doing by looking at the name of the object.

Note that while the language itself had no arrays you could use read-only lookups from the database. These were the accepted way of converting between text and numeric values if you needed any rounding. Version 2.2 added external programs capable of doing the conversion but they couldn't round things properly nor produce output with fractions (fractions were the desired output, not decimals. You would say 2 1/2, not 2.5.)

2.2 added a limited debugger that was full of bugs--it was supposed to give you a trace of what things looked like on each line but if you threw anything remotely complex at it much of the trace would be missing.

All identifiers were limited to 15 characters and that included the symbol saying to return them from a table lookup so the practical limit was 14. All uppercase, pure alphanumeric.

I saw nothing in the system that did not appear to be laid down in the 70's.

Answer 21

I had to debug a web service and I was unable to compile and run the code. I was pointed to the project and they said fix the problem it returns the error:

"instance of object not found"

go. Needless to say debugging by hand sucks. Before I was able to fix it they went ahead and dropped the project all together.

Answer 22

I've already talked about this job in this question, and seriously, it's worth following that link for part of my rant on the subject.

The client is an ASP for a niche banking product; they have a small number of clients, but those clients are pretty solidly locked in. As a result, they have enough money to pay for ongoing maintenance of the application, but not enough to rebuild it. So they limp along.

Some characteristics of the application:

• It's a "classic ASP" application, with VBScript ASP pages and a heavy home-grown JavaScript front-end library. They're just now updating their servers to Windows 2005.
• To a first approximation, all, and I mean all, of the application logic is in SQL Server stored procedures. Seriously. XML messages are formulated on the front-end, the middle tier figures out what SP they belong to and pass them along, and the SP does whatever it's going to do and emits the XML response that goes back to the client. I'm not making this up.
• There are many stored procedures that are 3-5,000 lines long.
• They were written by people whose ignorance of the most basic elements of SQL continues to astonish.
• There is no documentation of any kind, beyond the barest-bones "how to install this on a server" document.
• The original developers were fired back in 2000, six years before I arrived on the scene. And good thing, too. I would have had a thing or two to say to them.
• The subject-matter expert whose brainchild this whole application is, the guy with the banking/finance smarts, is, well, dead.
• The pay is lousy.

So I spend my time there fixing huge snarls of undocumented stored procedure code, figuring out what the procs do and rewriting them for efficiency, building the occasional middle-tier component when I can get away with it.

Even this job isn't a complete waste: I've learned a fair amount about SQL Server during my time there (and not all of it of the "don't ever do this" sort). The job came along at a time when I really, really needed one. The stress level is awfully low.

But man, fixing a 5,000-line stored procedure written by someone who didn't understand NULL? It's further evidence for Dostoevsky's observation that man is the animal who can get used to anything.

It's not the worst job I've ever had, though. That one is a story that I've told to many veterans of incompetent management and horrible pointless deathmarches, and there's not a single person I've told it to who has ever said "Oh, I can top that." But that story is too long for this venue; it would probably exceed 50-75,000 words to get it all. (And who wants to read a book-length essay about a failed software project?) It takes about 2 hours to tell in person, and it's gotten a lot harder to tell since I stopped drinking. Also, while I'm the hero of the story, I really don't come off looking all that good.

Answer 23

write some test two weeks before the delivery because the manager decided that we needed to show the client that our project has been thoroughly tested

Answer 24

Working on a Grad student's Transportation Network Simulator, which was written in Fortran and featured an enormous but undocumented COMMON block.

Answer 25

The most unpleasant programming task I have ever wrestled was removing in-line SQL statements from over 400 classic ASP pages, migrating them into stored procedures and views, with a DBA who sat on his butt and dragged his feet the entire way. I ended up doing the entire project myself. Only to find out that the project was the first step in becoming compliant to a larger business that would purchase the company I worked for, which ultimately put me out of my job. FML.