Things I never, ever, want to hear. Ever.

Things I never, ever, want to hear. Ever.

  • In theory,… No, I don’t want to know what you think the code does, I want to know that it actually does—especially if you’re the one that wrote the code. If you haven’t verified, validated by actually testing stuff in a systematic manner, you have failed. Have you validated the functions with stringent unit testing? No? then get out of my face and go write code to test your code. Validate your hypotheses. Always.
  • It compiles correctly. This one also irks me quite a lot. It compiles, so, wow? Want a medal? You think that because a 10 LOC program compiles it works correctly? I fart in your general direction. Have you checked that the code does what it has to do, every time, on every input? That’s what interests me. If not, get out of my face and go back do your homework.
  • The compiler/OS/library has a bug. While it is nice to be able to think that the bug may be somewhere else than in your code, you should definitively start by suspecting your own code. When I hear stuff like “we have a bug when we compile using -O3, so the compiler is bugged” I have a hard time not to laugh at the person that uttered that. Unless you can prove me that the compiler has a bug and make a simple 5 lines program that reproduces the bug every single time in an explicable way, I’ll consider that you’re the source of the bug. Memory and register allocation change dramatically when optimizations are enabled, so a perfectly harmless buffer overflow in debug mode can cause an immediate crash with optimizations enabled. Seriously. Do you think that the guys that wrote the compiler didn’t check their code? The same holds when applied to an OS or library function.
  • I haven’t checked. I’ll do that later. This one really makes me want to bitch-slap silly whoever say this. Checking code is not some kind of cute endeavour to be undertaken if we have some spare time. Correct code is the core of a coder’s business. Incorrect code isn’t code. It’s garbage. I really wish everyone could fully realize how hard and how important it is to write perfectly correct code. Of course, we do not always succeed, but if we fail at writing perfect code, at least, let it not be by nonchalance and negligence.

I’ve heard a couple of other nice ones. One that made an epic facepalm moment is: strange, my program seems non-deterministic. Well, that’s worrying it you hear that about a single-threaded program… That pretty much tells me that there’s bug somewhere. O rly? ya, rly.

6 Responses to Things I never, ever, want to hear. Ever.

  1. Stuart says:

    I would also suggest variations of: It works on my machine. Wow! Just because it works ok on your machine doesn’t mean that the same code is going to work exactly the same on a different machine.

    • Steven Pigeon says:

      Oh right! I had this problem too, and quite recently as well. The one that comes right after it is “I don’t understand, my machine has nothing special”. Except for a few more libraries. And shell scripts. And environment variables. And duct tape.

  2. Having said all that, you might also add, that:

    1. Compilers/OSes/libraries do have bugs. Seriously. Of course, you should look for the bug in your code, but the first rule of debugging is “don’t assume anything”. Obviously I’m not saying that such bugs are very frequent.

    2. There’s a whole world between “incorrect code” and “correct code”. The mere fact that the code does not have tests does not mean that it does not work. It might even be as close to “correct” as practical. Of course, tests add confidence and often discover bugs/non-obvious behavior – however their presence and bug absence/code quality/etc. is not equivalent.

    3. Some code is very hard (close to impossible) to test. Yes, even if you are the author and you’ve refactored the hell out of it. Even functional tests sometimes can’t be done, setting unit tests aside.

    4. Thorough testing and correctness often clash with business requirements. If you have to deliver a build in two hours, you don’t have any time to write more tests. Just fix the bug and get the thing out. Yes, you might regret it later.

    5. “Works on my machine” is often an excellent point to start reasoning. In general, “works in my environment” (machine, compiler/libraries, input data) leads you to look for differences in environments, which often leads to a bug source.

    Just saying the world is not that black & white.

  3. Steven Pigeon says:

    The world is not black xor white, of course. But there’s a distinction between no, or insufficient testing, and reasonable effort of testing. True, you can’t test exhaustively all possibilities in all cases, but, if you can, you should. You can do a lot by testing individual components, then subsystems, and finally the complete software. The types of tests you do depends on what you’re testing exactly. Unit test for this, some other kind of regression test for that, etc. There are complete books written on the subject.

    Eventually, you’ll reach the point of diminishing return, where ten times the effort will bring you only one tenth closer to the ideal, perfect code, and you may decide at that point to release the software. But that’s a stage way beyond accusing the compiler of causing a bug in your code because, of course, your code is perfect.

    But you know what I meant, and I’m sure you’ve dealt with this kind of programmers before. I have. The kind that whatever goes wrong can’t possibly be their fault. You know, the nonchalant, lazy type?

    If “works on my machine” is the first step to discovering the bug, that’s all nice. But very often, you’ll get the “works on my machine” meaning that you are, or your machine is, the problem, not the software, which is perfect. I’m sure you got that too. That one irks me particularly.

    And yes, I do believe that code that is not, or insufficiently, tested is broken, by definition. Almost-kind-of-could-a-worka is pretty much useless. Tested with a few known and documented bugs is something else entirely.

    (Are we arguing for the same thing? :p )

  4. Yeah, I get that sometimes. It’s annoying. Still, “worksforme” can be a good answer, with the meaning of “this code works in our tests and worked for some projects; it’s possible that it has a bug that manifests only in your environment, but you’ll have to look for an answer yourself since I strongly suspect you’re to blame; come again once you’ve verified things on your end”. I tend to use that somewhat often (I develop & support internal tech which other in-house teams use), and most of the time the problem is actually in user code. Of course, sometimes it’s actually my bug; and often bug is in user’s code, but some additional verification is added to my code to help diagnose things faster should the similar problem arise.

    But yeah, the thing that matters is the attitude. And I agree that untested code can be considered broken, considering different types of testing (“Here’s the new optimized physics – I played through all levels and did not notice any glitches” is more than good enough for me, though more bugs may be found with further testing)

  5. Steven Pigeon says:

    Oh, another one I heard a couple of times. Remember when the first dual and quad-cores arrived? I had someone try very hard to convince me that the implementation of quad-cores had to be broken because they made its multi-threaded program crash.

    …yeah, right.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: