Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm working with some code which was written by a contractor who left a year ago leaving a number of projects with buggy, disgustingly bad code. This is what I call cowboy PHP, say no more.

Ideally I'd like to leave the project as is and never touch it again. Things break, requirements change and it needs to be maintained. Part A needs to be changed. There is a bug I cannot reproduce. Part A is connect to parts B D and E. This kind of work gives me a headache and makes me die a little inside. It kills my motivation and productivity. To be honest I'd say it's affecting my mental health.

Perhaps being at the start of my career I'm being naive to think production code should be reasonably clean. I would like to hear from anyone else who has been in this situation before. What did you do to get out of it? I'm thinking long term I might have to find another job.

Edit I've moved on from this company now, to a place where idiots are not employed. The code isn't perfect but it's at least manageable and peer reviewed. There are a lot of people in the comments below telling me that software is messy like this. Sure I don't agree with the way some programmers do things but this code was seriously mangled. The guy who wrote it tried to reinvent every wheel he could, and badly. He stopped getting work from us because of his bad code that nobody on the team could stand. If it were easy to refactor I would have. Eventually after many 'just do this small 10minute change' situations had ballooned into hours of lost time (regardless of who on the team was doing the work) my boss finally caved in it was rewritten.

share|improve this question

closed as not constructive by Walter, Yannis Mar 7 '12 at 17:11

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

Man up, step up, clean up, test up, party up. – Job Nov 30 '10 at 2:10
Welcome to the software world! – Manoj R Nov 30 '10 at 5:55
Hell is other peoples code. – user1249 Nov 30 '10 at 9:29
At the same time, it's worth remembering that a lot of crazy-looking code makes a bit more sense when you understand how it came to be. Perhaps the customer just couldn't make up their mind, or perhaps it needed to be compatible with something else which is now gone, or a certain library which would've made it super-easy isn't on the production machines, and they didn't have QA bandwidth for it, etc. – Darien Jun 14 '11 at 23:27
@Job: The usual process in the industry is wake up, stand up, throw up, give up. – Tom Anderson Jun 21 '11 at 14:03
up vote 20 down vote accepted

You run into this kind of crappy coding all the time. It won't be the last time you see it. You have two choices.

A) Get it done. Sucks, but the more you stare at it, the worse it looks. Just run through line by line to get it working, then refactor.

B) Start over again from the beginning. There are many times I wish I had just done this. One project, there was about a month of disgusting code put into it. I rolled with it since I didn't want to lose a month of work we had paid a contractor for. Now, I wish I had just hit delete and started over again. His mistakes haunted me for a long time... which is in the end, my mistake that there were still mistakes left by him.

share|improve this answer
Thr problem with starting over from the beginning is that needs experience to see when it makes sense and when not. But still, a very valid point. – Oliver Weiler Nov 30 '10 at 12:32
I inherited some egregiously bad code, and I thought it would be cool to build interface code that allows the existing code to mostly stay as-is, while at the same time, over-engineering new code in a manner that wasn't really appropriate for the scope of the project. Now, I have 2 problems: 1. The old, sucky code still exists; 2. The new code is overly complex, and difficult to debug, troubleshoot, extend, maintain, etc. I would have been better off with @Ginamin's option B. – Tim Claason Nov 30 '10 at 15:52

There will always be crap code. Frequently the answer to "what idiot wrote this crap?" is the one that looks back at you from the mirror [A].

