Muchas veces he escuchado a clientes o compañeros desarrolladores decir “Vamos a usar x framework” o “necesitamos x tecnología para el proyecto. El problema es que la mayoría de las veces no existe un análisis previo de la decisión propuesta. Es sólo porque algo está de moda (o es cool) y ya. Como uno de mis anteriores managers decía frecuentemente “Hype and buzzwords are dangerous friends”.
La pregunta principal que debemos hacer es “¿Cuál es el problema que estoy tratando de resolver?”. Es sorprendente la frecuencia en que proponemos soluciones para problemas que apenas conocemos. Estamos ansiosos de brincar a la pelea sin conocer de antemano el tamaño del oponente. ¿Que tal que es un mounstro en lugar de la cosita que habíamos pensado? ¿O lo contrario?
Cuando un desarrollador ve la oportunidad de aplicar una nueva tecnología que le gusta en un proyecto real, es predecible que lo propondrá sin preámbulos. Es algo normal, siempre estamos influenciados; nos gusta tener currículums con cosas brillantes. Pero, no perforarías tu pared con un taladro industrial cuando sólo quieres colgar un cuadro, o sí? Por eso es importante conocer tus herramientas. Usar algo sin conocer las implicaciones sólo porque es cool o nuevo puede agregar ciertas complicaciones. Aunque sean pequeñas, deben ser al menos declaradas para que todos esten en la misma página.
Por ejemplo digamos que quiero crear una pequeña página web para enviar algo. El cliente puede pedir que sea responsiva, o quizá yo prefiero hacerlo así porque pienso que es lo mejor. Pero primero necesitamos saber realmente los usuarios finales accesaran usando resoluciones diferentes. Quizá la aplicación solo va a ser usadas en las computadoras estándar de la oficina corporativa, por lo que usar Bootstrap no agrega mucho valor. Recuerda que la tecnología es una herramienta con la intención de dar valor a los usuarios; si algo va a hacer las cosas más lentas, complejas, etc., no debería ser considerado.
Si eres el responsable de tomar la decisión, tiene siempre que haber una razón detrás. Siempre pregúntate el porqué. Cinco veces. También pregúntate ¿hay una manera más fácil?. Como dicen Jason Fried y David Heinemeir Hansson en Rework, “Busca una solución tipo judo, que dé máxima eficiencia con mínimo esfuerzo”.
Todas las decisiones tienen un costo, por lo que es importante hacer las consideraciones pretinentes. Siempre un porque no; es necesario tener en claro cuando algo (tecnología, lenguaje, framework, etc) no es buena opción. De otro modo podrás parecer sólo un entusiasta novato en lugar de un desarrollador de software profesional.
Sé agil, de nuevo, primero es necesario enfocares en el problema y el valor que necesitas proporcionar. He visto (y participado en) discusiones sin fin acerca de qué tecnología es mejor y la mayoría de las veces no hay un claro ganador fuera de las preferencias personales.
[blogoma_blockquote ]
“We need to architect systems first and then decide which standards can support desired system requirements and qualities”
Grace Lewis
[/blogoma_blockquote]
No es que no pueda usarse cualquier tecnología para cualquier problema, pero la mayoría de las veces es la decisión menos importante. Ahora, tampoco queremos caer en la llamada parálisis de análisis, sino que primero se necesita pensar en las tácticas y estrategias a seguir.
Las tecnologías, lenguajes, frameworks son importantes, pero deben ser la última parte, seleccionados en base a las metas que se quieren alcanzar (a menos que sean restricciones puestas con anterioridad). Primero se necesita definir (o preguntar por) los principios de arquitectura, atributos de calidad, restricciones y después hacer la selección de tecnología.
Ya entonces se puede decidir si es mejor usar Angular o jQuery, Java o Python, SQLServer u Oracle, …. ya sabes a lo que me refiero.
Es correcto, y a veces hasta se sobrepone el ego profesional del developer o arquitecto del software.