De lo Complejo a lo Simple: Cómo la IA Está Reinventando el Desarrollo de Software

Marco Cynefin

Hola a todos,

Hace unos días, hablando con mi compañero de trabajo, Roberto Moraga, surgió una reflexión interesante: el desarrollo de software ha pasado de ser un proceso altamente complejo a volverse más simple, en gran parte gracias a la inteligencia artificial. Sin embargo, si bien las herramientas han evolucionado, el mercado (usuarios, consumidores, empresas y negocios) sigue siendo dinámico, incierto y cada vez más complejo. Entender las necesidades y traducirlas en soluciones sigue siendo un desafío estratégico, que marcos como Scrum y metodologías como XP buscan reducir a la interacción con una sola voz.

Después de conversar un rato, llegamos a la misma conclusión: el software ya no se construye de la misma manera que antes. Scrum fue diseñado para gestionar la complejidad del desarrollo de software inicialmente, permitiendo a los equipos adaptarse de manera iterativa y generar soluciones en entornos de incertidumbre y luego su alcance se amplió hacia soliciones en entornos complejos, sin importar si incluían software o no. Sin embargo, hoy en día, el proceso software es mucho más predecible, gracias a la inteligencia artificial, las mejoras en los procesos han aumentado entre un 40% y un 60%, o incluso más, en la generación de código, la validación y la utilización del talento en los equipos.

Esto nos llevó a unas preguntas clave: ¿qué va a pasar con Scrum en el desarrollo de sofware? Si este se ha vuelto más automatizado y eficiente,  ¿Cómo afecta la IA a los marcos ágiles, metodologías ágiles?¿El escalamiento (es decir muchos equipos ágiles) seguirá igual o cambiará al emplear estas nueva tecnología?. Una aproximación para responder a estas preguntas, se plantearán en este artículo.

El desarrollo de software antes de la IA

El desarrollo de software siempre ha sido un ejercicio de lidiar con la complejidad. Antes de la llegada de la Inteligencia Artificial (IA) generativa, la construcción de software requería múltiples iteraciones, idas y venidas con el cliente, reuniones de refinamiento y planificación, pruebas constantes y ajustes sobre la marcha. Era un proceso artesanal en el que cada pieza de código debía encajar perfectamente en un entramado ya existente, con una complejidad que crecía exponencialmente con cada nueva funcionalidad.

Con la llegada de los marcos ágiles, esta complejidad se empezó a gestionar de manera más efectiva. En Scrum y XP por ejemplo, los equipos reducían la incertidumbre fragmentando el trabajo en historias de usuario pequeñas, cada una encapsulada dentro de un timebox de dos semanas (1). Por otro lado, Kanban ofrecía flujos de trabajo más cortos y continuos para optimizar la entrega (2). La clave estaba en la descomposición y la priorización: si algo no llegaba a desarrollarse, al menos lo más valioso ya estaba en producción.

¿Por qué el desarrollo de software es complejo?

El software no es solo líneas de código. Es una red interconectada de dependencias, reglas de negocio, infraestructura, bases de datos y lógica distribuida. Su complejidad crece con cada nueva funcionalidad porque:

• La cantidad de código crece exponencialmente: Cada nueva línea interactúa con muchas otras, lo que hace que el sistema se vuelva más difícil de comprender y modificar (3).
• Las dependencias se multiplican: Los sistemas modernos no son aplicaciones monolíticas; dependen de APIs, microservicios y plataformas en la nube (4).
• Las reglas de negocio son cambiantes: Lo que hoy es válido, mañana puede cambiar por una nueva regulación, requerimiento de usuario o innovación del mercado.
• Las expectativas de los usuarios evolucionan: Lo que antes tomaba meses ahora se espera en semanas o días.

Dave Snowden, con su marco Cynefin, nos dice que un problema puede estar en distintos dominios: simple, complicado, complejo o caótico (5). Durante décadas, el desarrollo de software ha habitado en la zona de lo complejo, donde la relación causa-efecto solo se entiende en retrospectiva, y donde la experimentación y la iteración eran la única forma de avanzar.

¿Cómo la IA ha simplificado el desarrollo de software?

La IA generativa está moviendo el desarrollo de software del espacio de lo complejo al de lo complicado e incluso a la frontera con lo simple. ¿Cómo?

• Generación automática de código: Hoy en día, un desarrollador puede describir en lenguaje natural qué necesita y herramientas como Copilot o ChatGPT pueden generar código funcional en segundos (6).
• Automatización de pruebas: La IA puede crear, ejecutar y ajustar pruebas unitarias y de integración sin intervención humana (7).
• Refactorización asistida: Lo que antes requería semanas de análisis, hoy se puede hacer en minutos con IA sugiriendo mejoras y optimizando código (8).
• Mayor velocidad en el desarrollo: Ahora es posible generar prototipos funcionales en horas, lo que antes tomaba semanas.

Esto ha cambiado radicalmente el flujo de trabajo. Antes, un equipo de desarrollo tenía que construir cada pieza de código manualmente y validarla en iteraciones cortas. Hoy, la IA permite automatizar gran parte de ese trabajo, transformando el proceso en algo más cercano a un modelo de entrega continua, donde Kanban empieza a ser una herramienta de gestión más efectiva que Scrum (9).

¿Qué pasa con el escalamiento?

El desarrollo de software no solo se ha vuelto más rápido con la IA, sino que también ha impactado la forma en que las organizaciones gestionan el escalamiento. Antes, uno de los mayores desafíos en la escalabilidad era la gestión de dependencias entre equipos: ¿Quién trabaja en qué? ¿Qué bloquea a quién? ¿Cuándo estará disponible una funcionalidad que otro equipo necesita?

Con ciclos de desarrollo más cortos gracias a la IA, los equipos están generando software a una velocidad nunca antes vista. Esto significa que los cuellos de botella ya no están en la escritura del código, sino en la coordinación entre equipos.

La nueva gestión de dependencias

Cuando la generación de código deja de ser un problema, la conversación cambia:

• Los equipos hablarán más de dependencias y lo harán más rápido, porque llegarán a ellas en menos tiempo.
• La gestión proactiva de dependencias es clave, porque ahora los bloqueos pueden detener desarrollos que, de otro modo, habrían estado listos en cuestión de horas.
• Los gestores de flujo de trabajo (Scrum Masters, Agile Coaches, facilitadores) deberán anticipar y resolver estas dependencias con más rapidez que nunca.

Esto tendrá un impacto directo en los marcos de escalamiento ágiles como SAFe, LeSS, Nexus y Spotify Model. Tradicionalmente, estos marcos han tratado las dependencias con eventos de sincronización como el PI Planning (SAFe) o los eventos de coordinación en LeSS. Pero en un entorno donde los equipos avanzan más rápido, estas cadencias predefinidas pueden volverse insuficientes. Y es allí donde toma valor la gestión impecable de las dependencias, que es la forma como trabaja Amazon, que logra escalar sientos de equipos sin necesidad de eventos de coordinación.

Cerrando: De la complejidad a la simplicidad

El desarrollo de software ya no es un proceso 100% artesanal. Las historias de usuario siguen funcionando como método de comunicación con el cliente, pero la ejecución es más ágil que nunca. Algunas funcionalidades pueden construirse de manera casi instantánea, moviendo el desarrollo del espacio complejo al complicado, o incluso a lo simple, cuando la IA puede resolverlo sin intervención humana.

La IA ha cambiado el juego. Ahora, la clave no es escribir código más rápido, sino enforcarnos en en entender mejor el negocio y remover bloqueos con la misma o más velocidad que con la que producimos software.

Saludos ágiles,

Jorge Abad

Referencias

1. Schwaber, Ken, and Jeff Sutherland. The Scrum Guide. Scrum.org, 2020.
2. Anderson, David J. Kanban: Successful Evolutionary Change for Your Technology Business. Blue Hole Press, 2010.
3. McConnell, Steve. Code Complete: A Practical Handbook of Software Construction. Microsoft Press, 2004.
4. Lewis, James. Microservices: The Journey to Cloud Native. O'Reilly Media, 2019.
5. Snowden, Dave. Cynefin: Weaving Sense-Making into the Fabric of Our World. Cognitive Edge, 2020.
6. GitHub. "Introducing GitHub Copilot." GitHub Blog, 2021.
7. Agile Alliance. "Dependency Management in Agile Teams." Agile Alliance, 2022.

 

