From plastic ducks to IT audits: why clarity is the most underrated skill in software engineering

Thousands of developers around the world debug their code by talking to a rubber duck. The technique has a name — rubber duck debugging — and it works remarkably well. But behind this smile-inducing anecdote lies a powerful cognitive mechanism that most organisations underuse: explicitation, that is, the act of clearly formulating, aloud or in writing, what one believes to be true. When practised at an individual level, this mechanism allows a developer to track down a bug in minutes. When practised at project level, it can prevent months of drift and tens of thousands of euros in corrections.

This article explores that scaling journey: from the individual debugging technique to the analysis methodologies that structure business application projects. Along the way, we will see why the implicit is the leading cause of IT project failure in SMEs, and how a rigorous discipline of explicitation — at every level of your information system — represents a performance lever that few organisations fully exploit.

Rubber duck debugging: a serious technique behind the anecdote

The story has become famous within the developer community. In their seminal book The Pragmatic Programmer, Andrew Hunt and David Thomas recount the case of a developer who carried a rubber duck around and debugged his code by explaining his reasoning to it, line by line. The idea is disarmingly simple: when you are stuck on a bug, pick up any object — a duck, a mug, a patient colleague — and explain exactly what your code is supposed to do, step by step. In a surprisingly high proportion of cases, the mere act of verbalising reveals the error before you have even finished the explanation.

Why does it work? Because when developers read their own code, they do so in recognition mode. Their brain automatically fills in the gaps, skips over the obvious, and reconstructs a coherence that sometimes exists only in their head. This is a well-documented cognitive bias: we see what we expect to see, not what is actually written. Verbalisation breaks this cycle. It forces a shift in mental register — from “I know what my code does” to “can I demonstrate what my code does to someone who knows nothing”. And it is in this gap between the two modes that bugs reveal themselves.

What is remarkable is that the technical level of the listener is completely irrelevant. The duck understands nothing, and that is precisely why it works. It is not the exchange that produces the discovery; it is the effort of explicitation itself. The developer who says “here, I iterate through the entire list” and realises while saying it that they actually stop one element too early receives no outside help. They have simply made explicit what had remained implicit in their reasoning.

This mechanism is directly linked to what is known as clean code mastery. Readable, well-structured code is code that has, in a sense, already been “explained to the duck” beforehand. Explicit variable naming, clear functions, inline documentation — all of these follow the same principle: making visible and verifiable what the developer had in mind at the time of writing. Clean code is preventive explicitation.

The implicit: the silent saboteur of IT projects

If a lone developer needs a rubber duck to flush out their own hidden assumptions in a few dozen lines of code, it is worth asking what happens at the scale of a project involving a project sponsor, one or more project managers, a development team and end users. The answer is straightforward: the implicit multiplies at every human interface, and its effects compound exponentially.

Consider a common scenario. An SME director asks their service provider to “redo the CRM”. For them, it means automating sales tracking and integrating website data. For the project manager, it means migrating existing data and building new dashboards. For the developer, it means choosing a framework, designing a data model and developing interfaces. Everyone moves forward with their own understanding of “redo the CRM”, and for the first few weeks, everyone feels aligned. It is several months later, during the first user tests, that the divergences come to light. The cost of correction at that point bears no comparison with what a rigorous explicitation exercise would have cost at the outset.

This phenomenon affects several dimensions of a project. First, there is functional implicit: the business processes that “everyone knows” but nobody describes in quite the same way. A sales rep who says “I qualify a prospect” does not necessarily mean the same steps as their director or the technical team who must translate that process into features. This is why understanding business processes and their associated rules is a non-negotiable prerequisite before any line of code is written.

Then there is technical implicit: inherited architecture decisions that no one questions any longer because “it has always been that way”. A database schema that reflects the constraints of software replaced five years ago. An integration flow that works around a bug that was never fixed. These implicit decisions, accumulated over time, form the breeding ground of what is known as technical debt — and explicitation is the primary lever for reducing it.

Finally, there is human implicit, perhaps the most insidious of all. Resistance to change that is not openly expressed, fears of losing competence or control, unspoken political dynamics within teams. When a key user slows down a project for no apparent reason, it is rarely out of ill will. It is often because they lack the words — or the space — to articulate what concerns them. Reluctance in project management often masks a collective inability to verbalise the real issues, much like a stuck developer who “senses” there is a problem but cannot pinpoint it.

Explicitation as project methodology: from the duck to the consultancy

If the rubber duck is the artisanal version of explicitation, what a specialist consultancy does during the analysis phase is its industrial counterpart. The mechanism is the same: the client organisation is placed in a situation where it must explicitly formulate what usually remains implicit. But the tools and the rigour are of an entirely different order.

