Buceando en la web me topé con el artículo "Frequently Forgottenn Fundamental Facts about Software Engineering" de Robert L. Glass, en las que el autor enumera los que él considera los "teoremas" básicos a tener en cuenta al momento de construir software, y que lamentablemente parece que nadie considera. El listado que menciona lo realizó en base a su experiencia profesional y muchas de los principios que menciona han sido violentados en mi compañía, y a veces por mi persona. Paso a enumerar los que me llamaron la atención, junto a unos apuntes de mi parte:
- Los buenos programadores son por lo general 30 veces mejores que los programadores mediocres. Dado esto, no se debe escatimar en los salarios de los programadores buenos, dado que siempre producen más de lo esperado
En una compañía en la que estuve, empezaron a reemplazar Analistas Programadores (gente con experiencia) por practicantes (novatos o "trainees"), bajo la excusa de reducir costos y aumentar la productividad -más programadores con menos presupuesto-. Lógicamente, un practicante demoraba 2 semanas en hacer lo que un AP podía hacer en un día, así que no creo que les haya resultado beneficioso.
- El uso de una nueva herramienta o técnica reduce la productividad de los programadores y la calidad del producto inicialmente. Se obtienen beneficios una vez superada la curva de aprendizaje.
El arquitecto de donde trabajo es bastante "creativo", y constantemente incluye nuevas tecnologías en las aplicaciones que desarrollamos. El documentarnos sobre la tecnología nos toma como una semana, y cuando nos ponemos a desarrollar definitivamente lo hacemos más lento que con tecnologías más familiares. Pero ver cosas nuevas siempre es divertido xD.
- El mejorar un atributo de calidad generalmente perjudica a otro atributo de calidad. Por ejemplo, el mejorar la eficiencia perjudica la flexibilidad a cambios de la aplicación.
Se me viene a la mente el uso de procedimientos almacenados en base de datos: disminuyen el tiempo de respuesta pero te hacen imposible el cambiar de DBMS. Como dicen por ahí, nada es gratis en la vida.
- La detección y solución de errores representan el 40% de los costos de desarrollo. Por eso es una de las fases más importantes del ciclo de vida del desarrollo.
Yo me arriesgaría a decir que hasta el 50% de los costos.
- De un software -que según un programador promedio ha sido exhaustivamente probado- sólamente se han ejecutado el 55%-60% de sus rutas lógicas. El soporte automático, como analizadores de cobertura, puede elevar este número a 85%-90%. Las pruebas al 100% son imposibles.
Es por esto que el personal de control de calidad no nos cae nada bien. Siempre salen con casos que uno nunca pensaba que se iban dar, y que generan un nada discreto mensaje de error. Aunque como se dice por acá, es mejor que lo vea un tester a que lo vea el usuario xD.
- El software siempre contiene defectos residuales, aún después del proceso de eliminación de errores más riguroso. El objetivo es minimizarlos en número y en severidad.
Y sobre todo, que aparezcan después que se haya terminado la garantía xD.
- Las mayoría de las tareas de desarrollo de software y de mantenimiento de software son las mismas- excepto por la tarea de mantenimiento adicional "Comprender el producto existente". Esta tarea es de suma importancia, y consume casi el 30% del tiempo de mantenimiento. Por esto, se puede decir que el mantenimiento es más difícil que el desarrollo de software.
Bastante cierto... no hay nada más difícil de entender que el código ajeno. Lo digo con conocimiento de causa, que sufrí 1 año dando mantenimiento a aplicaciones que parecían hechas por chimpancés.
- Cuando un proyecto pasa de requerimientos a diseño, la complejidad del proceso de solución produce una exploción de "requerimientos derivados". La lista de requerimientos de la fase de diseño es por lo general 50 veces mayor que la lista de requerimientos original.
Nos pasa todos los días, y ocasiona amanecidas y/o retrasos.
- La mayoría de estimaciones de software se desarrollan al inicio del ciclo de vida. Es decir, ocurren antes de la fase de requerimientos y por ende antes de comprender el problema. La estimación por lo general ocurre en el tiempo inapropiado.
Es por esto que los cronogramas de desarrollo son las artefactos más desatendidos e ignorados que conozco. Los hacen por protocolo, pero a la larga nadie los sigue (al menos en mi compañía). Tal vez cronogramas por iteración, como señala RUP, serían la solución.
Esos son los que me parecen más importantes, y creo que si los jefes de proyecto los leyeran nuestros días serían más llevaderos. A ver que opinan ustedes.
Entradas
