Buscar el 10 al construir software tiene sus riesgos

Yo sé que me voy a ganar algunos enemigos con este post pero ya llevo mucho tiempo con esta idea dándome vueltas en la cabeza y creo que ya es tiempo de que salga. Necesito escribiría o por lo menos empezar a enunciarla y escuchar opiniones por supuesto. :-)

En mi trabajo cotidiano es común encontrarme con excelentes desarrolladores, personas inteligentes, preparadas y experimentadas. Excelentes técnicos va. Pero que [muchas|algunas] veces caen en una pequeña confusión. Se enamoran de la programación en si misma perdiendo de vista el verdadero fin de la actividad que es crear software a un costo y en tiempos razonables que pueda usar el usuario.

No sostengo que buscar la excelencia sea algo malo, para nada. Está muy bien lograr un buen diseño, tener un buen modelo y trabajar con la mejor tecnología posible pero siempre teniendo en claro el contexto en el que nos movemos y las limitaciones que tiene cada proyecto. Veo muchas veces desarrolladores empecinados en construir el mejor software de la historia en lugar de construir un software suficientemente bueno respetando los costos y los tiempos que el proyecto impone. 

Es justo decir también que a veces el usuario/cliente no colabora a la hora de mantener todo dentro de los parámetros fijados pero ese es otro problema en el que seguramente estaremos de acuerdo: ¿cómo hacer para que el usuario/cliente no conspire contra el logro de los resultados? 

Ese otro problema no es objetivo de este post. Aquí quiero hablar de esa tentación de que tenemos tantas veces los técnicos de complicar la solución, de hacerla más sofisticada, de agregarle "firuletes" que luego no sólo no sumarán, sino que en realidad restarán.

Pongo un ejemplo personal. En un proyecto de construcción de un software tuve serias discusiones con el equipo técnico respecto de lo "genérico" que debía ser el modelo de datos. Mi posición era hacer un modelo simple, tal vez menos flexible pero más fácil de entender y seguramente más fácil de explotar desde los reportes. La posición del equipo técnico era la de hacer un modelo totalmente genérico que se adaptara a muchas otras situaciones además de la situación concreta sobre la cual debíamos trabajar. Fueron largas charlas para tratar de hacerles entender que luego tendríamos problemas para mantenerlo, que no tenía sentido hacer un software que sólo el 2% de la fuerza de desarrollo pudiera "tocar". Para hacer corta la historia les cuento que perdí la batalla y hoy ese software tiene los problemas que yo enuncie.

Mi lección aprendida es que, si bien ya estoy alejado del detalle técnico, tengo que hacerle un poco más de caso a mi olfato. :-S

El punto es que hay que encontrar un punto de equilibrio pues tampoco vale la situación inversa de no poder mantener el software por lo mal diseñado y programado que está. No sirve hacer un software "atado con alambre" porque tendremos problemas también. O como mínimo tendremos costo de "refactoring".

El equilibrio está en lograr una solución suficientemente solida como para seguir construyendo encima pero suficientemente sencilla como para poder mantenerla a un costo razonable.

¿Qué opinan? ¿Se han encontrado con este problema?

Seguimos pensando..