Trial And Error Programming

You're not quite sure how to make a call to someone else's code or how to get rid of a bug. Normally, you would whip out a book to see just how to use that string class, or you would start up the old debugger, or you would carefully inspect the code to see what semantic error you've made.

But - for whatever reason - you decide to forego this approach. Instead, you use the trustworthy ScientificMethod! Formulate a "hypothesis", compile it, and see if it works! If not, try another "hypothesis"!

Example "hypotheses":

• maybe changing a[i] to a[i-1] would help
• maybe adding a few blank lines will get it to compile (it worked on project frump three months ago!)
• maybe commenting out these lines will fix it

AlarmBellPhrases of TrialAndErrorProgramming:

• "Doing X fixed the problem, but I'm not sure why."
• "Let's try doing X, compiling it, and seeing if it runs."
• "OK, now make it pass the test."

---

Most successful programming methodology of all time. This is how DNA is written.

If time and resources are not an issue. And an enormously high failure rate is tolerable.

---

I don't agree with the implication above. DNA evolved - it wasn't written. There was no intelligence involved. Nobody tried out different ways. One might argue that natural selection is something equivalent, but it isn't, really, for a number of reasons. For one thing, natural selection is only one of the mechanisms of evolution. And teleological thinking like this can lead one into serious errors when talking about evolution - for example, the belief that "Mother Nature" (non-existent) somehow "optimally designs" organisms "by using" evolution. Books by StephenJayGould and NilesEldridge? are good places to look to understand this better.

Possibly related: WhatIsIntent

---

> I don't agree with the implication above. DNA evolved - it wasn't written. There was no intelligence involved.

I suspect you have the original writer's implication backwards: personally, I read it as meaning that the code to which TrialAndErrorProgramming is being applied can't really be said to be written either, as there is no intelligence involved. And there are other distinct parallels: e.g., it takes millions of years to get something that works, and you end up with systems that fail in very nasty and highly opaque ways that nobody really understands well enough to fix.

---

An excellent way to begin to understand a very complex bit of code.

---

Use of UnitTests might make one confident enough to start with TrialAndErrorProgramming and see if it does the trick.

I agree with this sentiment. If I have a problem that is not initially obvious, I will usually go with my first hunch as see if that resolves the problem. If not, then I will fall back onto more detailed analysis methods such as debuggers, print lines, and knowledge base searches. Since I have a reasonable success rate with the first hunch approach, I do not feel overly concerned that I do not understand why the problem occurred and why the solution resolved it. Life's too short to worry about verifying that someones library call uses a 0 or a 1 based index. Try one and if it fails a test, try the other. If both fail, then it is time to dig a little deeper.

---

And the alternative is?

---

DoItRightTheFirstTime

---

(Arguably) The only way to learn.

> I don't agree with the implication above. DNA evolved - it wasn't written.

... and your dumb uncle had to be caged because he refused to evolve.

{But he's alive and reproduced anyhow because of his "lab job" and may survive Armageddon, unlike humans.}

---

> ... and your dumb uncle had to be caged because he refused to evolve.

Individuals of any species can't evolve, but must instead reproduce. Bad implications for your program.

---

See CodeAndFix, BrutalSarcasm, DebuggingAndTheScientificMethod, EvolutionaryDesignIsWasteful