The bug for December is a problem bugging primarily just me: I broke my wrist skiing December 30th. I have determined the computing world (and in fact much of the real word) makes it very difficult to do seemingly simple things with only one fully functioning hand, like for instance typing on a full keyboard (handhelds are friendlier.) I’ll therefore keep today’s story short and then rest my arm after typing so much in one sitting.
We had a crash coding assignment come into the lab in mid November and finished the first shippable version to the customer in late December. This feature work, which we are calling Transaction Analysis when it goes generally available in a DevPartner Studio release later this year, represented a steep schedule and technical risk. The request mirrored the existing Entry Point Transaction Tracking already shipping in DevPartner Java Edition, yet DevPartner Studio had none of the basis for entry points or transactions readily available, so we couldn’t just steal code. Instead, due to the risks, we followed a formal methodology including requirements capture, requirements elicitation, preparation of primary and alternative implementation strategies, and writing a functional specification detailing implementation work items, testable checkpoint plateaus, and potential future enhancements. The risks centered around the facts that the two engineers assigned with implementation were going into the high speed, low overhead, tightly coded heart of the DPS Analysis profiler core (TTCore, for those aficionados of TrueTime) with their changes, no matter what implementation they chose, and they had nearly zero working experience in those particular existing code modules. And it had to be demonstrable in December.
After we stacked up the proposed changes, I tried to come up with a way other than priority or hours or severity as a way to characterize and communicate the risk for the effort for each item. Since we had to make an overall estimate, but the individual work item estimates were built on the engineers’ ability to take a best guess based on general experience but not actual immersion into that slice of the codebase , I proposed using – you guessed it -- a skiing metaphor. Ski mountains are covered with trails of varying complexity, each labeled with a sign with a colored symbol to show with how steep, bumpy, narrow, icy, or tree laden they are. Easy runs are marked with green circles, moderate trails with blue squares, hard with black diamonds, on up to triple black diamond expert runs. There is no easy mathematical way to construct an index for each run, so some local experience by the resort operator goes into the choice of ranking by run, but no matter where you go skiing, you can be certain the double black diamonds will be tougher than the blues.
Why does this methaphor work? In actuality, the rankings capture not just the complexity of the run, but also aim to match the terrain with the skill of the skier, and also the reward of doing that caliber of trail. Beginners should self-select to stick to the green runs, while experts, as they earn experience, congregate in the double and triple black diamond chutes. As you improve in your skills, you can take on higher ranked runs with more confidence, and with more pride of accomplishment and thrill experience, since you got to rip down the steeper hill faster or hop higher off the bumps or zig zag through denser trees. In the case of our development work items, the skiing symbol captured both technical risk of change based on where existing code needed to be extended, the expectation that the black diamond work item should only be done by a strong caliber of coder with intense focus so that some greens and blues could be off-loaded to other teammates without much risk, and as well a marker of the longer term reward to the product and users because the change should bear lasting structural benefit for additional enhancements. The black diamonds represent key new intellectual property we’ve added to the code tree.
I’m sure seeing a stack of colored symbols (other than maybe red yellow green) might give most project and dev managers pause because you cannot sum them and divide by number of developers. But that is the dead honest truth about most hard software development assignments: until you match the developer to the technology to the assignment and let them ski a few runs, your estimates best not lead you into believing your projection is either accurate or precise. The only reason we hit the December target is that the developers had a hard commitment date to hit, and built out the few black diamonds absolutely needed to demonstrate the feature was working, plus a small handful of blues and greens to make it nice to use. They then pushed all the other highly desirable but impractical-to-tackle-right-now work items off into the backlog for future prioritization.
The Transaction Analysis feature should ship in Beta about the time my cast comes off.