Grimpi IT Blog

diciembre 20, 2010

Programando bajo Assumptions Driven Development (ADD)

Filed under: Arquitectura, Opinion — grimpi @ 4:24 pm

Antes de empezar este post, quiero advertir al lector, que el dueño de este blog no está muy de acuerdo con el modo en que se está desarrollando software actualmente. La mayoría de las posturas del autor, son contrarias a las del “mainstream” informático.

Una de las cosas que actualmente se utiliza mucho en el desarrollo de software, son los supuestos. Qué pasa si el día de mañana cambiamos de base de datos? Qué pasa si el día de mañana en vez de escribir en una base de datos, escribimos en un xml? Qué pasa si el día de mañana cambiamos de framework de logging? Qué pasa si el día de mañana nuestro sistema desarrollado para correr en un servidor Windows 2008 debe correr en un celular Android?
En definitiva, planteamos una serie de supuestos posibles cambios tecnológicos o de infraestructura que podría sufrir nuestra aplicación, pero nunca evaluamos la posibilidad de que tal cosa efectivamente suceda. Y estos supuestos no son gratis, porque requieren de capas de abstracciones que agregan más código, necesidad de uso de frameworks y nos limitan nuestras posibilidades.
Es lo que yo llamo Assumptions Driven Development (ADD). Desarrollo a base de supuestos.
Lamentablemente hoy en día, es casi la regla trabajar bajo esa “metodología”, pero cuya importancia esta terriblemente sobrevalorada. El gran mito de la portabilidad.

Si una empresa trabaja hace 10 años con un motor de base de datos especifico, por ejemplo, SQL Server y no hay ningún proyecto a corto y mediano plazo de migrar a Oracle, cual es el sentido de hacer una aplicación especifica para esa empresa que sea portable por si el día de mañana se cambia de motor, sabiendo que es muy poco probable que tal cosa suceda? Y como dije antes, los supuestos no son gratis. Nos limitan tanto en productividad como en performance. Si yo quiero hacer que mi sistema sea portable, entonces estoy desaprovechando muchas características que son propias de una determinada tecnología. Puedo usar store procedures en vez de tener un ORM que me autogenere consultas SQL genéricas, puedo usar características avanzadas de SQL Server incorporadas en SQL 2005 y 2008 que nhibernate o cualquier ORM no soportan. Lo mismo aplica a otros motores. PostgreSQL tiene algo fantástico que son los campos vectores. Es algo muy específico de PostgreSQL y lamentablemente si quiero portabilidad, difícilmente pueda usarlos.
Y no solamente con las bases de datos. La metodología ADD se usa en casi todas partes y junto con la utilización de mocking, es responsable del gran auge que está teniendo los frameworks IoC y la inyección de dependencias. Realmente necesito inyección de dependencias en mis clases para otra cosa que no sea mocking? Realmente necesito crear tantas interfaces para mis clases puedan ser reemplazadas por otras? Puede que sí, depende de las características del negocio y la aplicación, pero si vamos a usar DI solamente para un eventual cambio de librería de logging o de acceso a base de datos, me parece que hay que hacer un stop y pensar nuevamente si realmente vale la pena ensuciar el código con esto.
Porque ese es uno de los costos que pago para ser en muchos casos, innecesariamente flexible. Y la realidad que el uso de tantos frameworks a veces a uno le hace perder un poco el control de la aplicación.
Otro supuesto también muy común, es la escabilidad. Nuestro sistema “debe ser” escalable de antemano, aun si estamos desarrollando un software especifico para una pyme que van a usar 20 empleados. Esto significa hacer uso de estrategias de caching (con su respectivo framework) muchas veces innecesariamente.
La pregunta que hay que hacer es: tiene sentido pensar en portabilidad si la vida util del sistema es de 3 o 4 años maximo? Tiene sentido tanta flexibilidad y portabilidad? Estos supuestos, es común que ocurran? Y la verdad que no siempre sucede.
Y me atrevería a decir, que son minoría.

Por supuesto que si yo estoy desarrollando un software ERP genérico que quiero venderlo al mercado, la portabilidad es una gran ventaja, porque me permite venderlo a clientes que utilicen distintas plataformas. En ese caso, cuando se inicia el desarrollo del proyecto, no queda otra que pensar en portabilidad. Pero la mayoría del software que hacemos en general, no es genérico. Es específico para una empresa particular cuya infraestructura no suele ser migrada radicalmente o es una página web en donde los cambios de arquitectura e infraestructura tienen otra dinámica totalmente distinta y generalmente, cuando se produce un cambio de este estilo, es necesario reescribirla gran parte y no por una cuestión de no haber pensado en estos supuestos cambios, sino porque los casos de uso de nuestra aplicación cambiaron mucho. La vida util de un sistema web suele ser por otra parte mucho mas corta.

Ojo, yo no planteo tirar por la borda todo y no pensar en posibles cambios tecnológicos que puedan existir en la aplicación, pero si tener un poco más de cuidado, evaluar los costos que significan estos supuestos y ver si realmente existe la posibilidad de que tal cosa exista. Dejar de tener miedo en “casarse” con una tecnología y aprovechar al máximo, todas las bondades que ofrece.

2 comentarios »

  1. Argentina and Uruguay keep the report for the most worldwide
    matches performed in between two nations around the world.

    The two teams have confronted every single other 161 times given that 1901.
    The 1st match against Uruguay was the first formal intercontinental match to be performed outdoors the United Kingdom.
    Marcelo Trobbiani was a member of the Argentina World Cup squad in 1986, but he
    only managed two minutes of perform in the total event, he came on in the 88th
    minute of the World Cup Ultimate towards West Germany.

    This two minutes of football equalled the world record for the shortest World Cup job established by Tunisia’s Khemais Labidi in 1978.

    Comentario por 2010 fifa world cup brazil squad — marzo 31, 2014 @ 11:37 pm

  2. […] a nuestra solución, ya exprese mis dudas respecto a los nuevos patrones de diseño, pero de nuevo Esteban nos ofrece su visión de porque algunas cosas se terminan imponiendo (sin necesidad): Assumptions […]

    Pingback por La eterna búsqueda de lo que agrega valor a los proyectos | Consultor Internet — noviembre 1, 2014 @ 7:05 pm


RSS feed for comments on this post. TrackBack URI

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

Blog de WordPress.com.

A %d blogueros les gusta esto: