Inocencia interrumpida

Hace unos días leí este mensaje de Graydon Hoare, el iniciador de Rust1:

I hear this sentiment (“code is meant to be read more than run”) a lot among programming communities and I’ve even repeated it myself but lately I wince seeing/hearing it repeated. I increasingly think it serves to obscure the economic realities of our occupation. Like it’s a story we like to tell ourselves to try to elevate us from proletarians to poets or something (…) And I think it’s actually not very true. Code can be written for reading, among people interested in that practice, but it’s mostly written for running, and even more-mostly written by someone being paid by someone else very interested in minimizing the cost of going from “nothing running” to “great, something is running” (…) Virtually none of the people paying for software ever want to read it.

El texto me provocó una serie de reacciones, que ahora quiero desmenuzar.

En primer lugar me puso en guardia, porque la opinión de que “el código es para las personas antes que para las máquinas” es una que yo sostengo, a veces exageradamente. En segundo lugar me hizo cuestionarme si esa opinión efectivamente conlleva cierta arrogancia, cierta pretensión de superioridad, como insinúa Hoare. Tiendo a creer que no: al menos en mi cabeza esa idea siempre coexistió con la de que somos plomeros digitales más que arquitectos o ingenieros; que nuestro trabajo es menos especial y menos valioso de lo que muchos suponen.

Ocurre que la informática es una disciplina relativamente joven, que en algunos aspectos tiene un grado de desarrollo pre-industrial: los programadores se parecen más a los artesanos de los talleres que a los trabajadores de las fábricas. El desarrollo tecnológico no alcanza (por ahora) para prescindir del componente intelectual humano; no es una tarea alienante y repetitiva a lo Tiempos Modernos sino que requiere intervención activa e incluso creativa del trabajador2. Y entiendo que este tipo de involucramiento en la actividad conlleva, al menos en algunas personas, un aprecio por el trabajo, una vocación de hacerlo bien separada de su retribución económica3. El programador que promueve el código legible (o que escribe tests o hace algún otro esfuerzo de “mantenibilidad”) no está maquillando su tarea para que parezca más interesante: está intentando honestamente hacer bien su trabajo.

La cuestión es que la definición de trabajo bien hecho la da el propio artesano: es subjetiva y puede no estar alineada con los intereses de quien lo paga. En esto creo que tiene razón Hoare: es fácil para nosotros enamorarnos del oficio, tratar de hacerlo bien según nuestro criterio, ignorando el marco económico en el que existe. Pero me parece que tampoco sirve la actitud opuesta: limitarse a cumplir una tarea sin compromiso, al menor costo posible. Creo que es obligación del desarrollador de software aceptar la tensión de intereses y buscar un equilibrio razonable.

De acuerdo con como yo aprendí el oficio —según ideas que cristalizaron alrededor del año 2000—, ese equilibrio se puede encontrar poniendo en primer plano a los usuarios del software que desarrollamos: teniendo siempre presente que el código no es un fin en sí mismo sino un medio para resolver problemas o proveer servicios. Por eso el movimiento Agile, antes de devenir culto religioso, ponía como máxima prioridad satisfacer al cliente4; por eso Extreme Programming proponía sentar al cliente al lado del equipo; por eso The Pragmatic Programmer nos pedía que deleitemos a nuestros usuarios en vez de limitarnos a entregar código5. El razonamiento era que, poniendo al software en términos de la utilidad que provee a los usuarios, el programador podía reconciliar su definición de trabajo bien hecho con la del mercado, disponía de una vara con la que medir costos y beneficios y orientar sus decisiones.

Aunque no me guste el ejemplo particular que usa Hoare, comparto su intención de cuestionar el sentido común del oficio y exponer las dinámicas socioeconómicas a las que responde. Fue la expresión “it’s a story we like to tell ourselves” —que traduzco: es una mentira que nos contamos a nosotros mismos— la que me hizo entrar en resonancia. Porque le terminó de dar forma a una idea que venía zumbando en mi cabeza: aquello de que nuestra tarea es resolverle los problemas a los usuarios también es una mentira que nos decimos a nosotros mismos, también es una forma de evadirnos de la realidades económicas que determinan nuestro trabajo.

∗ ∗ ∗

Basta observar el negocio del software moderno, el sistema de incentivos económicos que lo rige y el lugar en el que pone a los usuarios, para reconocer que aquella idea es hoy una fantasía. Tanto en las plataformas Big Tech como en los productos de las startups incipientes, lo que vale no es la experiencia del usuario sino el potencial de crecimiento: se diseñan sistemas sin saber qué servicio concreto proveen; se los prepara para escalar globalmente cuando apenas tienen usuarios; se acumulan usuarios antes de encontrar un modelo de negocio sustentable; se aceptan inversiones exageradas para el potencial de ganancias; se deteriora la experiencia de usuario para recuperar esas inversiones.

