coding in flow, part III [0216.2000]

I'm having trouble with this notion of scheduling my time. I've got a fairly flexible schedule (I do my part-time contract work from home, and of course I can do whatever I want regarding zike), so trying to come up with a rigid schedule kinda goes against what I'm working for. I was wrong. Hey, I can admit it. But I think I found a discipline that can actually work...

If you recall, my metaphor was that "coding in flow" is like focusing light into a laser, and that freewriting helps can help us turn that laser on at will. The problem for me was getting caught up in "toy" projects. Even though they help to build a more powerful laser over time, they often lure me away for so long that I forget about the "real" work. There was no particular way of controlling when the laser turned off.

All of that just changed. I recently read Extreme Programming Explained, which talks about a set of common sense best practices in software design, and what happens when you turn them up to their logical extreme. The answer to my problem was right there on the first page of the preface:

If testing is good, everybody will test all the time ... even the customers.

Since my first real programming job was a Quality Assurance gig, I understand the value of automated testing. But.. Everybody doing it? All the time?

Heck, I was the one telling my boss that most testing is useless, and forcing individual developers to test their code is a collossal waste of time. And I was only talking about hand testing, let alone the expense involved in actually writing code to test your own programs.

Well, turns out I was wrong about that, too.

Thankfully, I'm either open minded or gullible enough try just about anything once. So I read over the UnitTests, UnitTestsDefined and CodeUnitTestFirst entries over on wiki.. And then I wrote some unit tests for the module I'm working on.

I used Stephen Purcell's Python version of the xUnit testing software, which was well documented and easy to use. (Actually, I'm making some modifications, but that's a different story..)

But.. I'm getting ahead of myself.. "CodeUnitTestFirst" means exactly that: you write the test case before you write anything else. That is, you write a test that you know will fail simply because you haven't written the code it's testing yet. Then you write the code to pass that test.

In NLP, we talk about "calibration", which applies to everything from eye accessing cues to determining whether or not you're reaching your goals. You can't calibrate unless you have a sensory specific way of measuring something.

Let me repeat that in terms of the laser metaphor: the laser never turns off until it has zapped the thing it is aimed at. If it can't calibrate to whether or not it has zapped the target, it will never shut off. It'll just keep zapping random things, or it'll just keep zapping the same thing long past quitting time - for example, in the recent case of my spending almost 20 hours straight on a windows-MIDI extention to python when I should have been "working".

Unit testing gives us a way to calibrate. We can press two buttons and run an entire suite of tests which tell us exactly whether or not its time to turn off the laser. Either all the tests passed, so we're done, or something broke, so we're not.

Calibration is the antithesis of planning. In both cases you set a goal. When you plan, you figure out exactly which steps you need to go through in order to reach the goal. With calibration, you decide how you'll know when you're reaching your goal, and just keep doing stuff until your senses tell you that you're done. (You also learn more and more, so that by the time you're a few iterations into it, you know far more about the problem than the guy who tried to plan everything right from the start, but that's a different story, too)

And, at least for me, there is a definite sense of accomplishment each time my code passes the current test. I know I'm done. I can step out of my "flow" state, and evaluate: do I neeed to switch to some other project? Should I move on to writing the next test? Have I learned anything in this loop that I can use to simplify the system as a whole? And so on...

There are other benefits to unit testing, and it actually seems to SAVE time, rather than take longer as I originally thought, but all of that is secondary right now. I'm just happy I can shoot my laser. :)