by Rick Carlton
It is said, that in the heady days leading up to the first Space Shuttle launch, engineers at Rockwell Aerospace wanted to measure the negative potential of bird strikes on their shiny new spacecraft. In order to produce a test regime that could be quickly measured and replicated, given the numerous sizes and weights of birds the aircraft might encounter in flight, the wonks in Palmdale hit on the novel idea of shooting raw, grocery store chickens at the Enterprise testbed using high-pressure air cannons. Allegedly, the process worked so successfully that the company published a series of technical monographs establishing its essential test requirements, followed by the effort’s detailed metric findings.
At about the same time, engineers at British Aerospace (BAC) found themselves in the midst of a host of bird-strike incidents resulting in windscreen cracks on the supersonic Concorde. After hearing of Rockwell’s work, and being clever engineers themselves, the BAC bird team decided to adopt and apply Rockwell’s Shuttle test requirements to their own problem, since the American methodology appeared to be generally relevant to their own engineering problem, while also offering a quick way to develop their own high-speed ‘chicken-thumpin’ program.
Unfortunately, however, things did not go well, since the BAC team experienced different results each time they pumped air through their cannon. After struggling to find a solution, and after relaxing its corporate stiff upper lip, the Brits finally decided to ask for help. Subsequently, a junior engineer was tasked with sending an early electronic BITNET message to the Rockwell team, listing all of the steps involved in the off-shore effort, then closed by suggesting that either the American requirement was in error in someway, or failing that; asking for any remedies they might offer. After a tense wait of several days (engineering is engineering, and competition is competition after all), the young boffin received a short, and entirely Americanized response in turn; ‘Thaw the chicken.’
Now, I can’t prove that any of these events actually happened, but what I do know from my own development experience is that the story of the cautionary ‘chicken-thumpin’ affair is as relevant today, as it may have been in the early 80’s. Why? Because technology has certainly evolved in the last thirty years but, to be frank, engineers haven’t, and well-educated ‘smart people’ rarely enjoy working within the limits of a formal requirement when simply being ‘creative’ is so much more fun.
If you don’t believe that there’s a concern here, take a look at the qualities of today’s standardized and incremental software methodologies like AGILE, or globally standardized systems development protocols like ISO. The common denominator in both cases is the word ‘standardized’; and why does that word apply specifically and rigidly? Because left alone, engineers will ‘assume a fact’ that doesn’t exist within a requirement’s fine print, in the same way that the BAC team missed Rockwell’s temperature note. In the real world, however, the impact of even a small error, like acknowledging the density difference between an entirely thawed, versus a frozen-as-a-rock roasting hen, frequently costs time and money that a developer doesn’t have.
In the end of the day, then, if you find yourself facing a go-to-market slowdown you can’t fathom, you might want to go back to the beginning, re-analyze the requirement and initiate a paper simulation to identify the problem before your ‘chicken is entirely cooked.’ Chances are that someone in the development team either didn’t ‘get the memo’ as it were, or more importantly, didn’t think to consider the impact of a small but important ingredient necessary to the entire meal.