At Agerix, this discipline of explicitation begins well before the first line of code, with the feasibility study. This analysis, structured around four pillars — technical, economic, commercial, financial — works exactly like a rubber ducking session at project scale. We do not ask the client “what do you want?”, a question that invites vague, implicit-laden answers. We ask them to demonstrate, pillar by pillar, that their project stands up. And it is in this effort of demonstration that inconsistencies emerge, well before they turn into delays or cost overruns.

The parallel goes further. A developer talking to their duck intuitively adjusts the level of explanation to the complexity of the code being examined. A consultancy does the same, but in a formalised way. The Cynefin framework, which we use to qualify a project’s level of complexity, determines the type of explicitation required. A project in the “simple” domain requires standard process documentation. A “complicated” project calls for in-depth expert analysis. A “complex” project requires an exploratory approach where explicitation proceeds through successive iterations, each cycle revealing new dimensions of the problem.

To illustrate this concretely, consider a bespoke business application project for an SME. The director expresses an apparently clear need: “we need a tool to manage our quotes and orders”. During the analysis phase, by getting them to verbalise each step of their sales process — who is involved, at what point, with what data, according to what rules — we discover that the actual process is significantly more complex than the perceived one. There are undocumented exceptions, informal approvals, information flows running through parallel spreadsheets. Without this explicitation phase, the delivered application would have addressed the need as expressed, not the need as it actually exists. And the difference between the two is what separates a tool adopted by teams from one circumvented within the first week.

Embedding explicitation at every scale of your IS

The strength of the explicitation approach is that it applies consistently across four distinct scales of an information system. What changes is not the principles, but the tools and the level of formalisation.

At the individual code level, it is rubber duck debugging in its original form, complemented by peer code reviews and inline documentation. A developer who names a variable remainingAttempts rather than n is practising explicitation. A comment that explains the “why” behind a technical choice (not the “what”, which the code itself should convey) is an act of explicitation. Teams that embed these practices mechanically reduce the time it takes other developers to understand the code, which has a direct impact on maintenance costs.

At component or module level, explicitation takes the form of unit tests and API contracts. A well-written unit test is literally a formal explanation of what the component should do: given certain initial conditions, when a certain action occurs, then a certain result is expected. It is automated, verifiable rubber ducking. API contracts play the same role at system interfaces: they make each party’s expectations explicit, eliminating misunderstandings before they manifest in production.

At project level, explicitation is embodied in scoping and governance methodologies. The kick-off meeting is the moment when all stakeholders must verbalise their understanding of the project — and where divergences, if tracked methodically, can still be resolved at low cost. The RACI matrix makes explicit what everyone often assumes: who is responsible for what, who decides, who is consulted, who is informed. Without this formalisation, grey areas proliferate and become conflict zones.

At the information system level as a whole, explicitation translates into application mapping, technical debt audits and architecture documentation. An organisation that can clearly answer the question “how do your systems communicate with each other and why were they designed that way?” is an organisation that has mastery over its IS. Those that cannot answer — and there are many among SMEs — discover this lack of explicitation the day a component fails, a key service provider changes, or a new business requirement exposes the limits of an architecture that was never documented.

Explicitation is not a luxury — it is an investment

It would be tempting to view this discipline as an overhead, an additional effort in projects already constrained by deadlines and budgets. That is a perspective error. The cost of the implicit is very real, but it is diffuse and deferred, which makes it invisible in standard dashboards. It manifests as specifications that need reworking, features that must be rebuilt, extended user training because the tool does not match actual practices, and technical debt accumulated through undocumented decisions.

SMEs that invest in explicitation — whether by training their developers in clean code practices, structuring their analysis phases with a competent partner, or documenting their business processes before automating them — see measurable returns. Shorter acceptance testing phases, higher user adoption rates, reduced maintenance costs, and above all, the ability to evolve their tools without rebuilding everything at each iteration.

The rubber duck, ultimately, reminds us of something fundamental. Intellectual rigour in software engineering does not begin with a technology choice or a fashionable framework. It begins with a simple, almost humble act: clearly formulating what one believes to be true, and checking whether that formulation withstands scrutiny. Developers who practise rubber ducking do so instinctively. Organisations that institutionalise this principle at every scale of their information system are those that deliver controlled projects, on time, and that generate the expected value.

At Agerix, this is the role we take on for our clients. We are, in a sense, their rubber duck — a duck that asks the right questions, structures the answers, and turns the implicit into actionable specifications. Because in business application development, what has not been said always costs more than what was said too early.