CaseBook, "Simple Ships", The Twilight Sad

CaseBook is an open-source quality assurance tool developed for my current client to organize and generate testing documents. It is similar in concept, though not in scope, to DocBook, consisting of a data-schema or three and an assortment of xsl transforms. When new application features are developed, a high level map is built in the CaseBook document, detailing pages and states, controls on the page and assertions about the page. This document is then transformed to generate acceptance, integration and regression documents. Once the application map has been created, further assertions can be skimmed out of our bug-tracking database (Bugzilla), using its Atom format reports.

For our latest development sprint, I was able to build a testplan containing some sixty testcases for a manual tester in a couple of hours. Refactoring this data is not difficult since all reports are generated by transforms. Adding further assertions is also quite simple.

Last Summer, at Home I had become the Invisible Boy - okay, so the title of this track from the debut release from Glasgow's Twilight Sad may be a little long... but, wow, if you like folky shoegazey music that grabs you by the guts and demands your attention, don't miss this one. "Last Summer" opens with a pounding percussive line reminiscent of Galaxie 500's cover of "Don't let your youth go to waste", building to an emotional release at the end, with vocals that could only come from Glasgow. I want to raise my children in that fair town, just so they can speak with that accent.

Last Summer, At Home....
The Twilight Sad - myspace

CaseBook is available at SourceForge.

During one of my early experiences as a developer, I worked in a development group that worked very hard to follow the keep it simple rapid development principle of "Simple Ships." Ideally, new modules are developed in short sprints, architectures don't become grandiose, and life is good. But we found ourselves adopting another adage: "Stupid Ships," and only half in jest. We discovered very often, throwaway ideas which began as a joke would prove to be more shippable than more traditional solutions. I have given a lot of thought to this as the years have passed: why is it that successful development often begins in jest?

The funny textual intrusions for record reviews and such also began as a joke, a holdover from my MA thesis, stolen quite shameslessly from David Foster Wallace's footnotes for Infinite Jest.

Even though we are told that creativity and innovation are absolutely essential to survival in today's technology market, the fact remains that ideas which are too far outside the box are shot down without consideration of merit due to time constraints. An idea promoted in jest may slip under the radar and plant a seed. I have definitely seen this happen on several occasions. What begins as an employee's throwaway takes on a new life when it is suddenly assumed by management. Often this happens when a new feature is given a silly name, for instance. In my experience, people like silly names, because it personalizes the otherwise obscure process of software development.

In reality, I was having a very hard time focussing on the task at hand, and since various other ideas kept interrupting the process of writing, I decided they should also interrupt the process of reading.

The jest, in this case, may create a safer forum for discussion, and one which has enough distance from the anticipated or perceived problem that a solution may be found that challenges the initial premises of the problem, which is often enough to create an innovative solution. "Wouldn't it be funny if instead..." is a great way to refactor a problem so that it becomes solvable.

This was also supposed to suggest a shuttle weaving from one side of the page to the other, but that is another story.

Also, if you are one of those developer people who experiences a knee-jerk reaction when your boss or client tasks you by executive fiat - "this is how it is going to be" - then the phrase "Stupid Ships" takes on a different shade of meaning: "Well, maybe I think this is stupid, and maybe I don't, but if you want it, and you will support it, and you will support me in developing it, then, well, we can ship it."

I believe a fundamental component in the shift from apprentice developer to journeyman, and then master comes from recognizing these "jests of brilliance" for what they are, as we encounter them, and instead of presenting them as throwaways, presenting them as statements that we are fully prepared to stand behind and back up.