Este modus operandi de crecer a toda costa, buscar inversiones y preocuparse al final por generar ganancias —sostenido, presumo, por un contexto económico global que no estoy en condiciones de analizar— distorsiona las reglas del juego capitalista: ya no importa hacer un producto mejor y más barato que la competencia, importa construir un monopolio lo suficientemente rápido para impedir que la competencia llegue a existir o a tener posibilidades de supervivencia6.

Los casos de Google y Facebook son ejemplares. Las dos empresas empezaron ofreciendo productos gratuitos, con un discurso que priorizaba al usuario y rechazaba los ads; las dos, una vez adquirida su posición dominante, se constituyeron en las agencias de publicidad más grandes de la historia7.

Google se fundó alrededor de un buscador revolucionario que cambió la web para siempre. Era un producto que, en principio, no generaba ganancias, pero su superioridad tecnológica le valió a la empresa un flujo enorme de inversiones. Ningún otro de los productos de Google estuvo a la altura del buscador, pero eso no fue problema: con la financiación que obtuvo se dedicó a comprar lo que no podía desarrollar en casa: YouTube, Android, DoubleClick, Motorola, Waze, DeepMind8. De forma parecida, Zuckerberg, que compitió y se impuso a MySpace en la guerra de las redes sociales, se aseguró de que nadie le pudiera hacer a él lo mismo: aunque Facebook se haya vuelto un basurero, bastó con comprar a la competencia (WhatsApp, Instagram) para retener a los usuarios.

El buscador de Google funciona hoy sensiblemente peor que hace veinte años, y amenaza con empeorar9. Facebook se enmierdizó y supongo que Instagram, como diría Borges, corre el mismo albur. Ambas empresas constituyen monopolios explotadores de los que no podemos prescindir. En todos los casos el usuario es el producto y se lleva la peor parte.

∗ ∗ ∗

El supuesto de que ofrecerle un mejor servicio al usuario es la manera de aumentar el valor del software —que era una abstracción conveniente de las realidades económicas que motivaban su producción— dejó de ser cierto: ya no es una representación satisfactoria de la realidad. Hoy el beneficio económico pasa por otro lado. Pensábamos que el software tiene que deleitar al usuario pero la economía y buena parte de la industria nos exige que sucesivamente lo ignoremos, lo manipulemos y lo maltratemos. La neurosis del programador contemporáneo resulta de que pasó, en menos de una década, de tener una profesión demasiado buena para ser cierta a tener un bullshit job10: un trabajo que no produce valor tangible, que hace del mundo un lugar peor, que resulta difícil de justificar incluso en los términos tradicionales del capitalismo.

¿Cómo conseguirse un empleo honesto en sistemas, sin tener que cambiar primero el sistema? ¿Qué nos queda si sacamos los proyectos de software imaginario, las redes sociales de vigilancia, las agencias publicitarias encubiertas, los productos que le hacen la cama a sus usuarios, las blockchains cuyos promotores oscilan entre el delirio místico y la estafa, la Inteligencia Alucinógena que riega con basura toda la web? ¿Existe todavía algún kibutz para deleitar a los usuarios sin corromperlos y sin engañarlos?

Elijo creer que sí. Consumidores de software no faltan. Necesidades tampoco.

Notas

1 El mensaje original fue borrado, pero se puede leer el texto completo acá.

2 En ese sentido cabe la comparación con otros oficios, sin pretensión de superioridad. La alusión al poeta que hace Hoare incurre en la romantización del oficio de escritor: la suposición de que consiste apenas en transcribir lo que dicta la inspiración cuando, en realidad, tiene mucho de pico y pala, prueba y error, sangre, sudor y lágrimas.

3 La sublimación, que le dicen.

4 Principles behind the Agile Manifesto.

5 Por eso los programadores de LucasArts organizaban “orgías de pizza” para que amigos y familiares prueben los juegos en desarrollo; por eso los de Midway ponían versiones preliminares del NBA Jam en un arcade del barrio para ver cómo reaccionaban los jugadores.

6 “Metaverse” means “pivot to video”.

7 Es curioso que los ads sean la solución preferida para improvisarle un modelo de negocio a los servicios de software: según el libro Subprime Attention Crisis, la industria de los ads se funda en supuestos incomprobables y conforma también una burbuja esperando por estallar.

8 List of mergers and acquisitions by Alphabet.

9 Google’s AI Hype Circle.

10 On the Phenomenon of Bullshit Jobs.



12/10/2023 #software
source | comments

Facundo Olano La mentira que nos contamos a nosotros mismos.