Agile está matando la innovación en software

• En la conferencia Black Hat, Moxie Marlinspike, fundador de Signal, sostuvo que en los últimos 20 años la innovación en software ha desaparecido debido al desarrollo ágil
• Señaló que los desarrolladores han quedado atrapados en "capas de abstracción de caja negra" y han perdido la libertad necesaria para innovar
• "Cualquiera que gestione una organización de ingeniería probablemente tenga una filosofía de gestión que sea un subconcepto de Agile, un concepto derivado, algo dentro del ámbito de Agile, o de alguna manera relacionado con Agile"
  • En lugar de avanzar de abajo hacia arriba, combinando la experiencia técnica de ingeniería con una visión para detectar nuevas posibilidades en las tecnologías existentes,
    afirmó que los equipos Agile quedan aislados en silos, trabajando por separado y sin poder entender qué están haciendo los demás equipos
• Además, en la sesión de cierre, Window Snyder, fundadora y CEO de Thistle Technologies, agregó que estos equipos de caja negra también tienden a carecer de visibilidad sobre los principios con los que funcionan sus propios productos
  • Snyder también argumentó que los estudiantes que aprenden programación no están aprendiendo a interactuar con lenguajes de bajo nivel ni con código máquina, sino solo con lenguajes de alto nivel que facilitan el desarrollo de apps, por lo que a los ingenieros les falta el contexto necesario para entender cómo encajan las piezas dentro de un todo más grande

Los investigadores de seguridad tienen la llave de la innovación

• Marlinspike también comentó que, mientras la ingeniería de software se ha ido abstrayendo durante las últimas décadas para volverse más rápida, más flexible y avanzar más, los investigadores de seguridad han intentado mirar más allá de la abstracción
  • "La seguridad es el proceso de mirar dentro de lo abstracto para entender cómo funciona realmente, qué hay debajo de ello y, a veces, comprenderlo mejor que quien lo creó en primer lugar"
• Por eso sostiene que los investigadores de seguridad tienen la llave para impulsar nuevas innovaciones
• Incluso comparó entender el software con entender la magia, y describió a los expertos en seguridad como "personas sentadas en una biblioteca estudiando magia"

Opinión de GN⁺

• Fueron comentarios perspicaces de Marlinspike, señalando con agudeza los problemas fundamentales de Agile
• Resulta fácil coincidir en que, por obsesionarse solo con la abstracción y la velocidad de desarrollo, los desarrolladores están dejando de conocer cada vez más los conceptos básicos
• También fue llamativo que pusiera el foco en el papel de los investigadores de seguridad. Como la seguridad consiste en escarbar en la realidad oculta detrás de la abstracción, puede convertirse en una fuerza impulsora de la innovación
• En cierto sentido, transmite el mensaje de que los ingenieros de software deberían buscar una comprensión más profunda
• Las ventajas de Agile también existen claramente, así que será necesario un enfoque equilibrado. Habrá que buscar formas de mantener la agilidad y flexibilidad de Agile mientras se refuerzan bien los fundamentos
• Para ello, será necesario mejorar desde el currículo de formación para desarrolladores. Habrá que fortalecer la enseñanza de materias básicas como lenguajes de bajo nivel y arquitectura de computadoras, no solo lenguajes de alto nivel

[jeokrang]

Parece que están confundiendo los problemas de los gerentes que malinterpretaron Agile con problemas de Agile en sí.

[yangeok]

Parece que, siguiendo la corriente de la época, como aprender conocimientos de bajo nivel no genera ROI, terminamos aprendiendo solo conocimientos de alto nivel.

[andrewchaa]

No entiendo por qué se la agarran con Agile...

[lordang]

Me confunde que se estén mezclando los conceptos de north-south y east-west al hablar del tema.
Parece que el problema de no saber qué hace otro equipo tiene más que ver con una estructura organizacional cross-functional que con Agile en sí.

En cuanto a no conocer bien el low level, por lo que dice el texto suena más a algo como “en ese caso también tienden a no conocer bien el low level”.

Aunque concedamos que no saber qué hace otro equipo tiene aunque sea un poco de relación con Agile, no logro entender qué tiene que ver Agile con no conocer el low level jajaja

[lordang]

Si nos ponemos estrictos, más bien con la adopción masiva del open source ya no hace falta construir todo desde cero, no se reinventa la rueda, y como en la parte low level simplemente se usa lo que ya existe, lo más cercano sería decir que ya no se estudia porque no hace falta.

Si tratamos de entender ese comentario, podría interpretarse como que por culpa de Agile solo se busca hacer las cosas rápido y por eso no se estudia low level, algo así, pero me parece que sería más correcto decir que no se hace porque no es necesario.

[bbulbum]

