Juan Macias dijo

Rodolfo, conozco muy bien el caso de escalar un sistema desde 10 clientes, hasta millones, y he vivido como dos empresas han tomado distintas alternativas.

Mientras que una, simplemente pensó en "mas máquina, más memoria" la otra pensó en optimizar el sistema.

La primera, se está gastando gran parte de su presupuesto en la nube, la otra, aún puede seguir con los procesos en su sistema.

Las soluciones tienen que ser escalables desde el principio, llevarlo a una nube no soluciona problemas de rendimiento ni de escalabilidad, sólo soluciona problemas de infraestructura.

He tenido muchas discusiones con antiguos compañeros, que eran propicios a la frase "si va lento, mas hierro", y despreocuparse totalmente de un diseño bien optimizado.

La nube, desde luego, esta muy bien, pero hacer las cosas bien desde el principio, está mucho mejor :)

3 Junio 2009 | 10:06 AM

Jorge dijo

Comparto 100% la reflexión con Juan. Cuando tienes algoritmos de coste en orden de magnitud 2 o más (es decir, costes geométricos), ampliar máquinas no soluciona nada, pues el crecimiento es lineal. Diseñar un buen sistema de base, es fundamental. Y "la aplicación" que finalmente utilizará el usuario, sólo es una de las muchas que se tienen trabajar. Además de esa aplicación "core", es necesario tener aplicaciones de gestión de incidencias (para el call-center), de monitorización (para saber que todo va bien o dónde se están produciendo los cuellos de botella), de administración, etc.

El problema de la informática es que creo que hemos entrado en una espiral negativa muy complicada:

a) Las empresas compras ingenieros "al peso" (¿a cuánto me dejas la jornada?)
b) Al comprar "carne" y no "proyectos" con objetivos concretos, nadie se responsabiliza del proyecto (bueno, el jefe de proyecto, pero que como tiene "carne" de todos los colores y sabores y poco poder de influencia y motivación sobre ellos, pues queda en nada)
c) Al no haber responsables y existir un mix de ingenieros de todo tipo de culturas, metodolodías, etc. lo que suele salir de ahí es un spaghetty-ware en toda regla, con un comportamiento muy deficiente a medio plazo.
d) Como lo que se ha pagado no está en proporción con lo obtenido, las empresas, en la siguiente iteración, están dispuestas a pagar menos por jornada de "carne de ingeniero"
e) Como pagan menos, se envía a ingenieros de menor calidad (bueno, incluso FPs o lo que sea... no es importante lo que sepan, porque nadie evalua nada ni se controla nada... lo importante es lo que cobran).
f) El resultado es más catastrófico aún

Conclusiones:
1) Los clientes tienen unos sistemas que dan pena y han tirado su dinero
2) Los proveedores serios, están fastidiados porque no tienen márgenes (los talibanes venden "carne" a una parte del coste que tiene para una ingeniería honesta)
3) Sólo ganan las boutiques de carne, pues como da igual el resultado, ellas sólo colocan "ingenieros" y es responsabilidad de los JP hacer el proyecto, pues siguen vendiendo.

Y digo yo... es cierto que la ingeniería informática es muy jóven respecto a la ingeniería industrial o aeronáutica. Pero ¿no podríamos copiar algo los modelos clásicos de ingeniería que tan buenos resultados han dado? Somos capaces de construir edificios, puentes y artefactos inmensos y con un nivel de complejidad brutal y ¿no somos capaces de construir software de calidad?

¿Cuál es la diferencia?. Pues básicamente que un puente, un edificio o un artefacto "clásico" se percibe por los sentidos (se puede ver). El software es un intangible y como pocos son los que tienen visibilidad sobre él, pues se hace de todo y lamentablemente, casi siempre mal.

Así que comparto por completo la reflexión sobre la importancia de los sistemas, pero creo que hay pocas ingenierías honestas y pocos clientes que sepan apreciar el trabajo que hacen (la "página web" -termino utilizado normalmente, en lugar de "aplicación web", lo que ya dice mucho de quien lo utiliza- se ve igual cuando se hace la demo al Director General o comité esté bien hecho el sistema o no. un puente, si está retorcido, se ve claramente).

3 Junio 2009 | 10:31 AM

Juan Macias dijo

Jorge, veo que coincidimos en que la consultoría tradicional no tiene futuro. Y que nos están comiendo otros países a base de mano de obra barata, en lugar de mejorar la productividad y eficiencia.

El problema, es que NADIE se cree que se pueden hacer las cosas mejor, y hay poca gente interesada en invertir en productividad.... es una pena. Nosotros estamos dedicando más de un 20% de nuestro tiempo en mejorar nuestro sistema y nuestra productividad....