La Inteligencia Artificial Generativa (GenIA) hace a los buenos desarrolladores entre 3 a 6 veces más rápidos según Jeff Sutherland

Video: Las consecuencias del desarrollador barato

Desarrollo Ágil sin Frameworks (sin Scrum, ni XP)

Hablemos de Deuda Técnica - El mal que puede acabar tu proyecto-producto ágil - Reloaded

Hablemos de Deuda Técnica - El mal que puede acabar tu proyecto-producto ágil - Reloaded from Jorge Hernán Abad Londoño

Leido y Recomendado: 12 ideas de la filosofía Clean que no pueden faltar en tu código

Excelente post en GenBeta:dev

12 ideas de la filosofía Clean que no pueden faltar en tu código - (clic aquí)

Dos post que nos invitan a ser muy buenos desarrolladores y a no menospreciar el arte de escribir líneas de código

Estos dos Post... son de antología

Lo escribieron dos ingenieros que conozco y que son de una alta capacidad técnica, los voy a copiar y pegar acá pues es necesario que esto redunde, que esto cale en la mente de los que se están formando en ciencias de la computación, ingeniería de sistemas, ingeniería informática, afines y tambien cale en quienes las estamos enseñando.

Se que un ciclo de formación profesional no tiene como objetivo un solo fin, pero no tiene presentación que los egresados salgan de carreras de sistemas (y sus afines) y que estos no quieran ver lineas de código "por que ya programaron demasiado en la carrera" como alguna vez lo he oído.

Es una realidad, requerimos buenos y excelentes programadores, pero lo cierto es que muy pocos quieren serlo, o peor quieren dejar de serlo lo antes posible.

------

Muchos caciques y pocos desarrolladores

Por: @GabrielMorrisS - Link: http://gabrielmorrissa.blogspot.com/2013/10/muchos-caciques-y-pocos-desarrolladores.html#!

Hace poco alguien me decía que había evolucionado bastante, que ya no desarrollaba y que dirige proyectos, que es todo un PMP. Casi me pega cuando le mencioné que yo siempre voy a ser un desarrollador, aunque lamentablemente cada vez lo hago menos. 

No me creía cuando le conté que cuando trabajé en unos proyectos en Brasil, el que más ganaba era el tester. Varios se han reído de esa anécdota, pues de inmediato me recuerdan que ese "recurso" debe ser un practicante o un bachiller ávido de conocimiento que ejecute checklists. Falso, el tester no solo hace pruebas, afina y recomienda refactorizaciones, evalúa el comportamiento en ejecución a través de telemetrías, en general tiene cicatrices de guerra, no come cuentos.

En otros escenarios me he enfrentado a discursos acerca del recurso, de fábricas de software, de métricas sofisticadas, de planes tipo bola de cristal, de látigo, como si los desarrolladores de software fueran unos chimpancés que se pueden llevar a alta mar para reducir tributos para que entreguen piezas de software similares a chaquetas o camisas. Que hacemos, el software es arte, lo demás son enfoques comerciales que buscan demostrar teorías de modelos de madurez o medir cuantas veces un "recurso" entra al baño para ser más productivo o contabilizar las líneas de código generadas.

En otros escenarios se muestra a super expertos que se muestran así por certificaciones alcanzadas, expertos de un año de experiencia y 6 meses de manejo de una herramienta. Qué pasará si cambian la herramienta? Si cambian las tácticas, las estrategias, los patrones a aplicar? Será que es mejor tener criterio que un discurso acartonado y poco original? Bien dice el antipatrón de dependencia del vendedor que si su arquitectura son herramientas implicará que no tienes arquitectura.

