Do you trust code that works the first time?

Question

I gave a coworker the man page for a C function he hadn't used before, as well as some of the parameters for it. It interacts with parts of the system external to the application he was writing, and he was surprised and pleased that it worked the first time.

Then doubt set in.

He now worries that though it's working now it will fail in front of a customer - in other words, it's not 'hard-won' code.

I suspect many people learn the most about a function/class/etc by doing it wrong, and struggling with it until the light comes on and they understand it - then it becomes part of their toolbox.

• Has this happened to you, where you don't trust a piece of code you wrote that worked on the first run?
  • If so, what happened later? (never failed, eventually found a corner case, failed, failed spectacularly, etc)
• What do you do to allay your fears?

• In the absence of struggle, how do you learn the quirks of a new function/object/etc?

• In the broader sense - very new programmers are often afraid and doubtful of their own work - even typing in an example verbatim will still result in a feeling of, perhaps, "I can't do this, I'm sure it's going to fail, etc" until something clicks and programming either makes sense, or they have simply overcome their fear. How do you mentor someone new to get past this point?

Answer 1

Nope, I don't!

ACM/ICPC and similar contests are the best way to prove it to you!

Surely it'll help but logically, the only thing that it proves is that you got it right for that specific input or situation ;)

Answer 2

No, because I write test code for the use cases that I expect to occur, with the inputs (valid or invalid) that I expect to receive.

If it passes my tests, then I trust it.

Of course, this is a chain of trust, because I have to trust that my test cases are complete for the knowledge I have of the app (likely), which means that my customers had to have given me the correct info about how they are going to use the app and their expectations (unlikely).

But in the end, if you test it for what you expect and it passes your tests, it makes the question a moot point.

Answer 3

My code never works the first time, because I write tests first, and I see them fail. Without a test failure to fix, I can't have any new code.

(well, that was a bit of idealization of my reality, but you get the idea).

Answer 4

Code does not "work" unless it has full unit test coverage, and the tests pass.

Answer 5

When I approach a new technology, concept, or language I usually hit some stumbling blocks.

But 3rd party libraries, should do what their documentation says. So I am rarely stumped by another person's library.

I also do what CasperOne does. I will run the 3rd party module through a mini gauntlet of test cases.

Answer 6

I trust code I understand, I don't trust code I don't understand. Whether it worked the first time I compiled it or if I had to spend a day debugging it doesn't matter.

Answer 7

Oh yeah, this happens to me. Whenever I write a function that works (or seems to) the first time I try it, I feel a wave of paranoia.

Testing will help, but I think in my mind that code will always be tainted and I'll never quite trust it. I realize this borders on superstition but there you go.

Answer 8

Yes, I do. And TDD is a waste of time.

ymmv

Answer 9

No, this kind of code scares me.

However this is why you need QA departments developers can become blind to their code and subconciously not test it effectively after a certain period of time.

Answer 10

There is a huge difference IMO between trusting code you wrote yourself and somebody else's code that was thrown over the wall to you. If I have thought out the spec, if I have written the code, if it has passed my tests, then great if it works the first time - it is usually solid and doesn't fail later.

If it is someone else's code that I have never seen before and it works the first time in on particular case, then certainly I would be suspicious until it could be tested fully and/or reviewed in detail.

In general I will say that the above is true of humans in general, not just programmers. If you are a carpenter and you built the house yourself, you feel much better about it than walking into someone else's. You don't know if they cut corners or what.

Answer 11

Am I the only one who single steps through every line of new code in the debugger the first time I run it to make sure it's doing what I planned?

A colleague of mine expressed incredulity that I do this and says he only uses a debugger when he has a bug to fix.

Answer 12

This kind of code worries me as well. Like a lot of the other people who responded to this question, I usually write unit tests to allay my fears. If writing unit tests isn't feasible for some reason or another, I'll often substitute a small, console-based "driver" application that lets me test all code paths manually (or automatically), with a variety of data.

Answer 13

There is a quote written in one of our tester's desk.

In God we trust, every one else we test.

Of course, the code has to be tested for all scenario's even though it worked for the first time.

Answer 14

I used to have a dyslexic boss, who couldn't write a VB function to save his life without making at least 3 or 4 syntax errors or typos, however one day I sat and watched him write a T-SQL function that was about 30 lines long, and it ran on first compile / run.

I'd still want to understand what even his code was doing though, and would often write test functions to call and understand it better.