Xuaps

Walter White

Qué estás haciendo mal? – Overengineering

Uno de mis primeros proyectos en este oficio fue una aplicación para una federación deportiva. Después, mi empresa vendió este software a otras federaciones. Era lo suficiente similar como para justificar reusar el código pero lo suficiente diferente como para tener características propias. Así que lo que hacíamos era duplicar el proyecto, cambiar los nombres y hacer las modificaciones necesarias. Evidentemente esto generaba mucho trabajo antes y después. Aunque yo había aplicado todo lo que me habían enseñado en la carrera y en la certificación MCSD de Microsoft, había algo que me olía mal.

Cuando cambie a otro proyecto, liderado por un equipo de veteranos programadores, creí encontrar la solución a todos mis problemas. Construir nuestro propio framework. Además de encapsular todo ese código común que tenían mis otros proyectos íbamos a forzar al framework de Microsoft a trabajar “de una forma más ortogonal”. Se mascaba la tragedia.

A los programadores nos gustan los retos y nos gusta escribir nuestra propia capa de acceso a datos capaz de interpretar sql y generar el código necesario para persistir y cargar nuestras entidades. Disfrutamos programando nuestro propio scaffolding. Y por supuesto nos gustan los patrones y si hace falta crear nuevas capas de abstracción e indirección para que las cosas funcionen como nosotros queremos lo hacemos sin despeinarnos. Todo configurable… O lo que es lo mismo nos encanta hacer overengineering, es nuestro trabajo.

Pero después de enfrascarse en todos estos problemas ¿alguien se ha preguntado de qué iba la aplicación? Buena pregunta. Creo que tenía algo que ver con hoteles, pero en los 6 meses en los que estuve trabajando la verdad es que no supe mucho más. En el primer proyecto había cosas mal, código duplicado sobre todo pero no trataba de adivinar el futuro, había programado lo que necesitaba para implementar los requisitos del cliente, YAGNI. En este segundo proyecto construimos una torre de marfil que no resolvía ninguno de los problemas reales de nuestro cliente.

En cualquier caso, esto no es una discusión acerca de frameworks si o no. Ni tampoco sobre diseño emergente vs bduf o botton-up vs top-down. Hay dos lecciones que yo extraería de aquí:

  • La primera, a no ser que tu producto sea un framework, si sabes más acerca de la capa de persistencia que de cómo es el proceso de reserva de habitaciones lo estas haciendo mal.
  • La segunda, el futuro es impredecible así que programa con las cartas que tienes y hazlo aplicando los patrones, principios y técnicas que te permitan moverte rápido cuando repartan la siguiente mano. Si estás escribiendo una capa de abstracción por si algún día alguien quiere cambiar de motor de base de datos lo estas haciendo mal.

Corolario: Si trabajas en la administración y tienes capacidad para decidir esto, un consejo, un framework no es un proyecto de I+D+i.