En defensa de ¿Xamarin Forms?

Este post tiene menos de Xamarin Forms, y más de las falencias del hacer software actualmente, sin embargo siento la necesidad de hablarlo en este contexto, pues con los años me resulta cada vez más pesado acumular historias de esas que tan injustas nos parecen a los desarrolladores.

Desde el año 2004 he trabajado profesionalmente en construcción de software a nivel corporativo, desde hace 3 años decidí aventurarme por mi cuenta y me encontré con que Xamarin Forms era esa herramienta que me iba a permitir explotar todo mi esfuerzo invertido en Windows Phone y Windows aprendiendo XAML. Felicidad fue cuando Microsoft compró Xamarin, y en consecuencia el producto y su comunidad empezó a crecer y ser cada vez más una propuesta de valor, que continua creciendo y mejorando.

Ahora bien, siempre que se habla de Xamarin y de sus dos modos, Classic y Forms, se exponen a la audiencia los escenarios en los cuales se debe elegir entre uno y otro, y hoy devolviéndome entre 30 o más aplicaciones que he construido a la fecha, puedo decir sin miedo, que mientras estas hablando de esta parte, vital e importante, sencillamente no te prestan atención, y los efectos de no poner atención siempre vienen después.

Desde los clientes más sencillos como startups con poco presupuesto, hasta clientes corporativos enormes, cuando se inician proyectos para crear software, en mi caso apps móviles, algunas premisas suelen ser las mismas, veamos:

• No hay tiempo, ni dinero.
• No hay suficientes desarrolladores y no queremos complicarnos la vida con diferentes equipos de desarrollo.
• Necesitamos algo que funcione bien y salga pronto.

El escenario parece venderse solo en si mismo, un solo código, todas las plataformas, desempeño nativo, respuesta: Xamarin Forms. Claro, ¡momento! espere ¿Qué tipo de aplicación van a crear?

Xamarin Forms no es una solución mágica para todo, pero si para muchos escenarios, en especial aquellos en los que la funcionalidad y necesidades son cubiertas, y no hay dinero para invertir en desarrollos nativos, pero además, "no se necesitan funcionalidades extraordinarias gráficamente, o nativamente etc..."

Pues vale, es un excelente primer paso para empezar y claro, tiene sentido cuando además... ¡Somos ágiles! ¡Todos hacemos desarrollo LEAN! ¡Entendemos perfectamente que los proyectos son iterativos, que hay que equivocarse y aprender para poder evolucionar un producto, pero llegar rapidamente con nuestros clientes! (Espero que la nota sobre que estas expresiones son sarcasmo sea innecesaria).

En este punto es donde duele hablar de Ingeniería de Software, o bueno "lo que dejaron como vestigios algunos consultores ágiles" de la Ingeniería de Software, aunque también podríamos hablar de sentido común (el menos común de los sentidos) y llegar a la misma conclusión. Hoy en día la gente cree que el software con sentido común se hace, pero aun más, que mágicamente cumple con todos los deseos y necesidades no especificadas.

Hace unos días, recordando tantas anécdotas de estos 3 años, publicaba una reflexión en mis redes sociales:

Enviar a hacer software sin involucrar a los stakeholders finales, es como forzar un sastre a hacer un traje sin llevarle a la persona que va a usarlo, querer que el susodicho se vea perfecto y si no, culpar al sastre. Traído de los cabellos esperar clarividentes en vez de programadores.

¿A que va Xamarin Forms en todo esto? Quizá solo a que es lo que me ha tocado vivir estos tres años, pero no dudo que les pase a muchos. En mis aventuras en proyectos estos 3 años, he tenido que vivir cosas como:

• Equipos que no cuentan con que tener una app es una inversion sostenida y no única en el tiempo, y cuyos productos fallecen ante la imposibilidad de contar con presupuesto para continuar su crecimiento y evolución, que por cierto es lo más normal.
• Líderes técnicos que prefieren rehacer aplicaciones y perder el principio de oportunidad y salir al aire hasta por un año de atraso, por encapricharse con funciones estéticas menores, que nunca tuvieron el valor real para justificar un reproceso de tanta magnitud.
• Equipos de usabilidad desinteresados que generan experiencias vagas y escuetas, ante la imposibilidad de que una herramienta los deje hacer lo que se les da la gana y evitan explotar al máximo su potencial para luego culpar la herramienta.
• Stakeholders ausentes, dueños de la que parece la necesidad fundamental de las aplicaciones, y que se presentan justo cuando ya se terminó de desarrollar la aplicación, sin ánimo de adaptarse a las condiciones de un proyecto en curso o finalizado.

No se ustedes, en ninguna de estas anécdotas veo yo nada técnico, o de Xamarin Forms y son solo algunas pocas historias. ¿Cómo puede ser que un producto, con tanto potencial, que solucionaba las necesidades enunciadas vehementemente, termine siendo el culpable de las fallas en los procesos de desarrollo y la falencia en las habilidades blandas de los participantes en un proceso de construcción? Yo no lo sé, pero eso me tiene aquí escribiendo a altas horas de la noche.

No hay más que pueda decir, lo funesto es como errores de personas y procesos, terminan por difundirse de una manera tan espantosa sobre un producto con tanto potencial.

Siempre me dolió la ingeniería de software y hoy me sigue doliendo su estado del arte, aunque hoy me duele más que antes.

De mi parte solo tengo que decir, lo que pude haber dejado en un párrafo, si los participantes de un proyecto se involucraran en las decisiones y el desarrollo de los productos, tal como el mal llamado y tan de moda agilismo propone, y si las personas de los equipos de verdad asumieran las habilidades y valores humanos como parte del proceso de desarrollo, la excusa no sería la herramienta, o el equipo que no funciona o tiene mala actitud, sería un poco más mirar al interior, mirar el yo, y como yo deje que pasara y que mi equipo no se diera cuenta que cometíamos un error del que solo yo era consciente o como yo, no hice lo mejor que podía hacer para sacar el proyecto adelante.

Para quienes no lo sepan, en la maravilla esa que llaman agilismo, los errores propios y ajenos son válidos, nos hacen seres humanos, pero hay que corregirlos sin culpar a lo que no tiene culpas, y siendo parte, en vez de haciéndose a parte.

@soreygarcia