La ineficiencia de la industria de software

El ser humano como primera opción usa la fuerza bruta para resolver sus problemas. Si no consigue hacer algo con ciertos recursos humanos, acaba poniendo más para hacerlo y, sólo después, cuando fracasa, piensa en cambiar métodos y paradigmas. Eso es lo que ha hecho tradicionalmente la industria de desarrollo de sistemas en el mundo.

Existe una enorme ineficiencia de la programación manual en todo el mundo y la ineficiencia relativa es cada vez mayor. Se puede pensar que con los nuevos lenguajes -por ejemplo por usar Java o C#, en vez de usar Cobol- existe un aumento de productividad del orden del 50 al 100% sobre los estándares de 1990. Pero las aplicaciones actuales son mucho más complejas que las de 1990 (probablemente 1000% más complejas. Entonces, si estábamos mal, estamos peor.

El síndrome del año 2000, empujó aún más el uso indiscriminado de recursos de la fuerza bruta.

Cómo se ha respondido a la ineficiencia del desarrollo manual

Contratación de paquetes: contrato la solución hecha, sabiendo que no va a satisfacer más que un porcentaje de mis requerimientos, sabiendo que voy a perder individualidad y, a veces, mis ventajas diferenciadoras. Sacrifico eso y me incluyo en una solución general. Esa ha sido una gran tendencia. Los grades líderes de los paquetes han conseguido insólitamente convertir su debilidad en fortaleza pregonando con éxito que si quiero ser una empresa de clase mundial debo utilizar su software (y, desde luego, adaptarme a él).

Importación de recursos humanos. Esto es bastante claro, por ejemplo, en Alemania.

Contratación de programación y, si es posible desarrollo y aún outsourcing, en países donde los salarios son muy bajos y la capacidad técnica razonable. Éste es el fenómeno de la India hoy emulado por muchos países de bajos salarios y que afecta en forma importante a la industria de software de los países desarrollados

Tenemos varias experiencias al respecto y hemos emprendido una acción por una oportunidad ligada a la solución de este problema en el Japón. Pero el problema no se refiere únicamente al Japón: en el último Cebit de Hannover he tenido la oportunidad de conversar con varios empresarios de software y servicios asociados de Alemania, Inglaterra y Holanda, fundamentalmente, y todos están sintiendo el mismo problema. En particular todos ellos contratan servicios en la India y les es claro que resuelven el problema sólo transitoriamente: todos ellos ven claro que, en el medio plazo, si todo sigue así, sus clientes contratarán directamente en la India.

Dicho de otra manera: con los actuales paradigmas de desarrollo manual es inviable la industria de software y servicios asociados en los países desarrollados que pagan altos salarios.

¿Y eso es fatalmente así?

El síndrome del know how

Estamos en una cultura presidida por el "síndrome del know-how". Permanentemente manejamos una enorme cantidad de datos, poca información y casi ningún conocimiento. Por eso no vemos los problemas en su verdadera perspectiva, por eso no los resolvemos.

Para revertir la ineficiencia: desarrollo basado en conocimiento

¿Cómo revertimos esto? Los requerimientos tienen que especificarse estrictamente al nivel del "qué", y para ello necesito que el analista -ninguna máquina lo va a hacer- entienda el "por qué" y el "para qué". Entonces la persona, un analista de negocios, va a describir el qué, y luego veremos cómo lo hacemos: el "como" siempre puede automatizarse.

Si lo hacemos a mano el "qué" es insuficiente, hay que saber el "cómo" también, de lo contrario no hay una idea de cuánto va a costar, pero si lo hacemos con herramientas basadas en conocimiento el "qué" es suficiente: describimos en vez de programar. Entonces, es muy importante que podamos ir a un paradigma de desarrollo basado en conocimiento, un paradigma donde yo describo el problema, y no tengo que analizar todo el problema y deducir de el los complejos algoritmos que lo resuelvan.

El conocimiento es permanente, no pierde valor con el tiempo ni con los cambios tecnológicos, el conocimiento es absolutamente independiente de la tecnología (sistemas operativos,  sistema de gerencia de base de datos, lenguaje, arquitecturas). En el desarrollo basado en conocimiento ¿qué pasa con los cambios? Alguien me puede decir no hay cambios, pero es mentira, sólo en una empresa que esté muerta no hay cambios. Hay cambios, sólo que los cambios se propagan automáticamente, la consolidación del conocimiento es automática, la base de datos se diseña y genera automáticamente, los programas se diseñan y generan automáticamente, los requerimientos se describen al nivel del qué.

La importancia del desarrollo basado en conocimiento para las empresas

La influencia de la división del mercado entre dos plataformas de ejecución (Java y Microsoft.NET) es muy importante y afecta al resto del problema. Si soy un cliente final, si hay dos plataformas voy a escoger una y, de pronto, dentro de tres años me doy cuenta que erré y  reparar el error es muy caro, porque generalmente hay que hacer todo de nuevo para otra plataforma. Pero si yo fuera una casa de software, por ejemplo si yo fuera Mariano de Larrobla, la situación es bastante diferente, no puedo escoger, porque escoger significa automáticamente renunciar a la mitad del mercado.

Entonces para una gran corporación es muy importante tener desarrollo basado en conocimiento porque si su elección tecnológica de hoy no es la adecuada, mañana puede cambiarla a un costo muy bajo. Para una casa de software el desarrollo basado en conocimiento es esencial

La tecnología hace la diferencia: GeneXus

Ahora pensemos en la industria de servicios que vende servicios a medida. ¿Qué vendo? ¿Vendo horas de trabajo? Si es esto lo que vendo es mejor que me vaya dedicando a otra cosa, porque nunca voy a poder tener salarios adecuados, en el Uruguay por ejemplo, para poder competir con los países de bajos salarios. Debo organizarme para vender otra cosa, vendo trabajo medido con algún tipo de unidad objetiva que conozcamos ambas partes, vendo trabajo medido, por ejemplo, en puntos funcionales.

¿Qué pasa si hacemos un desarrollo basado en conocimiento, si lo hacemos en GeneXus? Pues una empresa norteamericana, con salarios de USA, trabajando en GeneXus puede hacer la misma aplicación a menos precio de lo que puede hacerse esa misma aplicación en algún país de bajos salarios programando a bajo nivel. Desde luego, los salarios en Uruguay son un poco más bajos -esperemos que suban- y la diferencia es mucho mayor. La tecnología compensa la diferencia.

Lo que queremos es que gente de primera, trabajando en sus países, y ganando buenos salarios, puedan ser eficientes: más que aquellos que ganan bajos salarios pero trabajan sin tecnología.

Esa es la diferencia, la tecnología hace la diferencia.

Material de la conferencia: http://www.gxtechnical.com/main/hdcenter.aspx?2,5,36,938