Del ticket al código: el error de programar antes de entender
El ticket parecía sencillo: agregar un botón para reabrir una evaluación finalizada. El diseño ya tenía botones parecidos, el estado existía y el endpoint que guardaba los cambios estaba funcionando. En una primera lectura, parecía una tarea de unas horas.
Pero “reabrir” no es una acción de interfaz. Es una decisión sobre el comportamiento del sistema. ¿Quién puede hacerlo? ¿La evaluación vuelve al estado anterior o entra en uno nuevo? ¿Qué ocurre con el resultado que ya fue comunicado? ¿Los reportes deben mostrar la versión original, la nueva o ambas? ¿Cómo queda registrado el motivo y quién autorizó la excepción?
Cada respuesta cambia la solución. Puede cambiar los permisos, la transición de estados, los datos que se conservan, las notificaciones y la forma en que otros procesos interpretan ese registro. El botón solo es la parte visible de una regla que atraviesa todo el producto.
Ahí aparece uno de los errores más costosos del desarrollo: confundir una descripción breve con un problema entendido. Un ticket puede decir “agregar un botón”, “crear un endpoint” o “cambiar un estado” y seguir sin explicar qué decisión necesita tomar el sistema. Cuando esa decisión queda implícita, el código termina eligiendo por el equipo.
El caso feliz suele ocultar el riesgo. Un usuario autorizado pulsa el botón, modifica el dato y guarda. Todo parece funcionar hasta que aparece una evaluación antigua, un usuario sin permisos, un reporte que ya había utilizado el resultado o dos personas intentando modificar el mismo registro. Entonces el equipo no solo corrige una condición: vuelve a discutir el alcance, repite pruebas y reconstruye el contexto que faltó al principio.
Por eso, antes de preguntar dónde implementar una tarea, conviene entender qué problema la originó, qué debe permanecer cierto después del cambio y qué otros comportamientos dependen de esa decisión. Leer el código existente, revisar datos reales y formular una pregunta concreta no es retrasar el desarrollo. Es evitar que una suposición se convierta en una regla difícil de deshacer.
Programar no empieza cuando se abre el editor. Empieza cuando el equipo deja de repetir la solución escrita en el ticket y comprende el comportamiento que necesita construir. El ticket puede señalar dónde mirar; la calidad de la solución depende de todo lo que se descubre antes de convertirlo en código.
El ticket ayuda a ordenar el trabajo, pero no reemplaza el criterio técnico. La diferencia entre una implementación rápida y una buena solución suele estar en las preguntas que se hacen antes de escribir código.
Fuentes consultadas
Resumen Ejecutivo
El artículo plantea que muchos problemas de software aparecen antes de escribir código: cuando un ticket se interpreta como una orden literal y no como una pista incompleta. Desarrolla cómo entender usuario, restricciones, estados, permisos, impacto técnico y contexto del sistema puede evitar retrabajo y soluciones que funcionan solo en el caso feliz.
Puntos Clave
- El ticket es una pista, no una verdad absoluta.
- El caso feliz suele ocultar estados, permisos y datos reales que rompen la solución.
- Empezar rápidamente puede crear retrabajo cuando las decisiones se toman demasiado pronto.
- La pregunta clave no es qué pide el ticket, sino qué problema intenta resolver.
- Las restricciones forman parte del requisito, no son detalles para después.
- El código existente ayuda a entender la historia y las decisiones previas del sistema.
- Preguntar bien es una forma de análisis técnico.
- Un spike acotado puede convertir incertidumbre en una decisión antes de convertirla en código.
- La calidad también depende de que el equipo permita hacer visibles las dudas importantes.
Enfoque recomendado
"Usar este artículo para abrir una etapa más centrada en oficio de desarrollo. El enfoque debe ser narrativo y práctico: mostrar que programar no empieza en el editor, sino en la comprensión del problema, las restricciones y el impacto."