En algunas ocasiones nos encontramos con clientes que están atados de pies y manos por su proveedor de software. Usan un software que es sistémico para la empresa pero no están contentos con el mantenimiento que el proveedor realiza, los tiempos medios para la corrección de errores y lo tarde y mal que entrega nuevas características del programa. A veces el servicio no es del todo malo pero sí caro pero no pueden pedir ofertas a otros proveedores y estimular la competencia porque ellos son los únicos que conocen el software o quienes tienen contratados a los expertos en esa solución.

Se les suele pedir a estos proveedores que continuamente documenten todo lo que hacen para así asegurarse un traspaso tranquilo y cómodo a otro proveedor si se diera el caso. La empresa probablemente asegure que sí, que todo está bien documentado y esto da cierta tranquilidad al cliente pero ¿pueden estar tranquilos con esta afirmación? ¿basta con documentar el código para evitar la dependencia de proveedores? Probablemente no.

En la empresa proveedora cada vez que llega una nueva andanada de peticiones de documentación, ésta se vuelve como loca a producir documentos pero pueden pasar estas cosas:

  • El proveedor puede ser reticente a documentar las partes más sensibles de su código porque contenga las claves que permitan que su trabaje se copie a otras soluciones.
  • Puede que al proveedor no le interese documentar bien el código para mantener su situación de vendor lock-in (dependencia del proveedor) y que el cliente tenga unos costes inasumibles si intenta cambiar de proveedor.
  • Se producen documentos como si los pagaran al peso pero su principal objetivo no es el de clarificar qué se ha hecho en el código sino poder facturar documentos, enseñarle papeles a un auditor o justificar el trabajo.
  • La documentación no está actualizada porque a medida que se han ido haciendo más y más cambios nadie ha ido actualizando cada diagrama y cada nota de unos documentos que cada mes que pasa se hacen más viejos. Documentar y mantener actualizada una documentación es un trabajo muy costoso que consume mucho tiempo y recursos.
  • La calidad del código es mala y algunas partes del código sólo son entendibles por la persona que lo hizo haciendo muy difícil que nadie pueda escribir un documento que los describa.
¿Podemos quedarnos tranquilos con nuestro código ya documentado? ¿Qué podemos hacer si ya sabemos que documentar no es suficiente?
  • Asegurarte que se usan buenos estándares de programación para que el código sea claro y fácilmente entendible por cualquiera que lo retome.
  • Procurar que todas las personas trabajen en todas las partes y módulos del código (Collective Ownership) evitando que quede en manos de unas pocas personas todo el conocimiento de algunas áreas del código.
  • Seguir el principio KISS (Keep It Simple Stupid) evitando diseños y soluciones demasiado complejas de entender. Ya se sabe que ‘lo bueno, si sencillo, dos veces bueno‘.
  • Utilizar un buen sistema de control de versiones que te permita mantener la propiedad y el control de todo el código de forma que sea fácilmente transmitible a cualquier nuevo proveedor que llegue con sólo pasarle una url y un usuario y contraseña.
  • Usar APIs de Servicios Web y estándares XML o JSON de forma que puedas extender tu aplicación con las mínimas interferencias con el resto del código de tu producto.
  • Tecnologías como Docker te permitirán aislar tu código del entorno hardware donde están para controlarlo tu mismo evitando hacer peticiones a la empresa que controla el hardware y middleware donde está desplegado tu aplicación.
  • Herramientas de gestión de la configuración como Chef y Puppet te ayudarán a automatizar la configuración de la infraestructura en la que tu software se ejecuta simplificandola drásticamente.

Referencias: