Nunca te enseñan cómo construir software de calidad

Artículo original ↗ Discusión en Hacker News ↗

Muchos ingenieros sostienen que la educación en informática y las prácticas típicas de prácticas profesionales se centran en algoritmos y en entregar funciones, mientras ofrecen poca formación sistemática en la calidad del software, las pruebas y la mantenibilidad a largo plazo. Quienes comentan lo contrastan con campos como la aviación y la fabricación, que incorporan QA riguroso y procesos de postmortem, pero señalan que esas prácticas son costosas y a menudo chocan con los incentivos empresariales de moverse rápido. El debate se centra en si la “calidad” puede enseñarse formalmente, cuánto solo puede aprenderse con la experiencia y cómo justificar el trabajo de QA en organizaciones que optimizan principalmente para la velocidad y los resultados a corto plazo.

Qué significa “software de calidad” (y si se puede enseñar)

  • Muchos sostienen que “calidad” es un término vago: ¿es fiabilidad, rendimiento, mantenibilidad, UX o valor de negocio?
  • Algunos dicen que la calidad se aprende sobre todo mediante la práctica y la retroalimentación, no con teoría de aula.
  • Otros insisten en que sí existe una disciplina académica y de ingeniería (ingeniería de software, QA, métodos formales) que enseña calidad, pero su adopción es desigual.

Comparaciones con otros campos (aviación, fabricación, ingeniería)

  • La aviación y la fabricación se citan como ejemplos en los que la calidad se enseña sistemáticamente mediante listas de verificación, regulación, revisiones de incidentes y controles de proceso.
  • Algunos sugieren que una lista de verificación comparable de 500 elementos para software reduciría drásticamente los errores, pero mataría la velocidad al estilo startup.
  • Contraargumento: incluso en la ingeniería “dura”, los defectos, retiradas y fallos son comunes; todo es “suficientemente bueno”, no perfecto.

CS universitario vs. Ingeniería de Software

  • Queja recurrente: los programas de CS se centran en algoritmos, compiladores, teoría y sistemas de bajo nivel, pero apenas en QA, pruebas, estrategia de depuración o diseño de sistemas a gran escala.
  • Otros cuentan haber cursado asignaturas serias de ingeniería de software: pruebas, SDLC, UML, proyectos en equipo, proyectos finales que simulan el mantenimiento del mundo real.
  • Hay debate sobre si las universidades deberían ser formación para el trabajo o educación pura, especialmente por el aumento de las matrículas y las expectativas laborales.

QA, pruebas y proceso

  • Tema fuerte: QA a menudo se añade al final (o se omite) por presión de calendario; las “QA sprints” y las pruebas tardías se señalan como antipatrón.
  • Quienes lo defienden proponen: pruebas escritas junto con el código, CI/CD, automatización, pruebas de instantáneas/visuales, cobertura más pruebas de mutación/fuzz, y métricas cuidadosas (con conciencia de la ley de Goodhart).
  • Algunos señalan que existen equipos de alta calidad donde el 40–60% del esfuerzo se dedica a pruebas y trabajo de calidad, pero no son la norma.

Errores, afirmaciones de “sin bugs” y métodos formales

  • Consenso: el software absolutamente libre de bugs es prácticamente inalcanzable más allá de programas triviales; “cero bugs” se ve mejor como una asíntota o como “sin defectos conocidos frente a una especificación”.
  • Debate sobre las definiciones de “bug” (desviación de la especificación vs. cualquier comportamiento inesperado) y sobre si los errores de especificación cuentan.
  • Los métodos formales y las pruebas pueden eliminar clases de defectos en dominios críticos para la seguridad, pero son caros, de alcance limitado y no arreglan especificaciones malas o incompletas.

Economía, incentivos y compensaciones

  • Muchos señalan que la dirección suele priorizar la velocidad y las funciones visibles por encima de la calidad porque las métricas de negocio rara vez recompensan la mantenibilidad a largo plazo.
  • Los costes de calidad son difusos y tardíos (deuda técnica, equipos más lentos, tiempo desperdiciado de los usuarios), mientras que el coste de desarrollo es inmediato y medible.
  • Algunos sostienen que, a gran escala, incluso los errores “raros” se vuelven comunes y provocan una “muerte por mil cortes”, pero otros afirman que la mayoría de los mercados tolera software mediocre si sale rápido y resuelve un problema.