Wednesday 11 July 2007

Teoría vs. Práctica. Round 1

En el trabajo del día a día uno a veces cae en la cuenta de que las cosas no son siempre como se leen en los libros; si, esto está claro desde hace rato. Teoría vs. práctica. Pero sinceramente creo que es parte de nuestro trabajo también tratar de que estos dos extremos no se aparten tanto uno del otro.
El caso en el que estoy pensando ahora es, desde mi punto de vista, bastante común. Hablo de un análisis real en el que se consideren los factores necesarios para la selección de un lenguaje de programación para resolver un problema (obviamente, una vez que este está definido y está claro que se quiere solucionar desarrollando una aplicación, script o lo que sea...).

Hasta el momento, nunca tuve la suerte de tener la suficiente libertad ni la posibilidad de realizar un análisis exhaustivo acerca de este tema en un contexto laboral. Por lo general noto que algunos de los siguientes factores afectan con alta influencia a la selección del lenguaje, no permitiendo tener estas libertades de las que hablo:

  • Lenguaje con el que trabaja la empresa u organización en la que trabajamos. Por una cuestión de convenios o relación laboral inter-empresas o por disponer de licencias para determinados productos asociados directamente a un lenguaje determinado, nos vemos acotados en el análisis. Este tipo de restricciones parece inevitable.
  • Conocimientos por parte de los recursos. ¿Por que pasa a ser esta una restricción? Pienso que muchas veces por especulación. Si se tiene desarrolladores con dominio de un lenguaje de programación determinado y la posibilidad de capacitar o bien obtener nuevos desarrolladores con dominio del lenguaje que realmente se requiere, ¿por que no hacerlo? Tal vez sea porque no se sabe qué lenguaje realmente se requiere (aquí estaría afectado el 'conocimiento por parte de los recursos' de más alto nivel: líderes técnicos, arquitectos, etc.). O tal vez sea por propósitos económicos (léase, ahorrarse unos mangos). Yo veo a este tipo de restricciones como algo posiblemente evitable, siempre que se cuente con los recursos y voluntad necesarios.
  • Modas. Muchas veces se nota que, debido a falta de claridad en ciertos conceptos, se selecciona un lenguaje en función a 'lo que se usa actualmente'. Sería algo asi como un '...y si lo usa todo el mundo debe ser bueno...'. No creo que haga falta aclarar mucho mas.
A modo de mini-resumen observo que a menudo trabajamos matando lo que se nos cruce por delante con un cañón. Sea un ejercito entero o un mosquito. Ni hablar de cuando se eligen frameworks o toolkits para trabajar, pero de eso podemos 'hablar' en otro momento (aunque está muy relacionado).

Por otro lado, algunos de los factores que tendría en cuenta si existiera esa libertad para el análisis (que actualmente veo restringida):

  • Análisis del problema y visión. Creo que en parte el análisis del problema a resolver se basaría en un análisis de la posible solución y su factibilidad. Esto requeriría experiencia y visión del profesional encargado del análisis.
  • Eficiencia del lenguaje. ¿Necesito responder en tiempo real? ¿Como me pueden perjudicar/beneficiar factores propios del lenguaje o de la plataforma que lo soporta (se me ocurre por ejemplo, el uso de Garbage Collectors, manejo de la memoria disponible, etc)?
  • Comunidad de apoyo/referencia. Si tengo problemas, tengo a quien recurrir? Empezando por los recursos que tenga en la empresa (líderes técnicos, arquitectos, etc.) y siguiendo por la comunidad de desarrolladores que podemos consultar por ejemplo en foros o que nos puedan comunicar su experiencia.
  • Documentación existente. ¿Existe documentación formal sobre el lenguaje (mas allá de los foros... ¿algún libro, tutorials?), problemas existentes, problemas solucionados, y todos aquellos factores que nos reflejen la madurez del lenguaje?.
  • Proyección, crecimiento. ¿Es un lenguaje con tendencia a evolucionar, madurar, integrarse?¿Cuán viable parece una migración?
  • Paradigma. ¿Pertenece a algún paradigma de programación?¿En que medida se ajusta al paradigma al que pertenece?
  • Herramientas asociadas. ¿Existen frameworks/toolkits/bibliotecas de funciones maduras para el lenguaje que me puedan ayudar en el desarrollo de mi solución? ¿Existe una IDE que brinde beneficios considerables en el trabajo diario?

La conclusión desde mi punto de vista es que la realización de este tipo de análisis no resulta excesivamente costosa; Si bien, muchas veces nos encontramos afectados por las restricciones mencionadas inicialmente y no poseemos control sobre ellas, observo que con frecuencia, la selección del lenguaje no es resultado de un análisis real, sino es tomada como premisa incuestionable de trabajo. ¿Por qué entonces no realizar un análisis real y exhaustivo y comunicarlo a los niveles superiores en un modo profesional y a la vez comprensible de manera de lograr mayor eficiencia? Si no logramos eficiencia, tal vez logremos mostrar profesionalismo. Cuando las cosas se hacen bien, la recompensa llega en algún momento.

1 comment:

Unknown said...

Muy interesante el post. Hace algunos días ya que quería dejar un comentario, pero lo venía posponiendo (tal vez con la intención de aclarar un poco mis ideas).
Bueno, va mi opinión al respecto: realmente creo que es verdad lo que dice Daniel, creo que sería conveniente que la decisión sobre qué herramientas utilizar debe ser el resultado de un análisis de las necesidades y restricciones que nos imponen tanto el problema como el contexto.
Uno de los limitantes que se me ocurren al momento de aplicar esto es que es complicado encontrar personas con el conocimiento suficiente de distintas herramientas (en este caso me refiero a lenguajes de programación -o ambientes-, pero también se aplica a frameworks, IDEs y otras cosas) como para tomar una decisión con fundamentos.
Dejo el link de un artículo que encontré que tiene varios aspectos relacionados con este post http://www.infoq.com/news/2007/08/buzzword-driven-recruiting