¡El código no probado no funciona!

Esta historia es una versión editada de un mensaje que recientemente publiqué en el foro de Multics en LinkedIn.

Hacer que tus cambios "salgan al aire" muy rápidamente puede ser un poderoso incentivo. Esta es la historia del primer error que introduje en Multics, que era un importante sistema operativo que se estaba creando en el MIT a finales de los 60 y principios de los 70.

Yo era un joven estudiante de primer año del MIT que había sido aceptado en el proyecto Multics. Me ofrecí a añadir una función al comando dprint ("daemon print") que ponía en cola las peticiones para que el demonio de la impresora de línea las procesara. Uno de los gerentes me pidió que registrara el número de copias en la solicitud, en lugar de añadir N solicitudes a la cola. Este cambio resolvería una condición de carrera que implicaba el borrado de solicitudes de impresión completadas. Hice los cambios y los probé a mi satisfacción.

Mis cambios se instalaron pronto y estaba encantado de que me permitieran mejorar el sistema. Pero mi emoción duró poco, ya que pronto contesté el teléfono de mi oficina y me encontré escuchando a un usuario furioso que se quejaba de que yo había roto su programa. Volví y vi que no había notado, o probado, el punto de entrada de la subrutina en el mismo archivo fuente. Por supuesto, lo había roto. Lo arreglé y la vida continuó. Pero nunca he olvidado esa llamada telefónica. Todavía no soy perfecto, pero esa voz furiosa que resuena en mi cabeza me ha salvado de cometer muchos errores similares y descuidados a lo largo de los años.

El aforismo que acuñé de este caso es "El código no probado no funciona".

Pruebe su código. Encuentra tus propios bichos; no hagas que otros los encuentren. Evita la voz furiosa!