Do you ever recur to that method? Can you live with knowing that you really don't know what you did?

Do you consider important to understand every little piece of what you're doing or you're more interested in achieving the final goal?

I personally do this a lot. Many times I'm faced with something I don't know or understand and I start making random assemblings and trials until it starts working. I sometimes think of it as a kind of "genetic algorithm" way of doing things.

Once it works I'm usually already familiar with all it's parts as to know more or less what they are meant to be doing.

So, what about you?

Sometimes I do it to explore some problem but I always want to understand why it worked.

If I am debugging something I might try to swap two lines of code. If that worked I would not submit the fix without some further investigation. Maybe the library should be used in a different way than we thought or perhaps I can improve the implementation of the library if it is not third party code.

I have worked with people that just randomly fiddle with the code until it works. I remember one occurance where a "fix" made the bug seem to disappear so I guess the bug could be closed. But that fix made pretty much everything else break.

If you can't explain why it worked you should not submit the code! Fix the underlying bug if possible.

I think that the more complex the system is that you're working with, the more likely it is that you'll end up with one of these "I poked it and it started working again" methods.

You really just reminded me of working with the Half-Life code base - there was a lot of "I don't know why this works but it does so I'm leaving it here" comments around the place -- and this code got a game of the year award

// this is the most hacked, evil, bastardized thing I've ever seen. kjb
// why does this work?
// hopefully this will fix the VELOCITY TOO LOW crap
// HACKHACK -- This is bugly, but the train can actually stop moving at a different node depending on it's speed
// is this legal?
// this is evil
// This will probably break some stuff[/quote]

Sure. Sometimes there's something that I'm not all that interested in fully understanding, but I just want it to work so I can move on to the more interesting bits.

Do you ever recur to that method?

Yep, it happens. I think everybody does at some point, especially when you're already past the deadline.

But there are various grades of evilness. If crashes are involved that magically disappear when moving around unrelated pieces of code, then something is fundamentally wrong. If you let that slip it will come back and kick you in the nuts really hard when you least expect it...

But on other occasions, I guess it's acceptable if it gets the job done. Just a couple of weeks back I tried to get a complex reference frame fitting function to work. Basically a huge list of concatenated matrices. On paper all looked good, but in code there would always be some axis flipped, some gimbal lock where it shouldn't, some attempt at inverting a singular matrix. It drove me insane. Realizing that I was still in office at 3am, I finally resorted to randomly switching matrix order - and after some trial and error it worked. Never looked back at that one...

Honestly, I'm too much of a perfectionist to do this except on very rare occasions. But it comes at a cost that I tend to be slower than most people getting code done. This is not to say that bugs don't slip into my code though. There's just a balance that needs to be reached, and some people fall on one side of speed and spaghetti hacks, and others on the opposite side.

I don't usually do this. I tend to make test cases and validate everything. However, if I'm using wpf at work I do just hack at xaml until it does something right. I don't care to learn why something I think should be valid requires 10 more tags. Heh

I used to do this, but after enough fumbling around I learned that it's usually quicker and more efficient for me to just start over what I'm working on than to keep bashing my head against the wall. I recommended that my friends start doing it, and after trying it the first time they all do the same thing. It might be worth a try -- after trying and failing to do something once, you often get new perspectives on how the problem needs to be solved.

I'm most guilty of this when I do some Math on paper, code it up and it doesn't work like I thought it would. The urge to tinker until it appears to work is often stronger than the more rational response of returning to the paper to see whether there is a flaw in the Math itself rather than in my translation of it.

In theory this is where you use your version-control system... but in practice I find these problems happen when in the middle of a change.