Estamos arruinando el software

• Estamos arruinando el software al dejar de considerar la complejidad cuando agregamos funciones u optimizamos partes específicas
• Estamos arruinando el software con sistemas de compilación complejos
• Estamos arruinando el software al volver todo inflado y frágil con cadenas de dependencias absurdas
• Estamos arruinando el software al decirles a los nuevos programadores: "Don’t reinvent the wheel!". Pero reinventar la rueda es una forma de aprender cómo funcionan las cosas y el primer paso para crear una rueda nueva y diferente
• Estamos arruinando el software al dejar de considerar la compatibilidad hacia atrás de las API
• Estamos arruinando el software al presionar para reescribir cosas que ya funcionan
• Estamos arruinando el software al lanzarnos sobre cada nuevo lenguaje, paradigma y framework que aparece
• Estamos arruinando el software al subestimar siempre la dificultad de lidiar con bibliotecas complejas ya existentes en comparación con implementarlo nosotros mismos
• Estamos arruinando el software al asumir que el estándar de facto XYZ siempre es mejor que algo que podríamos implementar directamente para nuestro caso de uso específico
• Estamos arruinando el software al afirmar que los comentarios en el código no sirven para nada
• Estamos arruinando el software al confundirlo con una disciplina puramente de ingeniería
• Estamos arruinando el software al crear sistemas que ya no pueden reducirse: en cualquier sistema, lo simple debería poder lograrse de forma simple
• Estamos arruinando el software al intentar producir código lo más rápido posible sin esforzarnos por hacer el código lo mejor diseñado posible
• Estamos arruinando el software, y lo que quedará ya no ofrecerá la diversión de hackear

[dohyun682]

Reinventar la rueda <-> reinventar lo que ya se está escribiendo

¿No son estos dos conceptos completamente opuestos entre sí?

[roxie]

Se viene el boom de los comentarios.

[tujuc]

Me pega bastante jajaja. Cada vez que entran los más nuevos... he estado pensando en cómo enseñarles, y creo que puede ser una buena forma.

[ilikeall]

Dejen de golpearlo ;_;

[bus710]

....Me quedaré quieto...

[laeyoung]

Parece que hay bastante que se superpone con las “10 señales de que un país se arruina” que decía Han Feizi.

[GN⁺]

Comentarios en Hacker News

• Hace recordar una charla de Jonathan Blow. El software, si no se cuida, se deteriora como cualquier otra cosa

  • La tecnología de software parece avanzar en la superficie, pero en realidad está en decadencia
  • Las mejoras de hardware y el aprendizaje automático dan una ilusión de progreso, pero la solidez y confiabilidad fundamentales del software están empeorando
  • El desarrollo de software moderno se ha vuelto innecesariamente complejo, haciendo difíciles incluso las tareas simples
  • Esta complejidad reduce la productividad de los programadores y dificulta la transmisión de conocimiento entre generaciones
  • La sociedad termina aceptando como normal un software lleno de errores y poco confiable
  • Si no simplificamos los sistemas de software en todos los niveles, desde el sistema operativo hasta las herramientas de desarrollo, la civilización enfrenta el riesgo de un retroceso tecnológico similar a colapsos históricos

• Hace recordar los "10 principios del buen diseño" de Dieter Rams

  • El buen diseño es innovador
  • El buen diseño hace útil a un producto
  • El buen diseño es estético
  • El buen diseño hace que un producto sea fácil de entender
  • El buen diseño es discreto
  • El buen diseño es honesto
  • El buen diseño dura mucho tiempo
  • El buen diseño es minucioso hasta el último detalle
  • El buen diseño es amigable con el medio ambiente
  • El buen diseño es la menor cantidad de diseño posible

