Exploring possibilities surrounding Rubber duck debugging

This blog post explores some developmental possibilities surrounding "Rubber duck debugging", an analytical technique embraced by software developers to achieve actionable break-throughs while debugging their application.

---

Concept

Rubber duck debugging is an analytical method (often referred to as the analytical method later on) by which a software developer explains the workings of the software at hand to a rubber duck, in an attempt to gain insights and to potentially formalize a solution while doing so.

The explanation usually consists out of an interplay between how the software should work and how the software works.

---

Abstract

The how the software should work part can be described as an expectation, the how the software works as a revelation.

Such an understanding goes beyond mere analytical debugging of software but is the basis of what I consider, an analytical treadmill.

When it comes to rubber duck debugging, one is an active participant and responsible for attempting to assure that the expectation becomes the revelation. The desired eventual equilibrium between the two is one's goal. While one pursues this goal, one is bound to deal with intermediate expectations and revelations whereby the goal is the same. 

The analytical method concerns alignment whereby the revelation results in constraints being imposed on the expectation, which may or may not redefine it.

Constraint imposition also affects related (higher-level, intermediate, co-existing) expectations for which the degree to which it affects them is determined by the relatibility between said expectations and the constraint's characteristics.

---

Touching base and establishing a foundation

Now that we've abstracted a bit, let's touch base again with the core concept.

The analytical method is concerned with debugging, implying a software application already exists and that there's a problem, of any nature, presenting itself, in need of reparation. The analytical method is flexible, open-ended & freeform in nature. All the responsibility rests with the software developer as to how to fill in the blank space; with as guideline, to explain how the software (should) operate to an inanimate rubber duck.

One has many ways to utilize the analytical method and inherent to its application is that some form of structure will emerge as a result. This lack of structure imposed by the analytical method is liberating and allows for a lot of possibilities, yet it may also be a limiting factor in the sense that it may not be obvious how to tactfully utilize it.

The most solid foundation for exploring possibilities appears to be the notion that there may be value in providing structure to software developers when it comes to rubber duck debugging.

Considering the aforementioned, the focus from hereon out will be to explore the possibilities surrounding the creation of structure which results in effective knowledge acquisition and analysis (reflection) by the developer.

---

Exploring possibilities

On the topic of a data analyst's mindset, Cassie Kozyrkov refers to analytics as the pursuit of good questions & statistics as the pursuit of good answers. 

In order to rubber duck debug effectively, one is expected to both identify questions and answer them. Getting the questions right is imperative for increasing the likelihood of producing good answers.

Therefore, some possible areas of interest may be:

• to assist the developer and rubber duck in formulating questions
• to assist the developer in answering said questions effectively
• creating methodologies and/or frameworks to enable the above
• creating methodologies and/or frameworks to effectively retain contextual information scoped to a class, solution, project, business motives; parsed to information dense contextual representations for further use while ensuring data freshness and accuracy, as provided information may become stale as time progresses
• possible integration of existing documentation and codebase, if desirable by the developer or business
• creating low-tech questionnaires or high-tech generative pretrained transformer agents with precise characteristics to enable the aforementioned; e.g. inquisitive and informative
  
• pertaining to the aforementioned GPT agents, creating parallel or async prompt engineering methodologies and/or frameworks 
• giving priority to AI models which can be locally deployed, without uploading the aforementioned data to third parties
• using the stackoverflow offline library and ranking answers based on date and upvotes, shifting the weights of it, regardless of the AI model's knowledge of its contents
• ensuring the high-tech GPT agent is SOC-2 compliant and vetted, if local AI models are undesirable for developer or business
  
• beating Google's way of general purpose pattern matching when it comes to debugging, the future of search is boutique, after all
• ...
  

This article isn't too long, but should give you some inspiration in regards to rubber duck debugging with or without AI LLM's.

Let's connect, discuss & share.

Copyright 2023 - Benjamin Van Renterghem @ construct0.com