Feeds

Of software bugs and learning curves

Testing as learning

Secure remote control for conventional and virtual desktops

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.

kevlin henney headshot

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.

The essential guide to IT transformation

Next page: Design Education

More from The Register

next story
Microsoft boots 1,500 dodgy apps from the Windows Store
DEVELOPERS! DEVELOPERS! DEVELOPERS! Naughty, misleading developers!
'Stop dissing Google or quit': OK, I quit, says Code Club co-founder
And now a message from our sponsors: 'STFU or else'
Apple promises to lift Curse of the Drained iPhone 5 Battery
Have you tried turning it off and...? Never mind, here's a replacement
Uber, Lyft and cutting corners: The true face of the Sharing Economy
Casual labour and tired ideas = not really web-tastic
Mozilla's 'Tiles' ads debut in new Firefox nightlies
You can try turning them off and on again
Linux turns 23 and Linus Torvalds celebrates as only he can
No, not with swearing, but by controlling the release cycle
prev story

Whitepapers

5 things you didn’t know about cloud backup
IT departments are embracing cloud backup, but there’s a lot you need to know before choosing a service provider. Learn all the critical things you need to know.
Implementing global e-invoicing with guaranteed legal certainty
Explaining the role local tax compliance plays in successful supply chain management and e-business and how leading global brands are addressing this.
Backing up Big Data
Solving backup challenges and “protect everything from everywhere,” as we move into the era of big data management and the adoption of BYOD.
Consolidation: The Foundation for IT Business Transformation
In this whitepaper learn how effective consolidation of IT and business resources can enable multiple, meaningful business benefits.
High Performance for All
While HPC is not new, it has traditionally been seen as a specialist area – is it now geared up to meet more mainstream requirements?