I unabashedly love the art of metaphor. I find it to be uniquely powerful in that it allows one type of thoughts to be overlaid or substituted for another. In discussing testing regimes with our Q/A manager at DecisionDesk, I stumbled upon a new and useful metaphor; web-application as a pirate ship.

We’re wrapping up the massive engineering effort that went into the new version of our system. It’s a rebuild from the ground up with a new database and a new API-centric client/server architecture. Our new stack is Mongo, Django, Tastypie, Backbone, and there are a lot of unknowns to account for and that means lots of testing.
One use I have for metaphor is to grant heuristics for classifying things according to collections of semi-arbitrary groups like the ones mentioned above. A good metaphor serves for a model to determine what category something is.
A company can be thought of as the crew of an old sailing vessel, kept afloat by it’s hull, and propelled by the wind in its sails and for a web company, the ship itself really represents the web-application through which the company’s service is offered. On this, the good ship metaphor, a serious issue is like a hole in the hull, actively letting water in in the form of bad customer experiences which drive people to other services. A less serious issue could be thought of as a hole in the sail, it decreases the capabilities of the ship but not so much as to prevent it from functioning (unless there are a lot of them). In the hostile waters of a competitive market, the good ship metaphor would be under threat and so need weapons; cannons in the form of new features to crush competition with.
Through the lens of this metaphor (meta-metaphor much?), we can see clearly the classification and prioritization of engineering work to be done. One wouldn’t work on the new cannons while there’s a hole in the hull, nor would one fix the sails while the enemy approaches.
As crucial as testing is to us as a reliable web company, it’s also important not to let ourselves get so bogged down in bugs and testing that everything else grinds to a halt. I’ve been doing some thinking to help us avoid getting stuck in that mire, and come to the conclusion that there are three categories of engineering work we need to be doing right now.
Zero Day Fixes
For “brown-pants-moments”, issues that need to be corrected immediately in our existing product or risk providing an unacceptable experience to our customers.
Two Week Fixes
For aesthetic, workflow, or other minor issues that represent a sub-par but acceptable experience for our customers. Many of these are the kind of thing that customers don’t even know aren’t the way they should be because it does work, just not optimally.
New Feature Development
Work on new stuff that our customers may or may not expect. Some of these have a timeline for delivery to specific customers whereas others are exploratory attempts.
All this kinda gives new meaning to the phrase “ship it”. Yarrrrrr arrrr arrr ar.
