Los mandamientos del desarrollo de software


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.

9 comments

Jaja! Me he identificado en muchas partes, pero la ultima de los cronogramas es muy cierta, casi es parte de la "Metodologia" sumar 2 meses o el 25% mas del tiempo "Por si acaso".

Sobre el punto 3... Realmente alguien cambia de DBMS?? Yo creo que un ejemplo mas claro es ver aplicaciones extremadamente parametricas o extremadamente eficientes. Asi como aplicaciones con codigo muy legible o codigo optimo.

Y bueno sobre el punto 2, tienes razon, es divertido, pero no necesariamente productivo... Depende mucho de la nueva moda, digo.. Tecnologia... Creo que en TI tenemos mas cambios de modas que las mujeres y sus vestidos de estacion...

Y finalmente sobre el punto uno, he visto programadores y programadores, y totalmente de acuerdo... Hay programadores que se tardan, y los que sencillamente lo hacen (Pero mal...), contra un programador que es capaz de pensar y luego de cinco minutos verlo jugando antes de comenzar sus pruebas unitarias.

Excelente Articulo!

Reply

Hola Mortal!! Gracias por el feedback. Si pues... cambiar de DBMS es algo bastante remoto, pero la idea de estar amarrado a un producto no me es cómoda: personalmente, prefiero tener la lógica de negocio en la aplicación (aunque a todo el mundo parecen gustarle los benditos procedimientos almacenados :@)

Reply

Estar amarrado a algo, creo que es algo inherente a todo desarrollo, digo yo, desarrollar en un lenguaje determinado te puede de por si amarrar a cierta tecnología, sea un sistema operativo, un servidor de aplicaciones, un framework, etc etc etc...

Lo que se puede hacer (Y esto va de manos de nosotros analistas) es siempre tener un nivel de acoplamiento y puntos de interface claros y de preferencia standart. Ademas de tener claro el concepto de modularidad. Para asi hacer las migraciones menos dolorosas... Para poder mover las "Cajitas" o reemplazarlas de manera limpia...

Pero bueno, entre una colonoscopia con o sin anestecia siempre quedara una sensacion incomoda al final. no?

Reply
Este blog ha sido eliminado por un administrador de blog.

Me impactó esta frase: no se debe escatimar en los salarios de los programadores buenos, dado que siempre producen más de lo esperado

Muy bueno, ojalá lo lean en mi empresa

Saludos

Reply

Aunque parece bastante obvio... creo que la gente de Recursos Humanos no lo tiene claro xD. Gracias por la visita!

Reply
Este blog ha sido eliminado por un administrador de blog.

Hola Mortal!, sinceramente ES-PEC-TA-CU-LAR todo lo dicho y comentando en este post. Trabajo en una empresa de desarrollo de software donde suceden "todas y cada una" de las cosas expresadas aquí. La frase "no se debe escatimar en los salarios de los programadores buenos, dado que siempre producen más de lo esperado" tendría que pasar a ser una frase "célebre"...

Reply

Gracias por la visita Anónimo! Y se agradecen también los comentarios. El artículo original me pareció esclarecedor, te recomiendo que lo revises.

Saludos!

Reply

Publicar un comentario