Creo que se está dejando de lado elegir con una perspectiva amplia sobre los problemas y de una forma que permita la sostenibilidad a largo plazo en nombre de lo ágil, y que esto también, desde la perspectiva del software, está haciendo que nos concentremos solo en resolver los problemas que tenemos enfrente.
Poner algo a funcionar primero sin más no sería necesariamente algo ágil, pero sí parece haber una tendencia a tomar decisiones muy centradas en la velocidad, y creo que eso puede convertirse en un factor que dificulte buscar una comprensión profunda.

[savvykang]

No entiendo por qué intentan buscar en Agile la causa del problema de que las organizaciones de ingeniería no tengan poder de decisión.

[galadbran]

Qué tiene que ver Agile con una situación en la que no sabes qué están haciendo los otros equipos... ;;;

Pero el nombre Window Snyder sí que es bastante peculiar...

[xguru]

Quisiera ver el video original, pero todavía no está. Supongo que en algún momento lo subirán al YouTube oficial.
https://www.youtube.com/@BlackHatOfficialYT/

[GN⁺]

Opiniones de Hacker News

• La raíz del problema es la estructura empresarial moderna

  • Existe una teoría moderna de gestión según la cual la responsabilidad y la toma de decisiones deben escalar por la jerarquía corporativa
  • Se considera que los empleados de niveles inferiores son quienes menos saben sobre el producto
  • Pero en la práctica, quienes trabajan en primera línea son los que más información tienen
  • Si la ingeniería de software se convierte en un proceso de línea de ensamblaje, la innovación se detiene
  • Una jerarquía de gestión completamente igualitaria no es la respuesta, pero hace falta una forma de no dejar sin poder a quienes están en primera línea
  • El libro <i>Reinventing Organisations</i> explica estructuras empresariales innovadoras

• Las buenas ideas de Agile fueron absorbidas por la ingeniería de software general

  • Se suele pensar que un programador ágil es alguien que sigue reuniones standup estrictas, tableros Kanban, etc.
  • No creo que Agile haya causado la fragmentación del conocimiento ni la degradación técnica de la ingeniería de software
  • Es un problema surgido por la tendencia hacia la producción en masa
  • Se observan fenómenos parecidos en automotrices y fábricas de muebles

• Quejas sobre Agile, Scrum y los OKR

  • Todos prometen trasladar libertad y responsabilidad a los empleados de niveles inferiores, pero en la práctica se centralizan
  • Me gustaría probar aplicar los OKR al revés
  • Cada empleado debería definir los resultados clave en su propia área, y los gerentes deberían fijar la dirección del equipo a partir de eso
  • Se necesita un enfoque de abajo hacia arriba, no de arriba hacia abajo
  • Hay que contratar bien, capacitar bien y confiar en los empleados

• Experiencia en una reunión de refinamiento de backlog

  • Tuve que estimar la corrección de un bug en un código que no conocía
  • Como era difícil estimarlo, terminé diciendo un número al tanteo
  • Agile funcionaba de manera parecida en tres lugares distintos

• Una teoría sobre los problemas de Agile

  • Dividir el trabajo en partes pequeñas es útil, pero programar requiere creatividad
  • En el proceso de dividir el trabajo, se pierde mucha información
  • Los desarrolladores necesitan encontrar soluciones creativas, pero no obtienen la información necesaria
  • Se necesitan desarrolladores con más experiencia o mejores diagramas de diseño y documentación

• Deterioro de la calidad del software

  • El software ha empeorado durante las últimas décadas
  • Usamos máquinas más potentes, pero con menor capacidad de respuesta
  • Podría estar relacionado con el auge de Agile

• Hay que permitir que los ingenieros "sean dueños" de partes del código

  • Fue la época en que el software del equipo era mejor

• Experiencia evitando las reuniones diarias de standup

  • Las retrospectivas constantes y la división del trabajo eran ineficientes
  • Solo beneficiaban a los gerentes no técnicos

• Problemas de las organizaciones grandes

  • Los desarrolladores ya no lideran
  • La visión, el producto, la UX y la gestión de proyectos se deciden desde arriba
  • Los desarrolladores trabajan usando tecnologías cloud
  • No pueden entender el panorama completo ni hacer propuestas importantes

• Opinión de que hay que recuperar la "magia" del desarrollo de software

  • Se nota que ha estado en la industria por más de 20 años
  • Si pasas tiempo con programadores jóvenes, esa magia todavía existe
  • Hace 20 años ya había quejas parecidas, pero aun así seguíamos trabajando con entusiasmo

[savvykang]

> Existe una teoría moderna de gestión que dice que la responsabilidad y la toma de decisiones deben escalar siguiendo la jerarquía corporativa.

¿No es esta una característica de una organización burocratizada?