There are many stories about intentionally bad code, not only on TheDailyWTF but also on SO. Typical cases include:

  • Having a useless time-wasting construct (e.g. an empty loop counting to some huge value) so programmers can easily "speed up" the application by removing it when they are tasked to.
  • Providing intentionally misleading, wrong or no documentation to generate expensive support requests.
  • Readily generating errors, or worse, generating even though everything worked fine, locking up the application so an expensive support call is required to unlock.

These points display a more or less malicious attitude (even though sometimes by accident), especially the first point occurs rather often.

How should one deal with such constructs? Ignore the issue, or just remove the offending code? Notify their manager, or speak to the person who introduced the "feature"?

  • 10
    Is it "sometimes by accident" or is it "intentionally bad"? I don't see how it can be both.
    – Roger Pate
    Commented Sep 27, 2010 at 11:16

6 Answers 6


Most bad code is due to a lack of understanding and the solution is education.

Intentionally bad code is entirely different, due to something completely unrelated to the coder's experience or the rest of the project. As such, you have to find out why they are sabotaging the code on purpose and deal with that issue. This means, more often then not, office politics, and that's rarely a pleasant situation for anyone.

How I would handle the politics side depends on many (unstated above) circumstances. How I would handle the code is to first make sure I'm not the one misunderstanding—that it really is bad code—then fix the obvious deficiencies. If reasonably possible, write tests that the bad code will fail. Double-checking that I've understood correctly would mean talking to the person who wrote the code. That should be done in a very nice, polite way, without assuming intent, and may help to find the underlying (political) reason needed later.

Shipping is more important than ivory tower perfection, but there are two points worth addressing. Fixing obvious deficiencies gets you 80% of the results with 20% of the effort, and that kind of low-hanging fruit is seldom worth ignoring. But more importantly, if you don't address the underlying (political) reason, it's likely more intentionally bad code will be written and cause further problems—and possibly prevent shipping.


I've never (in 20-odd years) come across intentionally bad code, but the examples you cite seem (to me at least, but IANAL) to be attempts to defraud either an employer or a customer, so you probably have a legal obligation to point it out to your manager.

  • 2
    Agreed. Nobody writes intentionally bad code. They're solving a problem, and they're solving it in the best way they know. They may be misguided, undereducated, ignorant, etc. But I can't really fathom a developer intentionally writing something they know is bad.
    – Dan Ray
    Commented Sep 27, 2010 at 12:06
  • 8
    Even if not legal, at least there's an ethical obligation. Commented Sep 27, 2010 at 13:45
  • @ChrisFarmer You can't separate ethical obligation from the wider context - there are some contexts where deliberately bad code represents legitimate collective resistance, either economic or political. (And an employment contract only deserves to be honoured in good faith when the relationship it formalises isn't exploitative individually or structurally.)
    – user234461
    Commented Aug 1, 2017 at 15:40

Depends on the culture of the company. More often than not, it's simply not your job to fix and clean up all bad code.

From Coders at Work, Jamie Zawinski's thought on overengineering, which can also be applied in this situation:

At the end of the day, ship the fucking thing! It’s great to rewrite your code and make it cleaner and by the third time it’ll actually be pretty. But that’s not the point—you’re not here to write code; you’re here to ship products.

There's plenty of bad coders and code out there, and simply trying to fix them all as you come across it, at the expense of the current project/task, may simply not be worth it if the product "is working". Too often, we are all just duct-tape programmers.

Also see Joel Spolsky's post: The Duct Tape Programmer

  • +1 I'm really a fan of the concept of shipping products. I think too many technical profiles are just missing that concept.
    – user2567
    Commented Sep 27, 2010 at 9:07
  • +1 Me too. There are way too many "Clean code" -kind of books etc. out there that endorse a skewed view on what's important. Code quality is only so important. The winners aren't those who have the best product. It's those who have a good enough product shipped quickly enough. Commented Sep 27, 2010 at 9:59
  • 4
    I think you missed the point in the question - the guy talked about intentionally bad code, not simply code that was written by bad programmers.
    – Hila
    Commented Sep 27, 2010 at 12:19
  • @Hila I believe my point still holds whether or not the bad code was intentional or not. Unless it's an issue that was on the project/task list assigned, it's not the responsibility of a duct-tape programmer to fix and clean all bad code. The culture out there isn't academic and to write clean/beautiful code. It's about shipping and supporting a product/business. I personally would love to fix all bad code I come across, but I can't dedicate 100% of my time to that-- I simply would never be able to finish the task/project assigned to me then.
    – spong
    Commented Sep 27, 2010 at 15:48
  • 3
    @sunpech But cleaning intentionally bad code is not the same as just cleaning any code. It's not about making your application more "beautiful", it's about fixing harmful code that was put there on purpose. It's like saying a doctor shouldn't take out scissors a colleague forgot inside a patient because a cardiothoracic surgery is about life saving and not about how pretty the stitches are.
    – Hila
    Commented Sep 27, 2010 at 15:56

That attitude is the symptom of something worse.

  • Is management encouraging developer's competition ?

  • Where is the team spirit ?

  • Are tasks assigned by someone else than the team itself ?

  • ...

In any case, removing the offending code is not enough. Complaining to his manager will certainly not help improving the team spirit.

I would try to speak with the person directly and try to understand why by asking many questions without judging him. The whole team has to do it without agressivity.

In most case, that constructive behavior put the real problem (the worse one) under light, and then you can work on it.

If it really doesn't work. Remove that developer from the team.


If I thought it was intentional I would probably fire the guy! If it is a result of someone not being a good enough programmer I would work on his skills. If it was being pushed from above I would probably start looking for a new job.


How should one deal with such constructs? Ignore the issue, or just remove the offending code? Notify their manager, or speak to the person who introduced the "feature"?

Depending on the context, any one of those might be the most appropriate. Other possibilities include, asking to transfer to a different project, getting a new job, and various acts of questionable morality and/or legality.

However, given that we don't know the real facts and the real people involved, there's no way that someone in the position you are describing should be paying much attention to our advice / 2 cents worth.

If this a real situation you are talking about, it might be worth having a quiet word with your manager, asking their advice on what you should do. If possible try to make the conversation about what you can / should do, not about pointing the finger. If possible, don't name names. There's a fair chance that your manager already has an inkling of the problem.

But the flip side is that you might be blowing this out of proportion. Think long and hard about that before you do anything. Think of the consequences, including the possibility that any steps you take might backfire on you ... badly.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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