ABUG IS NO MORE AND NO LESS THAN A SOFTWARE

defect. However, the less harsh and less directname “bug” masks the nature of the beast and helpsto ease the conscience of programmers and the organ-isations around them. The term also helps playsdown the frustrations of software users, to the pointthat defects have become accepted as a normal andreasonable state of affairs. The word has left its jar-gon origins and joined mainstream English.

OK, so now we know what a bug is, what is itworth? In practice, a bug has negative value: it usesup good will; it costs money and time to discover itand uncover its modus operandi; it takes time andconcentration away from whatever else we weredoing.

However, in principle, a bug also offers us a learn-ing experience. There is the potential for some-thing positive to come from it: we learn about aparticular usage or situation we had previouslyoverlooked; we learn more about a requirementthat was poorly articulated or tacitly assumed; welearn that a piece of code we assumed to be cor-rect was subtly problematic or obviously wrong –deeply and systemically or because of a simplethinko or typo – and we learn how to fix it. We alsolearn that there might be an opportunity for us tochange our habits and choice of practices to reducethe likelihood of such defects occurring again infuture.

With the exception of the last learning point, allof these are the direct andimmediate lessons we takefrom bug reports. They arefairly local in their effectand often we look no fur-ther. But the last point is themeta-lesson that could real-ly add the most value. Adevelopment model thatemphasises debugging afterthe fact over practices thatreduce enbugging in the firstplace has its priorities back tofront and represents a failureof learning.

Learning to develop softwareThe idea of learning having a central position insoftware development is more than a metaphor: itidentifies one dominant aspect of the softwaredevelopment process. Pundits are often happy tobrand software developers as knowledge workers.One image this inspires is of knowledge as somekind of artefact or workpiece with the softwaredeveloper as the artisan standing over it, craftingit with all manner of knowledge lathes and con-ceptual hammers. However, knowledge is not phys-ical enough to support such a metaphor. It cannotsimply be shipped and shaped as iron or wood.

The acquisition and presentation of knowledgeis all part of the established topic of learning.Learning involves accumulation, consolidation,exploration, articulation and feedback, all of whichcan be seen in effective software developmentprocesses. The emphasis on an iterative and incre-mental approach is something that distinguishesagile development processes from more bureau-cratic and master-planned processes. A cyclic andcumulative approach reflects a learning process.

When “learning” is normally mentioned in thecontext of software development, it is assumed torefer to development skills. This is the gap filled andfulfilled by books, training courses and so on. Butmore generally learning and the expression of theknowledge acquired defines the axis along whichsoftware development runs: what we learn isembodied and revealed in the code behind thesoftware 1.

For example, there is learning about the domainin which a piece of software runs or is to run, andthe specific needs that define the scope and purposeof the software and any changes to it. This respon-sibility is not only restricted to someone with thetitle “analyst”; it applies to all those who areinvolved in formulating the software, includingthe party for whom the software is intended. Acommon criticism of software customers is thatthey do not know what they want even though theyknow they want it; it is easier to reason about thisperception from the perspective of learning. Unlessthere is a process that encourages learning on all

sides, how else is the knowledgegoing to emerge clearly? Mir-acles and master plans?Feedback obviously plays asignificant role in all this, andshortening long feedbackloops is one of the optimisa-tions that can make anyapproach more effective.

Design educationSoftware development is adesign-based activity. Somepeople assume that designmeans “drawings and docu-ments about the software, but

PROGRAMMERS’ WORKSHOP

48 WWW.APPDEVADVISOR.CO.UK

KEVLINHENNEY

Software development can be more of an educationthan you might first think. Kevlin Henney studieswhat there is to learn

Learning curve

not the software”. However, this is not a particularly useful oraccurate reflection of what design-based professions do. Designis about the creation and expression of structure, physical orvirtual, which fulfils a number of goals and satisfies a numberof constraints. It is a creative and intentional act with manymodes of expression and levels of detail.

Goals and constraints can be decomposed recursively fromthe highest-level of granularity into finer levels of detail. Require-ments exist at the application level with respect to its users,but requirements also exist locally in the way that one methoduses another 2. However, there is no simple sausage machine thatsuccessfully turns a handful of use cases captured in natural lan-guage into an effective running system. Design is involved ineverything from framing the requirements to demonstrating theeffectiveness of a running system.