3 Junio 2009 | 11:12 AM

Jorge dijo

Sin duda Juan... 100% de acuerdo contigo en que todo el mundo piensa que no es posible mejorar. Nosotros conseguimos CMMi Level 3 en Diciembre, después de varios años de trabajo (no sólo en implantar procesos... sino en implantar cultura de ingeniería a los ingenieros). El incremento de productividad lo puedes conseguir por varios canales. Uno de ellos, la madurez de los procesos. Pero cuando hablas de creatividad, es complicado. Así que tienes que ir a economías de alcance (dado que no puedes implementar economías de escala en sistemas hechos a medida). Pero si unes ambas cosas, consigues una alta productividad en la creación de sistemas que incorporan una gran calidad como consecuencia de la madurez y de la economía de alcance.

Peeeerooo... eso tiene sentido, si hablas de crear un proyecto, donde tienes cada "pieza de ajedrez" en su posición y todos ellos trabajando con una estrategia compartida (cultura, metodolodía, criterios sobre estándares de calidad, etc.). Cuando eso te lo cargas y piensas que hacer software es un juego de damas, donde los "ingenieros" son las "piezas que mueves" y todos pueden hacer los mismos movimientos... pues no entiendes la complejidad de lo que tienes entre manos (no sólo el proyecto, sino las personas encargadas de su ejecución), piensas que todos los ingenieros informáticos hacen de todo con la misma "habilidad" y "Profesionalidad" y el proyecto te lo cargas.

El problema es que creo que es una espiral y que es negativa. Romperla será difícil, pero también me queda claro que no es sostenible y que por algún lugar va a suceder algo. El momento no es malo para una reconversión del sector. El problema es que el driver principal es el coste (lógico) y como sigue siendo un intangible (el software), mucho me temo que se acelerará la espiral negativa, en lugar de convertirse en una positiva.

Eso sí, creo que hay una gran oportunidad para la ingeniería que sepa dar la vuelta al modelo y hacer una propuesta de valor a las empresas donde éstas vean que el valor de lo que obtienen está muy por encima de lo que pagan (a diferencia de lo que sucede ahora), aunque lo que paguen "por jornada" esté por encima de lo que tienen marcado como referencia. Si comenzasen a darse cuenta de que la inversión en software es a largo (como casi todas las inversiones) y que la rentabilidad de la misma hay que verla a futuro (y en esto tiene mucho que ver la escalabilidad del sistema), se darían cuenta de que lo que importa es el coste total de propiedad del proyecto, y no el coste por jornada de un ingeniero...

Quizá tengamos que avanzar mucho en el ámbito de las responsabilidades. Cuando un puente se cae, aunque hayan pasado varios años, el equipo de ingeniería tiene una responsabilidad clara. Si un software "se cae" y no funciona... aquí no pasa nada... creo que esto marca una gran diferencia sobre cómo se aborda de origen la construcción.

3 Junio 2009 | 11:28 AM

Daniel Brandi dijo

No puedo por más que coincidir 100% con la reflexión de Juan. En estos días se habla mucho de cloud computing y hay gente que piensa que es la solución a muchos de sus problemas, cuando en realidad la mayoría de los problemas de escalabilidad son problemas de diseño que necesitan de gran dedicación para estar en continuo proceso de evolución y así disponer de un sistema robusto y escalable.

He entendido entre líneas en la reflexión de Rodolfo que un desarrollo hecho en casa no tiene la capacidad de escalar y que en algún momento hay de "tirarlo" y hacerlo de nuevo. Realmente no se trata de un problema de hacerlo en casa o utilizar una solución existente. Se trata de hacer algo bueno y escalable desde el principio y asumir que cierta capacidad de desarrollo interna se debe dedicar a evolucionar el sistema para así poder mantener esa escalabilidad.

Un saludo

3 Junio 2009 | 11:57 AM

Juan Macias dijo

@Jorge, enhorabuena por lo del CMMi, sé lo que cuesta, yo lo implanté en mi último trabajo, donde por cierto, desarrollé una herramienta para facilitar la implantación de CMMi, creo que es la única que existe, se ha llevado varias subvenciones de I+D, lo gracioso, es que la hice por mi cuenta, por que nadie apostaba por ella.

@Daniel, lo de software hecho en casa, normalmente se refiere (al menos eso pienso yo) en los desarrollos que suelen en las empresas, el listillo que sabe algo de informática, utilizando el excel o el access.

3 Junio 2009 | 12:06 PM