Cómo pone Facebook el código en producción

Aunque no es un documento oficial de la compañía y en algunos casos se basa sólo en suposiciones o cosas que leyó/escuchó en alguna parte, me ha parecido interesante el documento How Facebook Ships Code. Cita citable:

Most engineers are capable of writing bug-free code. It’s just that they don’t have an incentive to do so at most companies. When there’s a QA department, it’s easy to just throw it over to them to find the errors

Promesas incumplidas de la seguridad

En Security engineering: broken promises Michal Zalewski comenta sobre los problemas que tienen las diversas aproximaciones a la seguridad informática y en qué han fallado.

Por un lado los métodos formales se enfrentan al problema de la dificultad de definir el comportamiento deseable para un sistema de tamaño suficientemente complejo; es difícil traducir los deseos en expresiones formales; es difícil analizar formalmente el comportamiento de los programas.

Por el otro, hablaríamos de algo más actual, el análisis de riesgos. Sus defectos: en un sistema interconectado las pérdidas no están aisladas, ni ligadas a un activo concreto; las predicciones estadísticas no nos informan de nuestros problemas concretos; la seguridad no es un sistema que pueda seguir el esquema de las empresas de seguros (no hay datos estadísticos suficientes para modelar los problemas y sus consecuencias monetarias).

Finalmente, la categorización tiene sus propios problemas y, hasta ahora, no ha aportado mucho orden ni claridad a la forma en que podemos enfrentarnos a los problemas.

Las pruebas y los programas

En Testing is not a substitute for thinking (binary search part 3) una entrada interesante: con las metodologías ligeras tan de moda en estos tiempos, a veces pensamos que basta con las pruebas (‘tests’) para estar seguros de que todo va bien. No diremos que las pruebas no son útiles ni necesarias, pero en algunos casos (casi siempre) hace falta algo más y el autor da estas razones:

  1. Las pruebas sólo pueden mostrar la presencia de fallos, no su ausencia
  2. Las pruebas pueden tener errores, igual que el código que se quiere probar
  3. Las pruebas aumentan la confianza, no la comprensión

Yo añadiría una cuarta (¿relacionada con la segunda y la primera?) y es que es bastante posible que a la hora de preparar las pruebas nos dejemos algo porque es difícil que seamos capaces de prever todos los casos de uso.

Ya lo comentábamos en Una base axiomática para el desarrollo de programas la teoría y la práctica han de ir de la mano (y muy cerquita de la experiencia).

Y, en la medida de lo posible, utilizar más herramientas: Fuzzing y cubrimiento de código.

Métodos formales en el desarrollo de software

Otro artículos sobre el tema del desarrollo utilizando métodos formales. Se trata de Formal Methods: Practice and Experience (pdf) y nos da un resumen del estado actual de la industria basado en encuestas y cuestionarios. Proporciona algunos datos que me gustará tener como referencia para el futuro. Para los descreídos, una muestra de que estas cosas se utilizan en algunos sitios.

Ya habíamos nombrado de pasada el desarrollo utilizando métodos formales en Una base axiomática para el desarrollo de programas.