El software vuelve loca a la gente
Software Drives People Insane
El software combina velocidad, dinero, complejidad y una libertad casi ilimitada para cambiar de opinión, y eso puede hacer que personas normales pierdan el sentido de la proporción. El autor sostiene que la mayoría del software es un simple spreadsheet glorificado, pero la facilidad para cambiar cosas sin fricción visible genera urgencia constante, complejidad innecesaria y una cultura hostil a la paciencia. La solución no es ir más despacio, sino recuperar la proporción.
La mayoría del software, cuando le quitas la marca y los diagramas de arquitectura, es notablemente aburrido. Un formulario por aquí, un endpoint de API por allá, espolvorea algunos permisos, cálculos, flujos de trabajo y una base de datos en algún lugar. Pero, por duro que suene: la mayoría del software sigue siendo solo un spreadsheet glorificado.
- bob1029
El desarrollo de software desvinculado de las realidades prácticas del cliente / usuario es lo que vuelve loca a la gente.
Cuando se exige a los desarrolladores que interactúen con el cliente de forma regular, los efectos descontrolados que describe este artículo se atenúan enormemente.
El potencial de locura se dispara cuando el equipo de desarrollo está aislado en confinamiento solitario y las únicas interacciones con el cliente ocurren a través de una especie de guardia de prisión conocido como "project manager" que desliza notas por debajo de la puerta.
Trabajar con el cliente a veces apesta. Igual que hacer ejercicio y comer verduras a veces apesta. Es una infelicidad temporal que nos mantiene con los pies en la realidad.
- hliyan
Estaba a punto de publicar esta reflexión en el último post de "Nos estamos moviendo de la tecnología/arquitectura X a Y" en la portada de HN hoy, pero ahora siento que pertenece aquí.
Hace poco estaba charlando con un amigo sobre cómo solíamos hacer mucho más con tan pocos desarrolladores: hace 20 años, desarrollábamos software crítico y en tiempo real (sistemas de trading) en C++ con un equipo de un par de docenas de desarrolladores. El equipo central del kernel de trading era de cuatro personas. Una herramienta interna de orquestación de procesos distribuidos (tanto front end como back end escrita en C++) eran dos tipos. Yo mismo una vez logré producir un sistema completo de gestión de riesgo post-negociación para contratos de futuros en un par de meses, trabajando solo. Hoy veo equipos de 60-80 trabajando en aplicaciones web y móviles donde la gran mayoría de las operaciones son CRUD, con algo de complejidad de transacciones/colas en los extremos.
Creo que la diferencia es la rotación tecnológica. En aquel entonces, las pocas dependencias que teníamos, ya fueran bibliotecas de tiempo de ejecución o herramientas de tiempo de desarrollo, eran estables: la biblioteca estándar, el compilador, los comandos de unix y scripts de bash, y algunas bibliotecas internas. Gran parte de nuestro tiempo y enfoque se destinaba a encontrar los algoritmos y estructuras de datos correctos, con la codificación en segundo lugar. Se dedicaba muy poco tiempo a seleccionar, configurar, actualizar, rearquitecturar o reemplazar stacks tecnológicos y herramientas.
- tcdent
El OP prácticamente ha observado el efecto del Ego a través del software, pero aún no ha llegado a la capacidad de cuantificarlo.
Vuelve a leer y aplica cada ejemplo dado a través de esa lente.
Es posible que estemos en una industria que expresa desproporcionadamente esta parte de la naturaleza humana, pero estoy bastante seguro de que aparece en todas partes aunque con anécdotas diferentes. Aplica una visión reduccionista del budismo Zen a tu creatividad profesional y todo esto desaparece.
Bob quiere refactorizar un subsistema porque lo convertirá en un héroe, y si lo posiciona correctamente ante la dirección, el mérito técnico y el nivel real de éxito alcanzado serán irrelevantes. Alice elige sacar a relucir algunas preocupaciones obvias y luego sentarse a ver el espectáculo. Jane elige tirar la toalla en el stand-up e intentar convencer emocionalmente a todos de que el cielo se caerá. Sé como Alice y preserva tu cordura.
- randusername
Mi observación es simplemente que los líderes tecnológicos malinterpretan las recompensas del mercado al conquistar alguna representación abstracta de una faceta de un dominio con conquistar el dominio en sí. Luego se vuelven ególatras.
¿Conquistaste el sector inmobiliario comercial inaugurando el futuro del trabajo y la sociedad, o construiste una práctica aplicación de programación?
¿Tuviste una idea ingeniosa para una comunidad en línea o revolucionaste la conexión humana?
- Terr_
Me recuerda a este post de 2014 "Programming Sucks" [0], que toca algunos problemas similares de desconexión de la realidad en un microcosmos que siempre "debería" ser mejor de lo que es.
> Todos los equipos de programación están construidos por y de gente loca [...]
> El impacto destructivo en el cerebro se demuestra por los lenguajes de programación que la gente escribe. [...]
> Todos los programadores están forzando sus cerebros a hacer cosas que los cerebros nunca debieron hacer en una situación que nunca podrán mejorar, de diez a quince horas al día, de cinco a siete días a la semana, y cada uno de ellos se está volviendo loco lentamente.
- cestith
¿Es el software el que tiene este efecto o la gestión sobre los productos de software? No veo muchos proyectos de software académicos o de hobby cambiando constantemente lo que les importa por capricho. Sin embargo, se puede ver todo el tiempo en la industria del software.
- anigbrowl
No es el software; es el hecho de que la mayoría de los gerentes/administradores no son desarrolladores de software (aunque puedan tener alguna habilidad de programación). Así que están en la misma relación con su equipo de desarrollo que los clientes que se quejan a un fabricante sobre las características de un producto físico, y dicen 'debería hacer esto o aquello, es un cambio fácil de hacer' (porque es fácil imaginar tenerlo si te saltas la tediosa tarea de tener que implementarlo).
Por supuesto, a veces la petición está justificada y aborda algún fallo de la especificación original, ya sea por falta de ambición o por exceso de ambición que enganchó un contenedor de carga a un motor de cortacésped. Pero la mayor parte del conflicto que describe el artículo proviene de una combinación de imaginar los beneficios del cambio con la suposición tácita de que la implementación es solo cuestión de pulsar unos cuantos botones más.
- msteffen
Me encanta este enfoque. Tengo muchas ideas sobre por qué esto es cierto, pero la mejor explicación sencilla (en mi opinión) que he podido encontrar es:
1. Gran parte de la construcción de software es matemáticas de algún tipo. En matemáticas, escribes demostraciones que dicen por qué X es verdadero. En software, escribes código que garantiza que X será verdadero (por ejemplo, "el backend asumía que un ID de usuario siempre estaba disponible, pero ahora que tenemos cuentas de servicio, necesitamos cambiar el código de control de acceso para que aún se devuelva una vista sensata")
2. Las matemáticas son difíciles, y la mayor parte del trabajo es pensamiento invisible. Si le pidieras a un matemático una estimación de cuándo se probará la hipótesis de Riemann, se reiría de ti. Nuestros problemas son generalmente más fáciles, pero aún pueden ser difíciles. Y como en matemáticas, a veces son mucho más difíciles de lo que esperas (por ejemplo, el Último Teorema de Fermat. "¿Por qué fue tan difícil? ¿Hablaste con Fermat? ¿Se fue? ¡Pero dijo que sería fácil!")