Risposta breve:
Nella maggior parte dei casi, no. Non è raro che le persone utilizzino tecniche come il debug della papera di gomma in aziende o dipartimenti incentrati sul software. Se un'azienda è più incentrata sul business nella sua cultura, allora ci possono essere preoccupazioni da parte del management che non hanno familiarità con il metodo.
Risposta lunga:
La cultura di molti uffici moderni incentrati sul software permetterebbe una varietà di pratiche comuni (se strane, al mondo esterno) agli sviluppatori, come parlare con una papera di gomma. Tuttavia, se si lavora in un ambiente in cui la verbalizzazione del proprio processo con una papera di gomma sarebbe considerata una distrazione o un disappunto, ci sono altre alternative più silenziose che si potrebbero prendere in considerazione:
Comporre una lettera
. Sia tramite testo, scritto a mano, o diagrammati, comporre una nota come se si stesse spiegando il software a qualcun altro può essere utilizzato in un metodo simile al debug verbale della papera di gomma.
Chat Con un Bot (sicuro)
Se vi trovate a fare il debug in modo più efficace quando fate rimbalzare le idee su un'altra persona invece che su un oggetto inanimato, potete scaricare e costruire i numerosi bot di chat open-source disponibili.
Un esempio è il chatbot originale: Eliza , progettato per usare metodi di psicoterapia Rogeriana per conversare. Eliza viene fornito di serie in copie di Emacs, per chi lo usa preferisce come editor di testo. L'unica cosa da ricordare è l'uso di una chatbot sicura, se si hanno dubbi sulla fuga di segreti aziendali o commerciali.
Utilizza Strumenti non convenzionali
Se il tuo problema è che hai difficoltà ad affrontare il tuo problema da una nuova prospettiva per ottenere chiarezza sul problema e trovare una soluzione, allora esiste una varietà di tecniche simili per riformulare la tua prospettiva.
Un esempio è quello di utilizzare un prompt esterno di qualche tipo, come un mazzo di carte, un set di dadi storia, o un mazzo di tarocchi dove ogni carta ha un significato predefinito. Confrontando il vostro software con questi prompt vi costringe a fare dei parallelismi non convenzionali e a pensare ai problemi del vostro software in modi nuovi.
Un altro esempio è quello di tentare di disegnare il vostro software come una macchina fisica, per descrivere le relazioni tra i componenti. Così facendo potreste rendervi conto che il modo in cui volevate che il software funzionasse non è un passo fondamentale da qualche parte.
Il vantaggio dell'uso di tecniche di debug non convenzionali è che vi costringe a pensare in modo creativo e può aiutare a sbloccare il vostro processo quando vi trovate in un solco mentale. Il rovescio della medaglia è la facilità con cui si esce dal proprio obiettivo e ci si ritrova a passare più tempo a trovare parallelismi di quanto non si riesca a realizzare gli obiettivi di sviluppo.