Reflexiones de Desarrollador: De Impresoras POS a Lecciones Aprendidas en el Desarrollo de Aplicaciones Comerciales

Reflexiones de Desarrollador: De Impresoras POS a Lecciones Aprendidas en el Desarrollo de Aplicaciones Comerciales

¡Qué excelente manera de cerrar el año! Ahora, dejemos a un lado el sarcasmo. Comparto esta foto para hablarles de la primera aplicación comercial que desarrollé, involucrando el uso de impresoras de tipo POS, ESC, receipt, o como prefieran llamarlas.
 
Durante años, dediqué tiempo al mantenimiento de esta aplicación hasta que alcanzó un punto en el que cumplía todos los requisitos de los clientes y era una plataforma estable.
 
La aplicación no ha recibido actualizaciones en aproximadamente 3 o 4 años; sinceramente, no recuerdo la fecha exacta, solo sé que fue antes de mi boda, la última vez que vi ese código (que no he modificado desde entonces).
 
En aquel momento, la aplicación tenía lanzamientos por versiones, pero en un cambio de PC, perdí algunas versiones del código, lo que causó problemas con los distribuidores. Sin embargo, logré recuperar los lanzamientos y resolver la situación.
 
Hace dos o tres días, dependiendo de cuándo leas este post, un cliente me escribió diciendo que tenía problemas con la factura que estaba emitiendo la aplicación. Al revisar, descubrí que tenía razón.
 
Los precios de los productos no eran correctos, pero hay un detalle que no les mencioné: mi aplicación solo imprime los datos de las facturas de otro sistema. Si el sistema principal del punto de venta está equivocado, mi aplicación imprimirá datos incorrectos, y eso fue precisamente lo que sucedió.
 
Después de una revisión, encontré el problema, realicé la corrección, ¡y listo!
 
Si alguien ve el código de Frederick de hace 5 o 6 años, probablemente me insultaría, y yo mismo lo haría. Sin embargo, al revisar por qué está lleno de deudas técnicas e intentar refactorizar, encuentro las limitaciones que justifican esas deudas técnicas y malas prácticas.
 
A lo largo del tiempo, he mejorado enormemente como desarrollador y he aprendido que a veces debemos hacer concesiones porque la tecnología o las herramientas de terceros nos limitan.
 
Y saben qué, he mejorado muchísimo como desarrollador y también he aprendido que a veces nosotros tenemos que hacer ciertos "parches" porque la tecnología nos limita o las herramientas de terceros, como en mi caso.
 
Y a los clientes no les importa eso, siempre y cuando obtengan el resultado deseado. La aplicación se vendió desde la versión beta, un mes después de que recibí el contrato. Años después, se volvió estable y duró años sin que los clientes presentaran quejas.
 
Nunca han preguntado cómo lo hice, ni sobre la base de datos, ni el lenguaje, ni por qué hay un Windows Form ejecutándose en segundo plano. Solo quieren un resultado: imprimir facturas, y eso no les ha fallado.
 
A veces, como desarrolladores, nos enfocamos demasiado en construir un producto como si otro desarrollador lo fuera a consumir y no el cliente final.
 
Mi opinión es priorizar, obtener los mejores resultados con los recursos disponibles y luego sentarte con tu equipo para refactorizar, a menos que te encuentres en un entorno donde el cliente tenga el tiempo y el dinero para obtener el mejor resultado y la mejor calidad en el código (no calidad de la app).
 
Si lo haces como te digo, podrás ganar dinero con el producto mínimo viable, validar tu aplicación, probar con los clientes, todo mientras obtienes fondos.
 
Sin más que decir, les deseo un feliz año nuevo.
Back to blog

Leave a comment

Please note, comments need to be approved before they are published.