Of software bugs and learning curves

Column A bug is no more and no less than a software defect. However, the less harsh and less direct name "bug" masks the nature of the beast and helps to ease the conscience of programmers and the organisations around them. The term also helps play down the frustrations of software users, to the point that defects have become accepted as a normal and reasonable state of affairs. The word has left its jargon origins and joined mainstream English.

OK, so now we know what a bug is, what is it worth? In practice, a bug has negative value: it uses up goodwill, it costs money and time to discover it and uncover its modus operandi, and it takes time and concentration away from whatever else we were doing.

However, in principle, a bug also offers us a learning experience. There is the potential for something positive to come from it. We learn about a particular usage or situation we had previously overlooked, we learn more about a requirement that was poorly articulated or tacitly assumed, we learn that a piece of code we assumed to be correct was subtly problematic or obviously wrong — deeply and systemically or because of a simple thinko or typo — and we learn how to fix it. We learn that there might be an opportunity for us to change our habits and choice of practices to reduce the likelihood of such defects occurring again in future.

With the exception of the last learning point, all of these are the direct and immediate lessons we take from bug reports. They are fairly local in their effect and often we look no further. But the last point is the meta-lesson that could really add the most value. A development model that emphasises debugging after the fact, over practices that reduce enbugging in the first place, has its priorities back to front and represents a failure of learning.

Learning to develop software

The idea of learning having a central position in software development is more than a metaphor, it identifies one dominant aspect of the software development process. Pundits are often happy to brand software developers as knowledge workers. One image this inspires is of knowledge as some kind of artefact or workpiece with the software developer as the artisan standing over it, crafting it with all manner of knowledge lathes and conceptual hammers. However, knowledge is not physical enough to support such a metaphor. It cannot simply be shipped and shaped as iron or wood.

The acquisition and presentation of knowledge is all part of the established topic of learning. Learning involves accumulation, consolidation, exploration, articulation and feedback, all of which can be seen in effective software development processes. The emphasis on an iterative and incremental approach is something that distinguishes agile development processes from more bureaucratic and master-planned processes. A cyclic and cumulative approach reflects a learning process.

When "learning" is normally mentioned in the context of software development, it is assumed to refer to development skills. This is the gap filled and fulfilled by books, training courses, and so on. But more generally, learning and the expression of the knowledge acquired defines the axis along which software development runs: what we learn is embodied and revealed in the code behind the software.

For example, there is learning about the domain in which a piece of software runs or is to run, and the specific needs that define the scope and purpose of the software and any changes to it. This responsibility is not only restricted to someone with the title "analyst". It applies to all those who are involved in formulating the software, including the party for whom the software is intended. A common criticism of software customers is that they do not know what they want even though they know they want it. It is easier to reason about this perception from the perspective of learning. Unless there is a process that encourages learning on all sides, how else is the knowledge going to emerge clearly? Miracles and master plans? Feedback obviously plays a significant role in all this, and shortening long feedback loops is one of the optimisations that can make any approach more effective.