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.

+2  A: 

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.

Mark Lubin
one of the main reasons I hate php!
hasen j
+2  A: 

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.

Neither do I, yet there are instances where writing the program to do it for you is itself annoying, boring, and tedious - can you think of any you've experienced?
Really? Why should programmers be any different to the rest of the population? :-)
I meant they shouldn't have to do repetitive or tedious *computer* tasks, since we only have to tell the computer how to do something once, then it can do it many times for us...
Exactly! I have the same philosophy. If a programmer complains that something is boring, he hasn't thought deep enough about the problem.
If writing that program is too hard, write a program to write it for you. If writing *that* program is too hard, learn Lisp.
+5  A: 

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.

Fire someone, even incompetent, is the worst thing I had to do in my career.
+24  A: 

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.

"95% done" is usually what the previous dev kept telling management. More like 50%.
Karl R
More like 20%. Because in some of the times, it would be faster if you rewrote that 30%. :-s
You must have been looking at some of my code. :) M.. er.. A company I know doesn't believe in QA, we don't use unit tests, and we almost exclusively hire people straight out of college.Due to this, I wouldn't have the first clue how to write a unit test.
John Kraft
Oxymoron! The state you describe can't be 95% done.
Loren Pechtel
I'm thinking that must be at one of my previous employers...
Sounds depressingly familiar
John Nolan
+2  A: 

Debug Javascript without Visual Studio 2008...

aherrick :)
@CMS: You need a JS debugger for each browser though. VS2008 is excellent for IE, a good one come with Office too (possibly "VS-lite" anyway). Dragonfly for Opera. Not sure about Safari or Chrome, never had a problem isolated to just those browsers.
Lee Kowalkowski JavaScript logging and profiling for all browsers.
Brian Gianforcaro

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

Sounds more likely rewriting from the ground up. I mean VBA, really? ( NOTE: I started programming with VBA. )
Brad Gilbert
i am on my second project doing this very thing
John Nolan

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#.

Jeremy Reagan
Oops, that's why I have spell check :)
Jeremy Reagan
+1  A: 

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

I had a very similar assignment, implementing Solitaire using FORTRAN.
Mark Bessey
If you knew Haskell as well as you should, it would have been done faster than in Java or C#. This is more a sign of inexperience than anything -- and good programmers should seek out new experiences.
Oh shut up ephemient. The fact is, many people find Java/C# easier to grok than Haskell, meaning it's easier for them to solve simple-matter-of-programming type problems with those languages. It doesn't *matter* that Haskell is a more expressive language.
To be fair, ephemient's claim was that a sufficiently good Haskell programmer would finish faster than an equally good Java/C# programmer. This is a distinctly different claim than the one you refuted. As always, what language you program in reflects how you think. Thinking functionally is not how many people are trained to do, but it is worthwhile. I myself love Lisp and x86 Assembly. Go figure.
+3  A: 

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.

I had a very similar experience but also had to add new functionality.
Schalk Versteeg

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.

Mark Bessey
+1  A: 

Y2K fixes in a FoxPro for DOS application.

Jason Diller
Now you need to worry about Y2038.
Brad Gilbert

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.


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

That's nothing. One of my ex-bosses wrote a chess program in Lotus 123 macro language.
+7  A: 

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.

So.. you had fun day, after all? :-)
the funny thing is that manager did the right thing, i think its great temporary solution or not temporary if you dont care.
+1  A: 

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.

Jeremy Bade

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.

Schalk Versteeg

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.

+1  A: 

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...

Dining Philanderer
So you are a nerd...
I got better...
Dining Philanderer

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.


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.

Loren Pechtel

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.


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.

Robert Rossney

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

Johnny Blaze
Dude, you hadn't already beat him to the punch on that? I can see why that wasn't a fun project.
Joe McMahon

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


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.