High Stakes Programming by Coincidence

Editorial note: I originally wrote this post for the Infragistics blog.  Click here and check out the original at their site.  There are a number of authors worth checking out that write for them.

Have you ever found yourself running your code to test out some behavior when you noticed something unrelated and thought, “that’s odd?”  Maybe you wanted to verify that clicking “run” kicked off the process it was supposed to, but you noticed that the “cancel” button was randomly green for a second when the window opened.  “That’s odd,” you thought.

After verifying that the process was kicked off properly, maybe you re-launch the application to see about that odd, green cancel button.  But when you open the window this time, nothing.  It’s the normal color, with no sign of the green you noticed before.  Again, you thought, “that’s odd.”  And maybe, at that point, you shrugged, chalked it up to some weird OS rendering burp, and moved on.

You never knew why the button went green, and you never knew why you couldn’t reproduce it.  This is a relatively benign version of the phenomenon known as “programming by coincidence.”

“Programming by coincidence” was coined in the book, “The Pragmatic Programmer,” and they define it as “[relying] on luck and accidental successes” rather than programming deliberately.  In the case of the mysteriously green button, the accidental success is the fact that the problem just kind of vanished on its own.

It’s probably no great surprise that the Pragmatic Programmer’s stance on programming by coincidence is “don’t do it.”  It’s my stance as well, and I imagine a lot of you reading agree.  And yet, it’s something we’ve probably all been guilty of at one time or another. Read More

Code Kata? How About Product Kata?

When I was a kid, I spent a bunch of years doing karate. As best I can recall, there were three main types of activities around which we’d focus: kihon, kata, and kumite.  I listed these roughly in order of sophistication.

• Kihon translates to something like “basics” and it involved executing the same punches, blocks, or kicks repeatedly, going for correct technique.
• Kata was something like “form” and this involved stringing together moves into more complex sequences and practicing those, presumably to emphasize rote practice of sequential movements.
• Kumite was sparring, and this was meant to be in-situ, improvisational practice, using the first two activities as building blocks.

There’s a lot of spiritual type stuff that goes on around martial arts, and it’s not my intention to rag on that in any way. You get out of things what you put into them and you find value that makes sense to you.

But, at its core, these activities are really all about learning how to punch and kick other people and win fights. So you practice the basics, string those together into sequential movements and then have dress rehearsal sparring matches.

This is all done so that when the time comes to actually punch and kick people in real life, you’re good at it. You don’t flinch when someone throws a punch because your countless hours of practice have made stepping into the blow, deflecting it and countering as second nature to you as cringing and protecting the head are for most people.

Learning to Punch People with Our Code

When I first heard of the martial arts concept of “kata” being applied to software development, I found it sort of interesting and weird. There’s intense marketing power in appropriation of this nature, and it can really make a concept take off.

And, there are parallels between the two beyond the simple notion that deliberate practice improves technique. One of the main benefits to code katas is the practice of techniques like refactoring, TDD, etc. when the pressure is off.

When in coaching/mentoring roles, it’s pretty common to see people try new techniques, only to abandon them when delivery pressure is perceived. To have “stickiness” for a software development technique, it’s essential that it hit a tipping point where the practitioner finds it less efficient to skip it than to do it. And doing a lot of code katas is a way to work toward that tipping point.

Of course, as with any cross-disciplinary metaphor, there are gaps and those gaps can be problematic. Again, putting aside the spiritual overtones, karate is about learning to punch and kick people effectively. This is pursuit heavy on instinct and muscle memory and relatively light on cerebral cortex activity.

A fight also spans seconds or, at most, minutes, where programming is a pursuit of hours, days, weeks, months, or years. I believe it was this sort of information gap that led John Sonmez to post about code katas. He heard the term “code kata” and mapped the martial art version onto it — one where you practice precisely executing the exact same movements until you can do them in your sleep.

That’s not the intent of the code kata, but recall that we’ve been over what happens when you recycle terms with baggage for marketing purposes.

Read More