La idea es sencilla y lógica desde el punto de vista de negocio: Si tardamos menos en el desarrollo de un proyecto: Minorizaremos recursos, recortaremos gastos y adelantaremos resultados.
Esta presión se propaga desde arriba, hasta los niveles más bajos en el desarrollo:
La programación de los requisitos.
En consecuencia: Se codifica y se construye, dedicándole menos importancia al análisis previo, a una programación correcta, clara y fácil de mantener. Reflejando un código complejo y poco entendible.
La calidad y el tiempo: Nuestro interminable balanceo, que siempre debemos equilibrar.
Antes de justificar la poca calidad en nuestros desarrollos a consecuencia del tiempo: Equilibremos y razonemos conclusiones.
Nunca sacrificar el tiempo de análisis previo al desarrollo. Más de la mitad del tiempo asignado, debe emplearse en él:
Primero resuelve el problema. Entonces, escribe el código. John Johnson.
Una de las prioridades debe ser la transformación de lo complejo a lo simple:
La simplicidad llevada al extremo se convierte en elegancia. Jon Franklin.
¿Cómo?: Utilizando nuestro conocimiento e imaginación:
La imaginación es más importante que el conocimiento. El conocimiento es limitado, mientras que la imaginación no. Albert Einstein.
En cualquier caso: Sugiriendo métodos, ideas, propuestas, técnicas y metodologías que simplifiquen y se ajusten a la estructura global del proyecto.
Es más fácil cambiar las especificaciones para que encajen con el software que hacerlo al revés. Alan Perlis.
Escribiendo buen código, ahorraremos el tiempo que empleamos escribiendo comentarios:
El buen código es su mejor documentación. Cuando vayas a escribir un comentario, pregúntate, ¿cómo puedo mejorar el código para que este comentario no sea necesario?. Steve McConnell.
Ante análisis y contratiempos, ahorremos tiempo: Evitemos distracciones.
Sigamos nuestro instinto profesional y alimentémonos de aquellas ideas de quienes han demostrado alguna vez que pueden y saben ayudar. Evita seguir las ideas de aquellos que prefieren concentrar y transformar su calidad, en labia. Responsabílizate y actúa.
No tengas buenas ideas si no estás dispuesto a responsabilizarte de las mismas. Perlis.
Aún haciendo todo lo posible por priorizar y mantener una calidad óptima: Ocasionalmente debemos sacrificarla para llegar a las fechas. Especifica y comenta la causa por la que estas obligado a escribir ciertas líneas de código. Quizás en otro momento, tú u otro compañero de equipo, con más tiempo, puedan eliminarlas estableciendo una solución de calidad.
La presión contínua tras el paso del tiempo, provoca la acumulación de dichas líneas de código. Originando a su vez la creciente acumulación de incidencias.
En esos casos, debe valorarse el refactoring, eliminando todas las líneas innecesarias y/o con alto margen de error. No cometas el error de continuar aplicando líneas correctivas sobre líneas de baja calidad:
Cuando se está depurando, el programador novato introduce código correctivo; el experto elimina el código defectuoso. Richard Pattis.
Ajustando el tiempo de desarrollo obtendremos antes los beneficios y resultados.
Aunque a lo largo del tiempo, deben aceptarse los costes de tiempo y recursos para la re-solución de problemas y refactoring que ha provocado el desarrollo acelerado y de poca calidad. Pudiéndolos haber utilizado en otros nuevos proyectos y/o mejoras.
Cualquiera puede escribir código que un ordenador pueda entender. Los buenos programadores son aquellos que escriben código que los humanos puedan entender. Martin Fowler.
Quizá Martin Fowler, en su cita, debió tener en cuenta dicha presión: Los buenos programadores son aquellos que escriben código que los humanos puedan entender, independientemente de la presión que se les ejerza.
En la medida de lo posible: Mejora la calidad de vida de tus proyectos.