Otras cosas del hoy, bueno y del ayer es el fastidio a ensuciarse las manos con código miserable. Se buscan más niveles de abstracción olvidándose de niveles subyacentes. Por ejemplo: uso JSF según san X vendedor como MVC, uso como ORM  a hibernate, etc. ¿Qué pasa si ocurre un error en estas APIS? ¿Cómo lo resolvemos? ¿Cómo afinamos las consultas?  ¿Cómo evitamos introspecciones innecesarias? .....otro ejemplo es el uso de flujitos, dibujitos con herramientas que generan código; ¿y si fallan, y si el desempeño no es el esperado?

Hace unos meses un desarrollador tuvo un problema elaborando un servicio Web (mal llamado servicio). La afirmación del personaje era, "no funciona", sin entrar en detalles. El problema consistía en que no seguía un estándar simple de JavaBeans acerca de gets y sets para un bean, Qué pasó? Simple, nos volvimos herramienta dependientes, framework dependientes y nos olvidamos de los fundamentos.

Creemos por ejemplo que un ESB es una herramienta o que un servicio es un servicio Web; simple, los fabricantes necesitan vender y ese es un discurso fácil de mostrar y de aprender por figuras comerciales. Por ejemplo, el ESB es un concepto, una estrategia,  una capa de integración, una guía de arquitectura compuesta de patrones de integración siguiendo un manejo stateless con gestión de recursos orientados a la conectividad, que puede ser implementado a conveniencia y a la medida, no es la super herramienta que centraliza todo el procesamiento de transformaciones o adaptaciones. 

Bueno, y ¿los arquitectos qué? En mi opinión son necesarios. Éstos deben proporcionar decisiones de arquitectura teniendo como base pruebas de concepto PoC, decisiones de diseño de alto nivel HLD que impliquen su desarrollo así como el cumplimiento de restricciones y de los principales aspectos no funcionales. Sin embargo, no creo en arquitecturas de marfil o  BDUF, pues muchas decisiones de diseño detallado se determinan en  el día a día, en el tablero no en modelos que desencadenen generadores de código. Es  necesario un dueño de la arquitectura, un Architect Owner.

Otro punto clave es que conozco muchos casos de empresas de ciudad gótica en donde a las personas de negocio les molesta trabajar con personas de áreas de tecnología. Lo anterior porque ven que no les ofrecen implementaciones que realmente produzcan valor para el negocio, prácticas, sencillas, en tiempos cortos y que den solución a su problemática.

En conclusión, nos preocupamos por el cuidado de la caja, del tiempo, del presupuesto y del alcance, pero no en la generación de valor hacia el cliente quien es finalmente el más interesado en el software, si este le proporciona beneficios. En resumen, es necesario buenos desarrolladores con amplia experiencia, con criterio, que en  muchos casos son conocidos como arquitectos de aplicaciones.

Creo que en países hispano parlantes todos quieren ser abogados, gerentes de proyectos, médicos, pero pocos quieren ser maestros en una actividad específica. De igual manera pasa con los desarrolladores, pues todos quieren ser directores de proyectos o arquitectos en pocos meses.

Espero no herir susceptibilidades ni establecer opiniones fanáticas, es una opinión muy personal: mucho cacique y poco desarrollador.

------------------

Un desarrollador de 20 millones mensuales

Por: Yuji Kiriki

Link: http://sis-temas.uniandes.edu.co/un-desarrollador-de-20-millones-mensuales/

Recibí la llamada de una amiga con la que hace años no hablaba. Con ella trabajamos en un proyecto big bang en el que debíamos automatizar cerca de 30 procesos de negocio hace ya más de 7 años.

Después de ponernos al día, le pregunté el motivo de su llamada. Me dijo que quería saber si ella me podría poner en su hoja de vida como referencia profesional, a lo que respondí afirmativamente. Luego le pregunté si estaba escribiendo software en algún proyecto. Me sorprendió notar un fuerte cambio de tono, casi de indignación e ira; me respondió: “Yo ya no escribo código. Hace mucho que ya no hago eso. Yo ya soy administrativa y estoy Gerenciando proyectos.”

Por otro lado me encontré con un compañero de la universidad. El recién se bajaba de su BMW (no creo que esto indique algo, pero quédense con la connotación esnobista del BMW para efectos de esta entrada). Hablamos, nos reímos y le pregunté a qué se había dedicado. Me respondió con orgullo “nada, usted sabe que a mi me gustaba mucho la parte técnica y era hasta bueno, pero me ofrecieron un cargo Comercial super bien remunerado y ando vendiendo el X producto de esta Y empresa Multinacional Super Reconocida.”.

