How do you deal with intentionally bad code?

Question

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"?

Answer 1

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.

Answer 2

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

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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.