En nuestra industria, es común revisar un sistema y decir algo como “esto se podría haber hecho mejor”. La gente señala problemas, critica decisiones arquitectónicas, cuestiona detalles de implementación. Y más seguido de lo que parece, la conclusión es rehacer todo desde cero—sin antes intentar entender qué se hizo, por qué, y bajo qué condiciones.
Ese tipo de reacción puede sonar profesional—incluso segura. Pero muchas veces, no lo es. No porque esté mal señalar problemas—eso es parte del trabajo—sino porque hacerlo sin contexto suele ser una forma superficial de evaluar un proyecto. Es fácil asumir que lo que no construimos está mal. Mucho más difícil es entender el razonamiento detrás de una solución que no diseñamos.
Casi ningún software se construye bajo condiciones ideales. Plazos ajustados, alcances cambiantes, presiones del negocio, recursos limitados o restricciones externas suelen influir en el resultado. Quienes llegan después—muchas veces con más tiempo o perspectiva—pueden ver cosas que harían distinto. Pero eso no significa que lo que se hizo esté mal.
Para entender, hay que hacer preguntas que el código por sí solo no puede responder: ¿Qué información se tenía en ese momento? ¿Qué necesidades buscaba resolver esta solución? ¿Había restricciones que ya no aplican? ¿El objetivo era moverse rápido o construir algo para el largo plazo?
Evaluar un sistema sin entender su contexto técnico, organizacional o de negocio es como criticar un puente sin conocer el terreno, el presupuesto o la urgencia detrás de su construcción.
Cuando “esto no sirve, rehagámoslo” se convierte en el enfoque por defecto, es fácil pasar por alto valor real. Aunque algo no haya sido construido como lo haríamos hoy, puede contener decisiones inteligentes, conocimiento acumulado o simplemente… funcionar.
Empezar de cero puede sonar más limpio, más profesional. Pero descartar sin entender suele ser más riesgoso, lento y costoso que adaptar con criterio. Reescribir todo no garantiza un mejor resultado. A veces, es solo una excusa para evitar el trabajo difícil de comprender.
Eso no significa que debamos preservar lo inmantenible. Solo que necesitamos criterio—y eso solo se logra mirando con atención.
Ser ético en software no significa evitar la crítica. Significa hacerla desde una posición informada, constructiva y respetuosa. Significa reconocer que cada línea de código implicó decisiones reales, presiones reales y personas reales. No todas las decisiones fueron correctas. Pero pocas fueron tomadas con ignorancia total.
La ética también se refleja en cómo entregamos un diagnóstico, en la humildad para admitir lo que no sabemos, y en la capacidad de guiar mejoras sin descartar todo lo que vino antes.
En 301, valoramos tanto el análisis técnico como el respeto por el trabajo previo. Cuando tomamos un proyecto con una base de código existente, no asumimos que todo debe ser reemplazado. Y tampoco asumimos que todo debe mantenerse. Lo abordamos con una evaluación clara y equilibrada. Nuestro enfoque se basa en tres principios clave:
- Escuchar antes de actuar. Hablamos con quienes estuvieron involucrados, si es posible. Leemos el código—y la historia del proyecto.
- Identificar lo que funciona. Incluso si algo debe cambiar, ayuda saber qué es sólido o sigue siendo relevante.
- Tomar decisiones balanceadas. Evaluamos técnica y estratégicamente qué rehacer, qué mejorar y qué ya entrega valor.
Evaluamos con plena conciencia de lo que implica construir, mantener y evolucionar software.
Ejecutivo de ventas con amplia experiencia en soluciones SaaS empresariales B2B y un historial de crecimiento de ingresos en América Latina y EE.UU. Ha liderado equipos comerciales de alto rendimiento tanto en entornos corporativos como startups, incluyendo roles en Mastercard y AeroMexico. Especialista en planificación estratégica, gestión global de cuentas y ejecución de estrategias go-to-market. Éxito demostrado escalando ingresos recurrentes y obteniendo rondas de inversión clave en sectores tecnológicos de alto ritmo.