• Comparte una experiencia trabajando en una empresa en los 2000

  • Realizaban trabajo con decenas de computadoras, montaban una sala de servidores y construían una SAN para almacenar 3 TB de datos
  • Coordinaban tareas entre computadoras ejecutando scripts de Object Rexx con un programador de tareas hecho en casa en VB6
  • Usaban un balanceador de carga interno, servidor web, servidor de correo y servidor FTP para enviar y recibir archivos, además de software propio
  • Ahora toda esa configuración puede reproducirse en menos de una semana con archivos yaml y servicios en la nube
  • La arquitectura de servidores se ha "abstraído"
  • Crítica a la compatibilidad hacia atrás, señalándola como uno de los problemas de Windows
  • Apple rompió compatibilidad hacia atrás, hizo la transición entre 5 procesadores y eliminó la compatibilidad con código de 32 bits en chips ARM

• Hay muchas opiniones contrapuestas

  • Hay que mantener la compatibilidad hacia atrás evitando la complejidad
  • Hay que evitar árboles gigantes de dependencias y reinventar la rueda uno mismo
  • La única forma de satisfacer todos los requisitos es que no todo el mundo escriba código
  • Hay días en que uno desea que así sea, aunque no es algo de lo que sentirse orgulloso

• Comparte una experiencia en su primer trabajo

  • Escribían software en C, y era el único lenguaje con el que de manera realista se podía escribir software comercial
  • Solo una persona podía hacer builds, usaban una herramienta comercial de compilación y era la única persona que sabía usarla
  • Los builds tardaban horas
  • Creían que lo estaban haciendo bien

• Opinión sobre por qué estamos destruyendo el software

  • Destruimos el software al pensar siempre que el estándar de facto de XYZ es mejor que algo adaptado a nuestras necesidades
  • Un enfoque general suele poder cambiarse fácilmente por soluciones superficiales para muchos problemas
  • A los técnicos les gusta este enfoque, sobre todo porque cambian de trabajo con frecuencia, así que tienen varios de estos ejemplos
  • Pero las soluciones a medida rinden mucho mejor que las genéricas

• Toda afirmación es un intercambio

  • En todos los casos se sacrifica algo para obtener otra cosa
  • A veces tiene sentido no reinventar la rueda
  • A veces hay que reinventar la rueda para aprender
  • En general, estamos creando más de lo que destruimos
  • No siente la necesidad de adoptar una postura negativa

• Respeta a antirez, pero cree que esta publicación está llena de afirmaciones cortas que suenan bien y no se sostienen en una discusión

  • Ejemplo: los principiantes no deberían reinventar la rueda
  • Deberían usar las herramientas disponibles en el contexto dado
  • Si quieren experimentar, deberían escribir su propio compilador
  • Pero no deberían usarlo en producción
  • La compatibilidad inversa de API es en la mayoría de los casos una decisión de negocio
  • Empezar todas las frases con "estamos destruyendo el software" no ayuda
  • Suena mucho más sombrío de lo que realmente es

• Opinión sobre la complejidad/el grafo de dependencias

  • El grafo de complejidad/dependencias de una aplicación cualquiera es absolutamente demencial
  • No incluye el firmware ni el sistema operativo, pero está lo bastante cerca
  • Hay que resolver el problema de las dependencias transitivas
  • Considera al SO (API de Win32, syscalls de Linux) como la única dependencia dura de todo lo escrito en C
  • Al pasarse a Java/Python, ya no se puede controlar esa capa
  • Hace falta escribir algunos cientos de líneas de código ajustadas a una situación específica en vez de depender de todas las librerías
  • La carga de mantenimiento aumenta, pero las dependencias también requieren mantenimiento
  • Pueden tener APIs malas, romper compatibilidad al azar, quedar abandonadas o convertirse en malware
  • Su máximo personal de líneas para un proyecto útil es 5-10 KLOC en Java/JS/Python
  • Puede revisarse en unas horas y modificarse fácilmente años después

• Elementos que destruyen el software

  • Entrevistas tipo Leetcode, desarrollo guiado por el currículum, cambios frecuentes de trabajo, fraude de inversión de crecimiento, manipulación de métricas, búsqueda de ascensos, teatro de sprint, fanfarronería en todos los niveles del organigrama, apatía de la industria