Igualmente, el pifiarle en las estimaciones, por la edad, el orgullo, la autoestima y la inexperiencia creo que es la base económica de muchas consultoras, dado que le hacen estimar a los desarrolladores, saben que estiman mal, y después los tienen corriendo vez tras vez para cumplir.
Además de las mencionadas, quisiera mencionar 2 extremos, que por ser comunes pasan a ser promedio.
1.- Minimizar lo serio de hacer las cosas “bien”.
Hacer las cosas a la manera “tutorial” para que anden. Lo que sucede es que los tutorials no son parte de una gran aplicación y muestran un punto sesgado. En una aplicación tenés un monton de elementos que tienen que balancearse como estructura para tener una unidad conceptual . Hay cosas que cuesta lo mismo hacerla bien que hacerla mal. Hay que hacerla bien de una.
2.- Poner demasiado interes en hacer las cosas bien
Por el otro lado estan los dogmaticos con sus “best practice”. La best practice esta definida en un momento, en una tecnologia, en una version, y en un universo que tiene otras n tecnologias. Es una solucion a problemas o una proyeccion a minimizar costos a futuro. Si el contexto cambia o la direccion del futuro no es el promedio es altamente que la Best Practice no tenga sentido. Por eso … la arquitectura es “un conjunto de decisiones” … no es “un conjunto de tecnologias o una estructura” Porque esas decisiones son hechas en un contexto. Entonces siempre habria que preguntarse si esas best practices son validas en ese contexto.
Ejemplo : La 3ra forma normal para las bases de datos es razonable para tipos de sistemas transaccionales, pero en tipos de sistema de consulta con expectativa de una respuesta inmediata no es conveniente, y mucho menos para poner un esquema de datos general al servicio de personas que no saben de sistemas. Por lo que hay otros esquemas tipo estrella mas convenientes. Pero aun asi hay que analizar el contexto lo que incluye el grupo humano que se hara cargo de esa aplicacion.
3.- Un ultimo punto que quiero mencionar es el “poner nombres”
El poner buenos nombres indica la comprension que tenemos del problema que estamos resolviendo. Eso facilita la comunicacion con el usuario final, el tomar los requerimientos, y la comprension del sistema por futuros equipos. Por otra parte no es lo mismo llamar a la misma cosa diferente en distintos lugares como llamar algo practicaMedica, practicaMedic pracMedica, o pm . El hacer eso logra que ciertas herramientas que pudieramos aplicar automaticamente requieran una revision manual
4.- Ser clever
Muchos programadores tienen el desafio de poner en un solo renglon 40 cosas, y muchos desarrolladores de lenguajes proveen esas facilidades a los programadores.
El hacer programas “clever” aumenta el ego de los desarrolladores. Cuando se le señala que el codigo no es facil de entender, lo unico que se hace es alimentar su ego y que profundice en hacer cosas inentendibles.
El modelo de negocio de hacer programas es que gente con cada vez menos expertise pueda tomar ownership de un proyecto. Por lo cual tal practica va en contra de ese objetivo. Y me parece una actitud mezquina dado que no va a haber suficientes programadores nunca. Por lo tanto no es una defensa de su puesto de trabajo, sino alimentar la sensacion de disfrute del flautista de Hamelin… que cuando yo me vaya nadie va a entender nada… de una forma injustificada dado que nadie quiere quedarse en un proyecto toda la vida.