“Software que funciona” nos pregunta:

¿Hasta qué punto valorais en un proyecto el lenguaje, frameworks, o cualquier cosa que vayais a usar?. A ver si me explico. Ahora trabajais con Ruby, cuando os habéis planteado comenzar un nuevo proyecto, dedicais mucho tiempo a ver si el lenguaje que utilizais es el más conveniente?. No sé, si por ejemplo, vieseis que para hacer algo vais a tener que desarrollar vuestro propio código cuando igual con otro lenguaje ya lo teneis hecho, modificariais la concepción del proyecto, cambiariais de lenguaje… Ya sé que igual no es algo habitual, pero el otro día surgió el tema en una conversación y me ha parecido interesante, dar prioridad a la idea original a costa de mayor complejidad o reducir esa complejidad variando el concepto.

Ninguna herramienta, de ningun tipo, vale para todo… de hecho hay pocas que sean realmente buenas como herramienta polivalentes. Nuestro enfoque con respecto a la adecuación o no de un lenguaje o frameworks a los proyectos es por lo tanto igual, no todo vale para todo.

Dicho esto hay que tener en cuenta que, siendo realistas, tampoco los proyectos de una empresa son 100% diferentes cada vez, y que por lo tanto un número reducido de lenguajes/herramientas suele ser suficiente para acometerlos.

En nuestro caso, y a pesar de que entre los 3 juntamos varias décadas de desarrollo en Java, nuestro proyectos actuales estan relacionados con el desarrollo de aplicaciones y productos Web y Rails es en este caso una herramienta fantásticamente adecuada para tales fines.

Como comentas siempre hay excepciones, sobre todo en aplicaciones o librerías de nicho (gráficas, generación de formatos específicos, integración en sistemas antiguos), para los cuales otras herramientas tiene ya mucho camino andado. En estas ocasiones, obviamente se trata de aprovechar al máximo lo disponible pero con dos condicionantes:

• El coste de integración también existe. Es decir el tiempo que va a costar integrar esos componentes tiene que ser valorado y comparado con otras opciones (por ejemplo el desarrollo propio).

• Las integraciones complejas no suelen merecer la pena. Precisamente por lo que hablábamos en el punto anterior… por la complejidad aumenta el tiempo y el esfuerzo, y estos el coste.

En principio en Linking Paths tratamos de huir de la complejidad en el desarrollo de las aplicaciones (lo cual es difícil porque los desarrolladores somos gente cabezona y obcecada en general) y valorar en mayor medida otros puntos que el usuario puede valorar -¡y pagar!- en mayor medida.

¿Tienes alguna pregunta que nos quieras hacer?… ¿puede ser interesante para otros?: no lo dudes, mándanosla a linked@linkingpaths.com especificando en el asunto “Linking Paths responde:” e intentaremos responderla en este blog mediante articulo al respecto.