Hace unos días estuve viendo la película llamada Amor sin escalas (Up in the Air), en esta película, el protagonista, empezaba diciendo (en una conferencia):
“Imaginen por un segundo que llevan una mochila. Quiero que la llenen con todas las cosas que hay en su vida. Empiecen con las cosas pequeñas, las cosas de los estantes, cajones… Luego las cosas más grandes. Ropa, electrodomésticos, lámpara, televisor…, La mochila comienza a pesar. Sofá, coche, casa… Quiero que lo metan todo en la mochila; ahora imaginen caminando con esa mochila…, probablemente no puedan dar un paso”.
Al escuchar eso, lo relacione con el desarrollo de software, con la arquitectura y el diseño de la base de datos. Al establecer una arquitectura o al pretender hacer un modelo de datos al principio del desarrollo (BDUF) es como llenar una mochila para el equipo, mientras mas se avance en el modelo de datos, más difícil (menos ágil) será el camino; siendo, muchas veces, esto un impedimento para avanzar.
A veces el tener un modelo de base de datos (supuestamente terminado) al inicio del proyecto solamente causa retrasos en el desarrollo porque los desarrolladores podríamos ver algún tipo de error en el modelo; modificar este modelo sería mucho mas complicado porque mover una tabla que ya esta diseñada podría afectar otras tablas. Incluso hacer esto es un completo desperdicio de tiempo y esfuerzo, ya que las tablas que podrían estar involucradas en el cambio no se usan hasta muy avanzado el proyecto.
El diseño de la base de datos (Sea relacional o no), debería ser un diseño emergente, el modelo va a surgir conforme va avanzando el desarrollo del software. Y sobre todo (al usar TDD), todo el modelo esta respaldado y probado. Y haciendo las cosas al estilo "Lean", nuestro modelo en cualquier todo momento tendrá unicamente tdatos que aporten un valor para la empresa.
Pero ¿Y como se puede lograr esto?, al principio del desarrollo se entregaria un MVP (Minimum Viable Product), con esto, el negocio tendría un producto usable y que agrege valor al mismo. Sin preocuparse demasiado en aspectos que en "algún futuro" se utilizarán (esto no quiere decir que no las tengamos presentes). No podemos desarrollar un software para que soporte un millon de usuarios cuando actualmente solamente lo usan cien; cuando tengamos mas demanda la arquitectura tendrá que ir evolucionando y adaptándose a las nuevas necesidades de nuestro software.
Diseñar la arquitectura de un sistema o la base de datos (Cuando se hace bajo el enfoque BDUF) toma demasiado tiempo, si el proyecto se detiene (por algun motivo), en el momento del diseño, ese proyecto nunca existió porque los papeles (diseño) no es software y por lo tanto ese software tampoco existió. Si por el contrario empezamos con un diseño Agil, en poco tiempo tendremos software funcionando (y de calidad) que dará valor al negocio.
Nadie puede predecir que es lo que ocurrirá en el futuro, y menos nosotros; gastar energías en un "por si acaso", es desperdicio, y no se debería hacer. Asi que debemos enfocarnos en hacer software funcional y que aporte realmente al negocio.
