jueves, 17 de abril de 2014

¿Cuántos empleados de Microsoft hacen falta para cambiar una bombilla?

A raíz del anterior artículo acerca de códecs libres de patentes quise consultar la compatibilidad del irrelevante Windows Phone con estos códecs. En mitad de la búsqueda di con un artículo de un blog en la MSDN (Microsoft Developer Network). Un análisis bastante bien aproximado acerca de la cadena de eventos que se activa ante cualquier mínimo cambio que haya que realizar, en este caso añadir una función llamada ChangeLightBulbWindowHandleEx a la biblioteca estándar de VBScript. Veamos los sobrecostes que tiene a día de hoy una empresa como Microsoft con sus 100.000 empleados repartidos alrededor del mundo.

Cualquier modificación en el comportamiento de un producto sigue un proceso determinado antes de salir al mercado. En línea de lo que comentaba en la entrada de Android KitKat para el Galaxy S2, toda modificación ha de pasar por la QA (Quality Assurance).
Así pues, ¿qué hace falta para añadir una mísera función que seguramente sólo sean 5 líneas de código?, pues bastantes cosas:
  • Un desarrollador que emplee 5 minutos de su tiempo implementando ChangeLightBulbWindowHandleEx.
  • Un gestor de programa (program manager) para escribir la especificación.
  • Un experto en traducción para revisar la especificación en busca de problemas para traducir.
  • Un experto en usabilidad para revisar la especificación en busca de problemas de usabilidad y accesibilidad.
  • Al menos un desarrollador, un probador (tester) y gestor de programa para una lluvia de ideas (brainstorm) de vulnerabilidades de seguridad.
  • Un gestor de programa para añadir el modelo de seguridad a la especificación.
  • Un probador para escribir el plan de pruebas.
  • Un probador jefe para actualizar el calendario de pruebas.
  • Un probador para escribir casos de prueba y añadirlos al sistema automático de pruebas nocturno.
  • Tres o cuatro probadores para participar en una bug hash a propósito del cambio (alguna especie de reunión creativa en busca de fallos).
  • Un escritor técnico para escribir la documentación.
  • Un analista técnico para verificar la documentación.
  • Un editor de copias para verificar la documentación.
  • Un gestor de documentación (documentation manager) para integrar la nueva documentación en el texto existente, actualizar tablas de contenidos, índices, etc.
  • 25 traductores para traducir la documentación y mensajes de error a todos los lenguajes soportados por Windows. Los gestores (managers) de los traductores viven en Irlanda y Japón (idiomas europeos y asiáticos) y tienen un gran desfase horario con respecto a la central de Microsoft en Redmond por lo que contactar con ellos tiene sus problemas.
  • Un equipo de seniors para coordinar toda esta gente, escribir los cheques y justificar los costes a su vicepresidente.
Todo eso para añadir una simple función que haga una cosita de nada. Puedes preguntarte entonces qué pasaría si en la funcionalidad añadida hubieran bugs: más semanas de trabajo y más costes. El autor de la entrada de dicho blog en la MSDN pone como ejemplo de hasta donde pueden llegar los costes de desarrollar software el caso de que tiene que asegurarse incluso de que un español catalanoparlante y legalmente ciego pueda usar la nueva funcionalidad sin introducir nuevas vulnerabilidades de seguridad.
Cuando se publica una nueva versión de algo varios cientos de millones de personas lo usarán.
Así pues, en el caso de Microsoft y su posiblemente sobredimensionada estructura burocrática añadir cualquier cambio supone unos grandes costes burocráticos por lo que no es de extrañar que aglutinen cambios todo lo que puedan o sólo se dediquen dichos recursos a las cosas más urgentes: cualquier cambio por mínimo que sea requiere de recursos corrección de errores, buscar fallos de seguridad, traducir, etcétera por lo que si el cambio no afecta a un gran porcentaje de la base de usuarios ni se molestan en hacerlo.

En el caso del software libre dichos costes están distribuidos dinámicamente en función de las necesidades de los clientes de dicho software. Por ejemplo en el caso del núcleo Linux tenemos el Linux de kernel.org y de ahí toda compañía o distribución de software que quiera tener a Linux como núcleo se lo descarga y adapta y mantiene a sus necesidades. Luego gracias al código GPL dichos cambios están disponibles por lo que pueden contribuir al código original con muchos más casos de usos y pruebas y descubrimiento de vulnerabilidades. Linux está cada día puesto a prueba en millones de servidores accesibles desde Internet, también lo está todo el software por encima del núcleo como OpenSSL que no sólo se usa en distribuciones GNU sino también en Windows. Además, para esas modificaciones no necesitas hacerte con el Visual Studio y demás. Cualquier añadido o modificación del software libre es mucho más accesible.

Los comentarios del blog no ven al software libre como una solución de dicho problema sino como una visión desde otro punto de vista. De esa entrada hace ya más de 10 años.

No hay comentarios:

Publicar un comentario en la entrada