One way of dealing with broken crufty old code is to slowly refactor it while adding unit tests. I recommend the books Working Effectively with Legacy Code and Brownfield Application Development in .Net (note that this book is .NET specific while the first isn't). One application that I am currently working with is so tangled up that there is no way to add unit tests without refactoring it (the main form is passed as a parameter to every object and class - and those objects/classes all refer to stuff on the main form).

To keep track of what components connect to other components, I usually use Visio (there may be some equivalent drawing tool in your IDE of choice). When the drawing looks like a bowl of spaghetti, then it is past time to refactor it. You may find that frequently documentation is something that devs do after finishing a project (if ever), or done to figure out what is going on (more common than you think) because there was no documentation left behind.

Perhaps I'm just being at the start of my career I'm being naive to think production code should be reasonably clean.

Yes you are [B]. Now moving along, frequently folks do hurried rush stuff to get something done. Just do it and whatever it takes are the slogans of people who don't want "clean" stuff - they want quick and cheap. Remember that old saying "quick, cheap or good - pick two"? This is the sort of thing that commonly results when the quick and cheap corners of the triangle are grabbed.

A little saying that my father used to say [C] to me goes like this: "When you go to work, they hand you 2 buckets. One they fill with money. And one they fill with shit. When the bucket filled with shit is heavier than the bucket they fill with money, you leave."

A - Congratulations, you are learning that there are better ways to write stuff that your old self didn't know about. To paraphrase Alec Balwin's character in Glengarry Glen Ross: ABL. Always Be Learning.
B - Don't worry, being cynical and jaded takes time, practice, lots of screaming and lots of other things. Mostly experience. Don't go for bitter, as that is what you get when you are burned out (and them some).
C - Mostly this was said in conjunction with working in a certain middle eastern nation, but it applies worldwide.

share|improve this answer
+1 The buckets metaphor is good. – Keyo Nov 30 '10 at 5:12
+1 for "Frequently the answer to 'what idiot wrote this crap?' is the one that looks back at you from the mirror." I think the only programmer who can honestly say he's never looked critically at code he wrote earlier -- sometimes just months earlier -- is the one who has never looked at his old code. – Matthew Frederick Nov 30 '10 at 6:12
You get a one for that comment one. Seriously, I sometimes cringe. Especially code that was written during a time crunch. – Ginamin Nov 30 '10 at 8:18
@Matthew, ah, Aberforth Dumbledore! – user1249 Nov 30 '10 at 9:59
Aberforth Dumbledore ( – Gary Rowe Nov 30 '10 at 12:49

I realize this may sound kind of cruel but working with crappy code on first job is kind of boon in that you have realistic expectation with subsequent jobs (and I say this from personal experience). Truth is, while all of us would like to work with awesome code, that doesn't happen quite often. Hence it is necessary to have a perspective about these things. More importantly dealing with such kind of code tests and hones your skills in a way that good code (or working from scratch) can not, and one that is always appreciated in the industry.

share|improve this answer
+1 Agree makes you realize the kind of developer you don't want to be. – Ginamin Nov 30 '10 at 3:43

In my first job, I was in a similar situation, and I eventually quit after a few months. It's just too depressing to work with fugly code all day long, especially when you are young and ambitious.

share|improve this answer

I'm reminded of Groucho Marx's quote "I wouldn't want to belong to any club that would have me as a member". Don't take this personally. It sounds like you are really passionate about programming. It's just that unless you got a 4.0 from MIT, had internships with Google, and found time one weekend to prove that P != NP, your first job probably won't be anything to write home about. Some people are naturals at networking, writing resumes, and interviewing will land the perfect job no matter what. The rest of us have probably spent most of our time writing code and need to brush up on these skills. Until that happens, we usually have to take some jobs that are below our skill level. I'm saying this not to say "Deal with it, that's life" but to point out that this is a natural part of starting a career.

The best advice I ever heard on this subject was Martin Fowler's. In a situation like this, you can either change your company or you can change your company. In other words, try to help this company improve (this is difficult and draining, but far from impossible) or find another company that doesn't suck.

share|improve this answer

A lot of production software sucks, everyone has or had a job that really sucks... like Job said, man up, step up... or quit, probably you will find another job with crappy code.

share|improve this answer
Lol, you can't run away from that shiat. – Job Nov 30 '10 at 2:20
Changing jobs to get away from poor code would be a very bad idea. You'll every bit as likely to find equally bad (or worse!) code at your new job. – Carson63000 Nov 30 '10 at 2:23
@Carson - I have definitely left jobs with bad code to start a job with good code, so it's not impossible. It's not the code itself that should cause a person to leave. It's the lack of craftmanship and pride in their work that turns me off. – Jason Baker Nov 30 '10 at 10:15
+1. I've worked at jobs where the code sucked and caused people to leave (and I left for better code too). I agree with Jason Baker though - it's usually more a symptom of the Dead Sea Effect than just bad code existing in isolation somehow. – Bobby Tables Jun 14 '11 at 23:03

There are essentially two types of responses you'll get to this type of question:

  1. Man up and deal with it. Bad code is everywhere.
  2. Maybe the code really does suck, find another job.

Both can be true: 1) business pressures and real life simply mean that production code often does incur some technical debt and gets hacky over time, so you can't always realistically expect to work with 100% clean and beautiful code. 2) Some companies and projects really do suck.

The bad news is - if you are very early on in your career, it can be very hard to tell the difference. You might get a job in a company that is otherwise quite successful as a business, but the software side of it sucks. It's a Dead Sea engineering department, but the product is still stable enough and selling well enough for the company to be reasonably successful. This will drive you crazy, because you're dying inside knowing that you're working on code which is an abject mess, while from the business point of view things are fine, and noone cares about your complaints.

Telling the difference between the two gets easier the more jobs you've had. This is probably the main reason why I think a bit of job hopping is good in the first decade of one's career. Go through about 3-4 places and see how different organisations and projects work, then you'll be able to gauge pretty well if what you're working on is just a "reasonable" crappy legacy/maintenance project, or if it's a real Dead Sea mess. There are some telltale signs, but it's mostly something you come to "just know when you see it", like the difference between pornography and artistic nudes.

share|improve this answer
Good answer. I've since moved on to option 2. There is still ugly legacy code around, but there are ongoing improvements to it and it's nowhere near as bad. Since this code was written the company has added a lot more best practices like peer code reviews and DVCS repos. – Keyo Jun 15 '11 at 0:44

It happens. You could read this crap from beginning, and drop all your complaint, refactor is the correct thing you should do, and I guess you would proud of yourself when this crap become graceful

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.