Esta situación es muy curiosa. En mi trabajo me enfrento a muchísimos proyectos en clientes de varios dominios. A medida que pasa el tiempo me doy cuenta de que las organizaciones esperan más de las plataformas que desarrollamos. Es de esperarse, pues a medida que pasa el tiempo las personas del común van conociendo e interactuando con aplicaciones en línea que cada vez les ofrecen más comodidades, mayores facilidades u optimizaciones en la operación de sus negocios y su vida personal.

Por ejemplo cada vez es más común que nos pidan desarrollos con la disponibilidad de Facebook o con la simpleza y capacidad de respuesta Google. Inclusive nos han pedido colas de trabajo basadas en el comportamiento de Twitter. Es un hecho que los usuarios de las plataformas empresariales ya no son los que otrora se conformaban con lo que se les entregaba y eran completamente ignorantes del potencial de las TI.

Estos mismos usuarios son los que hoy en día se inventan requerimientos funcionales cada vez más interesantes. Y no sólo hablo de la experiencia de usuario, sino de reglas de negocio basadas en la evaluación de miles de eventos; o la detección de fraude en tiempo cercano al real; pueden ser reglas de negocio que se adapten al flujo de transacciones o que se autogeneren dadas ciertas condiciones de negocio. Sobra decir que estos desarrollos representan retos técnicos considerables.

Si el implementador es capaz de entregar este tipo de funcionalidad, el negocio será seguramente capaz de optimizar su costo de operación o de ofrecer servicios más interesantes a sus clientes. Muy seguramente este tipo de funcionalidad le permitirá a la organización diferenciarse frente a su competencia y posicionarse de mejor manera en el mercado. Posiblemente este conjunto de funcionalidades le permita a la organización abrir nuevos mercados o ganar terreno en el actual.

Ahora pregunto: ¿cuánto está dispuesta a pagar la organización por estas funcionalidades? ¿Le importaría que estas funcionalidades de negocio las desarrolle un joven recién graduado, que devenga al mes menos de $2’500.000 y que debe trabajar más de 12 horas al día, incluyendo sábados, para poder cumplir con un cronograma que definió un Gerente de Proyectos PMI y que acortó un VP por política y por mostrar resultados?

No sé en qué momento en Colombia ser desarrollador se volvió un trabajo, al parecer, de segunda clase. No sé en qué momento seguir siendo desarrollador se volvió sinónimo de no haber avanzado profesionalmente. Me sorprende que esto ocurra en el país si en países desarrollados este oficio es de los mejor pagados 1 o es considerado como uno de los mejores trabajos a realizar profesionalmente 2 debido a la autonomía, bienestar y salario que representan.

Es triste, pero no es raro ver las famosas y mal llamadas Fábricas de Software repletas de inexpertos e ignorantes 3 desarrolladores trasnochando de domingo a domingo entregando software hecho de la peor manera por cansancio, siguiendo metodologías rancias (RUP, TSP, PSP, ¿alguien?) y cumpliendo cronogramas políticos. No es raro que me llamen a prestar servicios de consultoría en proyectos donde el Arquitecto no tiene idea de desarrollo de software, pero sí de productos; lo que los lleva a implementar plataformas inviables.

¿Lo más triste de todo? Que estas plataformas supuestamente prestarán servicios a los ciudadanos o en teoría deberían optimizar la operación de una organización para ayudarla a cumplir con sus objetivos estratégicos.

Ah, la estrategia. Estos, podríamos decir, nuevos ricos llamados “Arquitectos Empresariales” que al ser tan “estratégicos” no tienen idea de software ni de tecnología pues saber de eso los ensucia o los avergüenza y terminan comprando productos porque están de moda o porque la competencia también los adquirió. Ríanse los documentos de justificación que se jalan estos personajes.

