[:es]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.[:en]Many times I’ve heard clients or peer developers saying “Let’s use x framework” or “we will need to apply x technology”. The problem most of the times is that there is no prior analysis for the decision its being proposed. It is just because it’s something trendy (and cool) and that’s it. As one of my prior managers frequently said, “Hype and buzzwords are dangerous friends”.

The main question we need to ask is “What’s the problem we are trying to solve?”. It is surprising how frequently we come up with solutions for problems we barely know. We are eager to jump into the fight without knowing the size of the opponent before hand. What if it ends up being a monster instead of the small thingy we thought? Or just the opposite?

When a developer sees a chance of applying in a real project a new technology he likes, it is predictable that he will propose it straightforward. It is something normal, we are always biased. We want a resume with shiny things. But, you won’t create a hole to hang a painting using an industrial drill, will you? This why it is important to know your tools. Using something without knowing the implications just because is cool or new may add some potential problems. Even though they might be small, they need to be at least disclosed so everybody it’s on the same page.

For example let’s say I want to create a small web page to submit something. The client may ask it to be responsive, or maybe I prefer to do it that way because I think it is the best option. But, first we need to know if there will be really different resolutions where the end-users will access from. Maybe the app I’m creating will be used in the standard-size computers of a corporate office, so using Bootstrap won’t add much. Remember that technology is a tool intended to deliver value to the users; if something will make it more complex, slower, etc. it shouldn’t be added/considered.

If you are the one responsible of making the call, there should be always a reason behind. Always ask yourself why. Five times. Also ask, is there an easier way?. As Jason Fried and David Heinemeir Hansson say in their book Rework, “Find a judo solution, one that delivers maximum efficiency with minimum effort”.

All decisions come at a cost, so it is important to make the proper considerations. There is also always a why not; you need to have a clear picture of when something (technology, language, framework, etc) it’s not a good fit. Otherwise you might look like a junior enthusiast instead of a professional software developer.

Be agile, again, focus on the problem and the value you need to provide first. I’ve seen (and participated in) endless discussions about which technology is better and most of the times there is no clear winner out of personal preferences.

[blogoma_blockquote ]

“We need to architect systems first and then decide which standards can support desired system requirements and qualities”
Grace Lewis

[/blogoma_blockquote]

It is not that you can’t use any technology for any problem, but most of the times it is the less important choice. Now, we don’t want to also fall into the so called analysis-parallysis; but first you need to think on what are the tactics and strategy you will follow.

Technology, frameworks, languages are important, but they should be the last part and be identified and selected based on the other goals you want to achieve, unless they are constraints already set. First define (or ask for)  your architectural principles, quality attributes, constraints and then make your technology choice.

After that you can decide if it is better to use AngularJS or jQuery, Java or Python, SQLServer or Oracle, ….. you know what I’m talking about.[:]