Of software bugs and learning curves

Shaker Loops

Successful design is inevitably incremental, although some steps might be larger than others. It inevitably involves acceptance of change, and therefore renewal and removal, rather than the obstruction of change. Of course, just to be clear, acceptance of change is not the same as an absence of stability. And, to take us back to where we started, successful design does not rely on software defects as its primary source of feedback.

Design is both a feedforward and a feedback process, which makes it a dialogue: between people; between people and the design; between people and the results of the design. This is where learning fits in. So there is a need to shorten long feedback loops, but there is also a need to increase signal to noise ratio by reducing interference — continuous unregulated feedback is noisy rather than helpful.

To take an example people often associate with the issue of bugs, consider the role of testing in software development. Is testing, as is often articulated, concerned only with the discovery of defects in software as built? Is testing, as is sometimes assumed, the sole preserve of a testing department and individuals with "tester" in their job title? Is testing, as expressed in many traditional development processes, something that necessarily falls in the closing phases of the lifecycle after all the "development" has been done?

If testing is divorced from other activities in software development and placed towards the end of the development lifecycle, carried out only by individuals who were not involved in the design of the system, its main contribution to the software is pretty much limited to one thing: defect reports. This is certainly better than nothing (and certainly better than many companies manage), but it represents a wasted opportunity for learning and a poor distribution of responsibilities, schedule and money. In such lifecycles testing is consigned to play a passive rather than active role, a role that cannot influence the framing of requirements, the design decisions, the coding guidelines or the team and its individuals until after the fact. If there is any genuine learning, it will typically be localised and lost or, at best, deferred to the next project.

As I said, a wasted opportunity. It is generally considered wiser to close the stable door before the horses bolt. Testing offers a form of empirical feedback that can be used to drive design, clarifying requirements and providing a health check for code.

Running testing along the main axis of software development and across more than one development role shakes up the pipeline model of traditional development processes. It closes many of the open feedback loops and shortens many of the others, while at the same time ensuring that the signal is stronger than the noise. Instead of treating testing as a critical passenger, shoved into the backseat, it becomes an informative driver. Testing ceases merely to be a synonym for bug hunting and becomes a proactive form of learning. ®

This article originally appeared in Application Development Advisor.

Kevlin Henney is an independent software development consultant and trainer. He can be reached at http://www.curbralan.com