InsightaaS: Cutter Consortium is an IT advisory firm focused on software development and Agile project management. ATN likes to drop in on Cutter’s blog site periodically to sample its “opinions on and reactions to what’s happening in business technology,” and we generally get an opportunity to learn something new about the connection between business and software development management activities. Today’s featured post provides a good example: senior consultant Tom Grant looks at parallels between the worlds of software development and national security, identifying some practices from the latter that can inform activities in the former. For example, security professionals (‘spooks’ in the novels I read) “assume that the first report is wrong,” “don’t trust any single source of information,” and “continue challenging the reliability of information, instead of treating it as established fact.” This isn’t, as Grant observes, standard operating procedure for software requirements – but should it be? Grant believes that “software professionals treat the problem of information unreliability…by acting as though it doesn’t exist.” He goes on to list a half-dozen questions that can help to accurately connect requirements analysis with real business needs, and urges adoption of intelligence-based practices like developing multiple sources of information. Grant concludes by noting that “we know what happens when civilian and military decision-makers misuse intelligence. Why would {software developers] be immune to the same results?” It’s a question that may well invoke some ‘spooky’ reactions from requirements professionals…
Every historical era has its lessons, such as Don’t trust totalitarian dictators to respect diplomatic niceties, Avoid land wars in Asia, and You know what’s going to happen to Sean Bean in this movie. One of the lessons of the last decade is certainly Information is not intelligence. Unfortunately, many people who do software requirements, or depend on them to build and test software, have not seen the relevance of that maxim in their own work.
Requirements in software development serve much the same purpose as intelligence in national security: they are supposed to provide actionable, reliable insights. “Actionable” is largely a question of format, which software professionals can control directly. Older questions like, What is the Jesuitical distinction between a requirement and a specification?and newer questions like, What kind of words do we need to supplement the pictures that we’ve created in this wireframe? have the same purpose: make sure that the developer, tester, or some other species of technologist understands what action to take, based on the information provided. In a similar fashion, the US President’s daily intelligence briefing follows a format that its intended audience finds useful.
The reliability of the information is not under the complete control of software professionals. In fact, we should always assume that the information we have is, to some degree, unreliable. We can reduce the amount of unreliability, but it will never reach 100% certainty. People in the intelligence profession deal with this problem in a variety of ways. Here are a few examples…
Read the entire post on the Cutter Consortium blogsite: Link
