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..

Comentarios

  1. Sinceramente creo que buscar un 7 es un error

    ResponderBorrar
  2. MAxi,
    gracias por el comentario pero ...

    No!!! Yo no digo apuntar al 7. Vos me conoces :-)

    Mi punto es que a veces nos pasamos de vueltas, tal vez es deformación profesional.

    Para mi la calidad tiene que verse, la tiene que ver el usuario/cliente. Lo de adentro es importante pero no lo más importante. Ese es el problema. A veces uno cae en el error de que lo más importante es lo de adentro.

    ResponderBorrar
  3. es un clásico problema de comunicación, chiste tambien clásico

    http://bit.ly/26d35s

    ResponderBorrar
  4. Creo que es un clasico problema de comunicacion, se soluciona hablando

    http://bit.ly/26d35s

    ResponderBorrar
  5. Kisku, me puse a leerte ahora que yo también estoy en management, y este post me toca de cerca.

    Estoy de acuerdo con tu postura. Es el problema de la optimización prematura, y es mucho más evidente en el contexto de una startup, donde no hay una lista de requerimientos y uno puede ir más o menos para donde se le de la gana. Suponiendo una visión estratégica que guíe el camino, la mejor forma de avanzar es hacer lo mínimo necesario, sin por eso cometer "crimenes".

    La solución que lleva menos esfuerzo o, a igualdad de esfuerzo, la solucion más simple y clara, es la correcta incluso si potencialmente puede complicar las cosas a futuro, porque no es seguro que ese futuro llegue a materializarse. En general, ese futuro viene condicionado por un "si crecemos mucho". Pues bien, si crecemos mucho, estamos donde queremos estar, y tener que adaptar el software para soportar ese crecimiento es un buen problema.

    Otra forma de verlo es el "pain driven development". Sólo se desarrolla algo si no hacerlo causa más problemas que hacerlo. Es notable lo liberador que resulta poder decir "esto no lo voy a desarrollar ahora; si se torna un problema, ya veré". Hubiera aplicado perfecto a tu ejemplo: "por el momento ponemos los nombres de las entidadees como nombres de campo en las tablas; si más adelante vemos que se complica, veremos si vale la pena hacer un refactoring". En una de esas ese momento nunca llega y logramos ahorrar esfuerzo y ganamos claridad.

    También conocido como KISS. ;)

    ResponderBorrar
  6. Gracias por el comentaro Jorge. Me gustó lo de Pain Driven Developement!

    ResponderBorrar

Publicar un comentario

Muchas gracias por comentar. Por favor deja tu nombre y/o email, los comentarios son mucho más valiosos cuando se sabe quien los hace.

Entradas más populares de este blog

10 definiciones de calidad

¿Qué es time and material?

Teoría Económica y Outsourcing