¿O qué me dicen de algunos Arquitectos que definen Arquitecturas de Solución pero que son incapaces de implementarlas, pues desarrollar software es una labor demasiado operativa y vulgar que debe ser tercerizada en alguna Fábrica de Software en India para que le cobren por hora hombre o punto de función (sólo nombrarlo da ganas de vomitar) y no por valor de negocio entregado?

Es un hecho que las plataformas de software son mecanismos a través de las cuales las organizaciones pueden innovar y pueden apalancar los objetivos estratégicos. Pero si estas plataformas son implementadas por personas sin experiencia o por personas mal valoradas ¿cuáles serán los resultados? ¿Será que esos resultados les alcanzarán a las empresas para lograr la innovación y el apalancamiento de la estrategia que buscan?

Es vital que nuestra industria empiece a entender que construir requerimientos funcionales no es lo mismo que echar cemento y pegar ladrillos (no es peyorativo, sólo quiero dar la connotación de que no es un oficio operativo). Es fundamental que nos saquemos de la cabeza que los desarrolladores son “recursos 4” intercambiables y explotables y que uno es capaz de hacer lo mismo que el otro.

La industria tiene que caer en cuenta que este oficio es profundamente artesanal y que el resultado de un proyecto depende casi en su totalidad de los artesanos que lo construyen. Entre mejor sea el artesano mejor será el producto. Si no me creen que es artesanal, métanse a Github 5 comparen proyectos y saquen sus conclusiones.

Por nuestra parte, como desarrolladores debemos empezar por respetar nuestro oficio estudiando, leyendo, compartiendo y publicando conocimiento. Debemos formarnos en la capacidad de escuchar, de entender y de proponer. Debemos volvernos diestros en entender una idea de negocio y de presentar la mejor alternativa técnica para llevarla a cabo.

Nosotros como desarrolladores somos el puente entre las ideas, las estrategias y su implementación en TI. También debemos esforzarnos por proponer ideas que abran nuevos mercados o que faciliten la penetración de los productos y servicios actuales. Recuerden Software Is Eating The World 6.

Como buenos desarrolladores debemos hacer valorar nuestro trabajo y explicarle a nuestros clientes que no es lo mismo un desarrollador juicioso con experiencia de 2 años que un desarrollador juicioso con 10 años de experiencia.

Imagínense: es como si compararan un experto en preparación de sushi con 2 años de experiencia con un experto en preparación de sushi con 10 años de experiencia. ¿Cuál pieza de sushi será más valorada suponiendo que ambos han invertido el mismo esfuerzo en ser cada día mejores? 7

Pienso que el tiempo nos dará la razón, pues a medida que las organizaciones dependan más de las plataformas de software, más valiosos deberán ser quienes las implementan. No es lo mismo implementar una aplicación que funciona a una que también funciona y que además es fácil de mantener y evolucionar. ¿Creen que la mantenibilidad de una aplicación depende completamente de la Arquitectura de Referencia o de un generador de código basado en modelos? Pues no mi querido Arquitecto PowerPoint. No.
Si los desarrolladores ven que si siguen en este oficio no van a avanzar profesionalmente porque ni la industria ni nuestros clientes los valoran por su experiencia ¿con qué tipo de desarrolladores se implementarán las retantes y poderosas plataformas de software necesarias en el futuro? ¿Con personas que no se han dedicado a ser maestros en su oficio y dirigidas por Arquitectos con asco a programar?

Para cerrar quisiera que me dijeran cómo se imaginan un desarrollador que devenga veinte millones de pesos mensuales. ¿Qué debería estar haciendo? ¿Qué experiencia debe tener? ¿Es demasiado irreal que en Colombia lleguemos a ese nivel?

¡Espero sus opiniones!

1. http://www.forbes.com/sites/jacquelynsmith/2012/12/06/the-top-jobs-for-2013/ ↩
2. http://www.forbes.com/pictures/efkk45mkkh/top-10-jobs-for-2013/ ↩
3. http://lema.rae.es/drae/?val=ignorante ↩
4. En serio, es demasiado ofensivo. ↩
5. https://github.com/ ↩
6. http://online.wsj.com/article/SB10001424053111903480904576512250915629460.html ↩
7. http://www.imdb.com/title/tt1772925/ ↩