La nostalgia por VB6: cuando la productividad no necesitaba un framework
Un hilo en Hacker News revive una pregunta incómoda: ¿por qué Visual Basic 6, un lenguaje de hace 25 años, sigue siendo recordado como el pináculo de la productividad en desarrollo de software? La respuesta revela más sobre nuestra relación actual con la tecnología que sobre el propio VB6.
Por qué importa
El desarrollador promedio hoy pasa más tiempo configurando herramientas que escribiendo lógica de negocio. React, Redux, TypeScript, Webpack, Docker… cada capa añade abstracción, pero también fricción. VB6 demostró que se podía construir una aplicación CRUD completa en una tarde, con binding a base de datos, ordenamiento y navegación. El resto de la semana se dedicaba a lo que realmente importa: la lógica del negocio.
Para el lector de Puro Flusso, esta nostalgia no es técnica: es una señal de alarma. Si la herramienta que usas te exige más atención que el problema que resuelves, algo está mal. La productividad no es cuántas líneas escribes, sino cuánto valor entregas por unidad de atención invertida.
Qué dice el contexto
- VB6 fue el lenguaje más productivo de su era: con data-bound controls, arrastrar y soltar, y un IDE integrado, un desarrollador podía crear una aplicación conectada a base de datos en horas, no en sprints.
- Microsoft ya no lo soporta oficialmente: los runtime de VB6 aún funcionan en Windows 10/11, pero la falta de actualizaciones y la dependencia de COM/DCOM lo convierten en un riesgo para sistemas críticos.
- La modernización es costosa: migrar código VB6 a .NET requiere reescribir desde cero, y muchas empresas aún mantienen millones de líneas en VB6 por el costo de la transición.
- El mito del “it just works”: aunque Microsoft garantiza compatibilidad, la realidad es que las aplicaciones VB6 fallan en entornos modernos por problemas de seguridad, permisos y dependencias obsoletas.
- La nostalgia es selectiva: se recuerda la velocidad de desarrollo, pero se olvida la falta de soporte para pruebas unitarias, control de versiones, escalabilidad web o seguridad moderna.
Lo que puedes hacer
- Audita tus herramientas: haz una lista de las tecnologías que usas a diario. Pregúntate: ¿cuánto tiempo dedico a configurarlas vs. a resolver el problema real? Si el ratio supera 1:1, busca alternativas más simples.
- Prioriza el “suficientemente bueno”: no necesitas el último framework para una app interna. Un script en Python, una hoja de cálculo o incluso una app low-code pueden ser más productivos que una arquitectura de microservicios.
- Revisa tu stack con ojos de VB6: imagina que pudieras construir la misma funcionalidad en una tarde. ¿Qué estarías haciendo diferente? Esa diferencia es tu fricción oculta.
En una frase
“
La productividad real no está en cuántas herramientas dominas, sino en cuánto valor entregas antes de que tu atención se agote.
