views:

254

answers:

6

I just caught myself doing something I do a lot, and wanted to generalize it, express it, share it and see who else is following this general practice, to find some other example situations where it might be relevant.

The general practice is getting something wrong first, on purpose, to establish that everything else is right before undertaking the current task.

What I was trying to do, specifically, was to find examples in our code base where the dojo TextArea widget was used. I knew (because I had it in front of me - existence proof) that the TextBox widget was present in at least one file. So I looked first for what I knew was there:

grep -r digit.form.TextBox | grep -v svn

This wasn't right - I had made a common (for me) mistake of leaving off the star, so I fixed that:

grep -r digit.form.TextBox * | grep -v svn

which found no results! Quick comparison with the file I was looking at showed me I had misspelled "dijit":

grep -r dijit.form.TextBox * | grep -v svn

And now I got results. Cool; doing it wrong first on purpose meant my query was correct except for looking for the wrong thing, so now I could construct the right query:

grep -r dijit.form.TextArea * | grep -v svn

and be confident that when it gave me no results, it was because there are no such files, and not because I had malformed the query.

I'll add three other examples as answers; please add any others you're aware of.

+4  A: 

TDD

The red-green-refactor cycle of test-driven development may be the archetype of this practice. With red, demonstrate that the functionality doesn't exist; then make it exist and demonstrate that you've done so by witnessing the green bar.

Carl Manaster
That occurred to me also. If you are setting up a test for something that currently works, you have to test the validity of your test by breaking something. Once your satisfied the test works, you go un-break it.
Smandoli
Duh. I assumed TDD was what you were talking about in your question.
Robert Harvey
A: 

arrange - assert - act - assert

I sometimes like, in my tests, to add a counter-assertion before the action to show that the action is actually responsible for producing the desired outcome demonstrated by the concluding assertion.

Carl Manaster
so ... Proof = FALSE ... then see if your next line changes it to TRUE?
Smandoli
Precisely. I put an example here:http://stackoverflow.com/questions/1021007/should-it-be-arrange-assert-act-assert/1034479#1034479
Carl Manaster
A: 

When in doubt of my spelling, and of my editor's spell-checking

We use many editors. Many of them highlight misspelled words as I type them - some do not. I rely on automatic spell checking, but I can't always remember whether the editor of the moment has that feature. So I'll enter, say, "circuitx" and hit space. If it highlights, I'll back up over the space and the "x" and type another space - and learn that I spelled circuit correctly - but if it doesn't, I'll copy the word and paste it into a known spell-checker to see whether I did.

Carl Manaster
A: 

I'm not sure it's the best way to act, as it does not prevent you from mispelling the final command, for example typing "TestArea" or something like that instead of "TextArea" (your finger just have to slip a little for such a mistake).

IMHO the best way is to run your "final" command, but on two sample files first : one containing the requested text, another that doesn't.

In other words, instead of running a "similar" command, run the real one, but over "similar" data.

zim2001
+1  A: 

http://support.microsoft.com/kb/275085

This VBA routine turns off the "subdatasheets" property for every table in your MS Access database. The user is instructed to make sure error-handling is set to "Break only on unhandled errors." The routine identifies tables needing the fix by the error that is thrown. I'm not sure this precisely fits your question, but it's always interesting to me that the error is being used in a non-error way.

Smandoli
+1 That's a nice trick, and it's related to what I describe, although I think not a 100% match.
Carl Manaster
I think it's generous of you to +1 ... kind of a mechanized thing and you are after something idiosyncratic and even intuitive, which is interesting. You probably enjoy playing Go.
Smandoli
+1  A: 

Here's an example from VBA:

I also use camel case when I Dim my variables. ThisIsAnExampleOfCamelCase. As soon as I exit the VBA code line if Access doesn't change the lower case variable to camel case then I know I've got a typo. [OR, Option Explicit isn't set, which is the post topic.]

I also use this trick, several times an hour at least.

Smandoli
+1; Excellent example, exactly the kind of thing I meant.
Carl Manaster
Yeh, I was hanging my head after my Ubuntu entry ... "Umm, I put a good light bulb in my bathroom fixture to make sure we aren't having a power blackout, and THEN I put in the bad bulb to make sure it's burnt out ..."
Smandoli
I think an intriguing angle on your question is the challenge of identifying one's behaviors when they are ingrained habit.
Smandoli