Programming in the Powerband

A power band, long the instructors' mantra at DMW Martial Arts, meant delivering a strike with maximum torque relative to proper form and requisite rotation. I know I've overshot my personal power band when I deliver a strike in the midst of a form and my hand tremors. Or, when I throw a back kick against a bag and the force of the rotation results in a departed angle and the kick placement is inaccurate. I understood the sentiment in referring to the body's physical operating range as its power band. Recently, it took on a new level of meaning.

Somewhere past Methow, WA on SR 20, over the whine of a 2010 Shelby supercharger, and shifting in the power band, came the existential connection. One may speak about power bands with graphs, describe the magnificence of holding the reins to five-hundred and forty ponies, or signal their exit from the discourse with a fact or pith on why their martial art, vehicle, or programming language is better. In action, the instruction, facts, and pith yield to how well the person executes by their capabilities with the equipment at their disposal.

The joy we take in putting down the established to chase flecks of shiny metal, the arrogance we succumb to drive through our myopic views upon the collective, and the education and practice we afford ourselves, shape our power band, metaphysically and beyond. The act of passing a car in a nearly four-thousand pound Shelby from 1,200 RPM means the effort begins below the vehicle's power band. As the car crosses the center line and the pedal stomped, the intercooled V8 has to work up to its potential, which, if there is oncoming traffic, may be a bit late. At the moment when the driver expects the car to respond, there is no point in becoming frantic when it trots instead of bolts, but it may require one to pull back. Understanding the capabilities of the vehicle and beginning the same procedure from within the power band, and shifting within the power band during the operation, has entirely different results. This is true for athletes who understand the importance of training adequately for an event. And, this is true for software developers and architects when selecting software processes, patterns, and runtimes.

While working with enterprise application server software that included a number of third-party and quasi-open source tools, and in trying to architect solutions that followed prescribed technical guidelines, I found myself spending more time working around errors in the tools than developing or unit testing my own software. And, when it came to unit testing my software or ferreting out bugs in the enterprise solutions, I wondered aloud: Where is the unit testing for the Web content? There are many unit test frameworks available, but far fewer that operate within the page, and of those, I didn't find any that were generic, easy to instrument, or easily abstracted. Preferable, I wanted to be able to write a simple test function and run the test across the page, or attach the test to a node in an easily-removed fashion, all without relying on further discoverability via global ids or class names.

Without testing the view, each shift from actual work to digging through third-party toolkit and runtime errors narrowed the power band of my development stride. I knew what I wanted, but couldn't find an implementation that met my three criteria of generic, easy of instrumentation, and abstracted. What I did have was a framework with most of the pieces already in place: I had written a lightweight unit test extension to Hemi. All that was missing was a convenient way to bundle, run, and abstract the tests. The result was a set of additional templates and a method for embedding JSON-esque configuration into a CSS class name (for schema compliancy where custom attributes are not allowed).

The result was captured as a pair of tutorials: TDD and Unit Testing.

One caveat to the architecture of large initatives is the process of selecting and standardizing on software and libraries may not fully include a full review of the ramifications of those choices. In my example with in-page unit testing, that worked because I had a specific set of problems I wanted to solve. Although myriad problems remain, in this one area I could influence, I identified the range of my development power band: The optimal power range of capability torqued by the technology.

Somewhere on SR 2, on the south side of the Cascade Loop, it started to rain. Pulling aside the Shelby to raise the top, idling around 1000 RPM, and expecting traffic to back up in Sultan, WA, I knew, at that moment, I was outside of the power band. And, given the circumstances, that was okay.