Calidad interna contra calidada externa
Me estoy leyendo el Growing Object-Oriented Software y en los primeros capítulos hay un par de párrafos en los que se señala un concepto que siempre había tenido ahí y nunca había sabido explicar en el software. Es la calidad externa contra la calidad interna.
La calidad externa es un concepto sumamente intuitivo y que todo el mundo conoce. Un software tiene calidad externa si funciona correctamente, hace lo que se supone que tiene que hacer, es eficiente e incluso estéticamente bonito. Ese es el concepto clásico de calidad y el que seguro que conocen vuestros jefes y encargados del departamento de márketing. Es la calidad que puedes ver con el producto en las manos.
Pero como siempre queremos ir un poquito más allá y profundizar en el tema de la calidad y ahí aparece el concepto de calidad interna. La calidad interna es, grosso modo, la capacidad que tiene un software para cambiar, adaptarse a requisitos nuevos o desconocidos, a detectar errores en fases tempranas del desarrollo. Es una calidad que solo puedes medir con el código en la mano, con diagramas UML, con diseños de la base de datos…
Para mi ha sido un descubrimiento el encontrarme con los dos tipos de calidad diferenciados. Intuitivamente trabajamos con ellos pero no sabía explicarlo correctamente. Es mucho más fácil tenerlo separado en dos conceptos, especialmente, a la hora de hablar con personal no técnico. Sobre todo cuando intentas explicar los diversos tipos de test que escribes en tu sistema. Por ejemplo: un test end-to-end que ejecuta un flujo completo de la aplicación comprueba la calidad externa mientras que un test unitario comprueba calidad interna.
Se puede tener calidad interna sin calidad externa y viceversa lamentablemente lo que hace este concepto un poco esquivo para es personal no técnico. Principalmente porque la calidad interna es un concepto que no da valor por si mismo al producto. El caso es que nosotros, como personal técnico, debemos de preocuparnos por la calidad interna por un sencillo motivo. Siempre vienen a por más. Es raro el caso en que terminemos de construir un producto y no haya que cambiarlo hasta convertirlo en algo completamente distinto. Como decían en mi casa: “Al platu vendrás arbeyu, si nun ye de mozu será de vieyu”[1].
[1] : Arbeyu quiere decir guisante en asturiano. El resto se entiende de sobra
Ya te estaba echando de menos. Pues de esto tambien pensaba yo (por supuesto mi nivel es mas basico). Por aqui yo no me propongo escribir software porque mi jefe me va a exigir 3 informes URS, PRS y Design document. El primero basicamente decribe lo que el usuario va a querer. el segundo es el que plantea todos los problemas que crees que va a tener y toda la ciencia que va detras de ello. El tercero es el documento “vivo” en el que vas describiendo tu dise~no. Sin decir tiene que mas o menos se espera que este todo redactado bonito y preparado para que el que viene detras con leer los tres documentos sabra lo que has hecho. Asi que lo que hago es no programar y si programo pienso hacerlo en mi tiempo libre para ahorrame la parafernalia. Ya intentare hacerlo curioso. El problema que el cabron no me lo esta limitando al software: cada proyecto nuevo tengo que redactarlo. OJO! muy util hacerlo porque te deja las cosas claras pero si el proyecto es muy corto o muy flexible se puede ver como un verdadero co~nazo.
Maria me ha dicho que no debo contar tanto rollo. yo le digo que queria poner comentarios en los blogs de los amigos. a lo que maria se rio.
Joder que mal estás de lo tuyo.
El tema del punto justo en la burocracia es complicado. Cuando se exige una documentación para cada cosa es, normalmente, demasiado. Por ejemplo, ahora andamos en un proyecto en el que tenemos que escribir documentación semanal sobre lo que ha hecho cada uno de manera tan detallada que, normalmente, perdemos un día de trabajo. Es algo verdaderamente absurdo. El problema es encontrar el punto justo en el que gastas el menor tiempo posible documentando pero el exacto para el que llega detrás entienda perfectamente lo que hay. Es un arte.
La solucion esta en los formularios. Mas o menos es bastante estandar. Una especie de FAQ que que hay que rellenar.
La mierda es que mi jefe esta obsesionado con sharepoint. Vamos que lo que quiere es trabajar menos: tenemos que subirlo a una pagina donde pasa por un mini “peer review” con approve, not aprove, coments.
Lo bueno es que cabe la probablidad que el trabajo cada vez es menos: primero porque puedes hacerlo como un formulario FAQ segundo porque vas ganando experiencia sobre lo que poner para ahorrarte muchos feedback loops.
El tema de pasar las tareas por un “completed pending review” siempre parece una buena idea por varios motivos: inconscientemente hacemos un mejor trabajo sabiendo que otra persona lo va a ver y además facilitamos el intercambio de conocimiento dentro de la empresa.