Debugging triage for developer warfare

I’m no military man, but I could only think of battlefield warfare strategy when I read over a couple of testing and debugging stories this week. Approaching bugs and fixes with military precision to assess their impact in terms of their severity, could arguably lead to a more sensibly executed battle plan in the combat theatre could it not?

' Free Image Source: Wikimedia Commons

If triage is the concept of treating wounded soldiers with the most urgent wounds first, the carry this concept forward to the bug battlefield and solve the most pressing problems first.

As far as I understand it, triage also embodies the concept of ‘wounded beyond help’ where a victim is simply left to die. This element does not carry forward to software application development does it? Well, perhaps it does if we consider that certain application modules are so broken and/or incongruent that they should be discarded and killed off or rebuilt from scratch like the bionic man.

Vendors in this space such as Coverity prefer to talk about software “integrity” in the face of bugs, but they still use terms like ‘mitigate the business risk of software changes’ as they map defects introduced by changes as projects develops. Perhaps we are leading towards a time when ‘builds’ start to become referred to as ‘offensive strikes’ upon the main code repository?

Is this too much conceptualisation for you? OK, I’ll succumb to vendor-speak then if you wish, “The Coverity 5 unified defect management interface is the first to enable developers and management to review, prioritise and triage their C/C++, Java and C# defects in a single workflow, providing a single version of the truth for the state of integrity across the entire product portfolio.” Now I knew I got that triage concept from somewhere!