Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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

share|improve this question
9  
Is it "sometimes by accident" or is it "intentionally bad"? I don't see how it can be both. –  Roger Pate Sep 27 '10 at 11:16
add comment

6 Answers 6

up vote 3 down vote accepted

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.

share|improve this answer
add comment

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.

share|improve this answer
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 Sep 27 '10 at 12:06
7  
Even if not legal, at least there's an ethical obligation. –  Chris Farmer Sep 27 '10 at 13:45
add comment

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

share|improve this answer
    
+1 I'm really a fan of the concept of shipping products. I think too many technical profiles are just missing that concept. –  user2567 Sep 27 '10 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. –  Joonas Pulakka Sep 27 '10 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 Sep 27 '10 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. –  sunpech Sep 27 '10 at 15:48
2  
@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 Sep 27 '10 at 15:56
show 2 more comments

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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