Design embraces all the kinds of expression of structurefrom whiteboard sketches in ad hoc UML to lines of code inJava. This means that the view of code as no more than animplementation detail – and therefore one that is not a prop-er concern or activity of design – is one of those unhelpfulmyths that has dogged software development for too long,and yet fails to stand up to close scrutiny.

Code is a formal notation used to express structure and exe-cution in a virtual world – very little code, even that written insomething as metal hugging as assembler, can claim to bedescribing structures and execution in a strictly physical world.Code creates and inhabits a designed domain 3. A significantnumber of decisions that affect the final software are made atthe keyboard in a code editor. This is not necessarily always agood thing, but it is necessarily inevitable. Any sustainablyrealistic view of development needs to do more than justacknowledge this inevitability; it needs to take advantage of it.

To understand the inevitability, consider detail: all designactivities are in some way based on abstraction, but not allare or aim to be complete. A package diagram sketched out ona whiteboard may be accurate, but it does not offer a com-plete view of what has been or is to be developed – if it did, itwould be unreadable and useless, defeating the very purposeof using such a sketch. By contrast, the definition of a wire-levelprotocol needs to be both accurate and precise for it to be of use– a sentence such as “...and the bits ought to be laid out insome order or other” is unlikely to be of much use. Code, in itsmany forms, is still abstract, but it demands a high level ofboth precision and accuracy. There is no cheating on the com-pleteness of the detail needed – the variation across various pro-gramming languages and infrastructures is with respect tothe amount of detail needed, not its completeness.

Of course, this is not to say that all designers are – or shouldbe – equally good at all kinds of design. Such a statementwould not be well supported by the facts. However, it doesindicate that design is a very broad church that cuts acrossmany different concepts and practices; successful designinvolves playing on and bridging these differences to besteffect.

Shaker loopsSuccessful design is inevitably incremental, although somesteps might be larger than others. It inevitably involves accept-ance of change, and therefore renewal and removal, ratherthan the obstruction of change. Of course, just to be clear,acceptance of change is not the same as an absence of stabil-

ity. And, to take us back to where we started, successful designdoes not rely on software defects as its primary source of feed-back.

Design is both a feedforward and a feedback process, whichmakes it a dialogue: between people; between people and thedesign; between people and the results of the design. This iswhere learning fits in. So there is a need to shorten long feed-back loops, but there is also a need to increase signal to noiseratio by reducing interference – continuous unregulated feed-back is noisy rather than helpful.

Active testingTo 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 ofdefects 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 tra-ditional development processes, something that necessarilyfalls in the closing phases of the lifecycle after all the “devel-opment” has been done?

If testing is divorced from other activities in software devel-opment and placed towards the end of the development life-cycle, carried out only by individuals who were not involved inthe design of the system, its main contribution to the softwareis pretty much limited to one thing: defect reports. This is cer-tainly better than nothing (and also better than many compa-nies manage) but it represents a wasted opportunity for learningand a poor distribution of responsibilities, schedule and money.In such lifecycles, testing is consigned to play a passive ratherthan active role, a role that cannot influence the framing ofrequirements, the design decisions, the coding guidelines or theteam and its individuals until after the fact. If there is anygenuine 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 consideredwiser to close the stable door before the horses bolt. Testingoffers a form of empirical feedback that can be used to drivedesign, clarifying requirements and providing a health checkfor code. Running testing along the main axis of softwaredevelopment and across more than one development roleshakes up the pipeline model of traditional developmentprocesses. It closes many of the open feedback loops andshortens many of the others, while at the same time ensuringthat the signal is stronger than the noise. Instead of treatingtesting as a critical passenger, shoved into the backseat, itbecomes an informative driver. Testing ceases merely to be asynonym for bug hunting and becomes a proactive form oflearning. ■

References1. Kevlin Henney, “Code versus Software”, artima.com,

August 2004, www.artima.com/weblogs/viewpost.jsp?thread=67178

2. Kevlin Henney, “Inside Requirements”, ApplicationDevelopment Advisor, May 2003.

3. Michael Jackson, Problem Frames, Addison-Wesley,2001.

Kevlin Henney is an independent software development con-sultant and trainer. He can be reached at www.curbralan.com

PROGRAMMERS’ WORKSHOP

MARCH-APRIL 2005 49