Al inicio de una de las primeras clases de mi carrera en la universidad, un profesor nos comentó el origen del término «bug» y el correspondiente significado de «debuguear», literalmente como «desenbichar» (que a la luz de la explicación dada se entiende perfectamente). Así, por mucho tiempo pensé que el término tendría su origen en el terreno del desarrollo de software pero veo que en realidad esta idea existe desde hace más tiempo. Hoy, creo que la origen que se atribuye a Grace Hooper fue más bien un retruécano de ella a algo que seguramente era ya bien conocido en el mundo del hardware, como inicialmente se concebía a la computación.

Hoy, casi 20 años después de esa primera definición a la que fui expuesto, creo que el término e idea detrás de esto es más que conocido por la mayoría de las personas que están acostumbradas a hacer uso de aplicaciones en computadoras, equipos móviles, y todo aquello que cuente con algún elemento de automatización. Algo que a la altura de nuestra época ya resulta inconcebible pensar resulte desconocido para alguien que viva en alguna población que cuente con electricidad, internet y tenga medio económicos para hacerse de estos aparatos.

Lo gracioso del tema es que las empresas son ambivalentes al respecto del término. No quieren hablar de errores porque tienden a pensar que eso es hablar negativamente de lo que ellas producen y buscan hacer pasar carencias, fallas de diseño o descuidos de elaboración, por bugs. Pero, al mismo tiempo hablan de cero defectos de fabricación, incluyendo bugs y tratan de hablar de calidad total. Como fuere, lo cierto es que los bugs son una consecuencia inevitable de un nivel de complejidad mayor y es mejor reconocer su inevitabilidad que desconocerlo. Por ejemplo, en una de las páginas del soporte del navegador Brave se puede leer:

The software development process is often an arduous one. Large scale applications can contain millions of lines of code that need to work across multiple platforms as well as account for a nearly infinite number of possible conditions at runtime. Subsequently, software at this scale is rarely perfect and may not always behave as intended. We generally refer to flaws, errors, or otherwise unintended behavior as bugs.

Esta serie de entradas que he iniciado, las voy a dedicar a revisar muchos de estos problemas y sus causas.