Hoy día el software es mucho más complejo que hace años, nadie lo niega. Un sistema operativo como cualquiera de los que manejamos, ya sea macOS, iOS, Android, Windows, distribuciones varias de Linux o cualquier otro sistema o software tiene una complejidad infinitamente superior a la que el software tenía hace años. Eso obviamente, hace más complejo mantener la calidad del mismo y requiere procesos y tiempos mayores para garantizar que no habrá ningún problema o minimizar, al menos, su impacto.
Pero la realidad que se nos presenta hoy, es que vivimos en un estado permanente de beta en todo el software que usamos, porque se da por hecho que si algo está mal podremos parchearlo con una simple actualización. Así que llegamos al paradigma de "tú saca, que si hay errores, ya iremos corrigiendo sobre la marcha". Eso no pasaba hace muchos años (o pasaba mucho menos) donde había un factor clave que se mimaba hasta el máximo: el QA, quality assurance o calidad del software.
Según un último artículo de Mark Gurman para Bloomberg, Apple habría tomado una importante decisión para solventar este problema en la calidad del software que claramente les ha afectado con el lanzamiento de la última versión de iOS y iPadOS 13, Catalina, watchOS y tvOS y que ya les volvió a pasar con iOS 11 donde tomaron medidas, pero claramente no las suficientes.
Mucho trabajo que hacer para tan poco tiempo
Cuando Apple hacía software solo para un sistema (como macOS) y las novedades en ellos eran pocas versión a versión, los lanzamientos estaban más controlados. Pero en los últimos 10 años todo se ha descontrolado en cuanto a cantidad de sistemas y librerías que mantener. Los problemas de ingeniería del software se han agravado, no solo en funciones para usuarios, también en herramientas para desarrolladores. Si analizamos lo que ha sucedido este año con iOS 13 o lo que pasó hace dos años con la versión 11, es obvio que se hubieran necesitado más meses de trabajo y un proceso de QA (control de calidad) más eficiente para evitar los problemas que todos conocemos.
En esta línea, los desarrolladores nos hemos visto afectados igualmente. Apple ha lanzado multitud de nuevas herramientas que, a pesar de lo increíbles y prácticas que son, es fácil encontrar en ellas pequeñas cosas donde se nota claramente que no se han implementado correctamente o probado de la forma necesaria, por falta de tiempo o un deficiente proceso de control de la calidad. Y también porque Apple (o cualquier otra compañía) ha de cumplir religiosamente determinadas fechas de lanzamiento (como la de su flamante nuevo iPhone anual) donde claramente al software no le da tiempo a estar preparado al 100%.
Según nos cuenta Mark Gurman en Bloomberg, Apple habría tenido una serie de reuniones internas con Craig Federighi, SVP de Ingeniería del Software en Apple, y una de sus personas de más confianza Stacey Lysik, Directora Senior, para buscar soluciones a esto. No solo para que la próxima versión iOS 14 venga mucho más limpia y carente de errores, principalmente para mejorar los procesos unidos a la ingeniería del software y la calidad del mismo.
En el pasado Apple ya tomó la decisión de poder parar lanzamientos cuando el software no estaba lo suficientemente preparado y ahora van un paso más allá: las versiones de prueba que se generan de forma continua (conocidas como builds diarias) que cubren futuras actualizaciones de los sistemas, desactivarán por defecto la inclusión de funciones que no estén terminadas o que tengan fallos conocidos. Estas seguirán estando dentro del sistema, pero se creerá una forma de clasificación mediante un menú de opciones en las versiones de prueba internas o peticiones a través de un nuevo canal de comunicación. Este proceso o menú (según función) permitirá activar o no cualquiera de ellas y con esto, aislar el impacto de cada una de las nuevas funciones no terminadas en el conjunto general del sistema.
Este nuevo proceso permitiría que las versiones internas de pruebas de los sistemas sean más usables y más vivas. Antes de este cambio que Apple anuncia, los equipos de desarrollo podían añadir funciones cada día que no estuvieran totalmente probadas, mientras otros equipos podían contribuir con cambios en tiempos más prolongados y más estables. Algo así como una receta donde un montón de cocineros meten nuevos ingredientes sin ningún tipo de control en diferentes estados de cocción o fritura.
¿Y qué provoca esto? Que los dispositivos de prueba se vuelvan excesivamente inestables con tantos cambios y funciones en diferentes estados de desarrollo. Según un desarrollador con el que Bloomberg ha hablado, esto hace inusables los dispositivos de prueba en muchas ocasiones o que se tarde días en conseguir una build estable con la que probar para una función completa. Cada una de estas pequeñas partes añadidas afecta al rendimiento general de todo el sistema y no pueden saber de una forma clara qué está funcionando o no.
Lo explico de una forma más clara: si tenemos que probar una funcionalidad concreta, pero otras que no son nuestra responsabilidad y están en estado de desarrollo muy temprano, afectan colateralmente a esta que estamos probando. Así que no podremos discernir claramente si ese error proviene de un fallo de lo que probamos o si hemos de reportarlo o no. No tendremos claro que componente está fallando realmente y lo más probable es que nuestro reporte sea incorrecto o impreciso.
El ejemplo más claro de esto fue lo que pasó en iOS 11 con los cambios en los algoritmos de Machine Learning. El cambio para usar el motor neuronal del A11 provocó que el teclado predictivo de iOS se volviera inusable cuando no disponíamos del motor neuronal de los nuevos chips (en dispositivos más antiguos), pero solo cuando estaba afectado por la bajada de velocidad de la CPU derivada de la degradación de la batería. Así que, ¿de quién es el error? ¿del teclado, del nuevo algoritmo de ML o de la función de la batería? En realidad es un conjunto de diferentes partes que afectan a un todo. Pero si pudiéramos aislar cada parte para activarla o desactivarla a voluntad, podríamos probar cada cosa por separado y obtener una mejor idea de dónde está el problema o qué conjunto de circunstancias lo provocan.
Internamente Apple tiene un sistema de clasificación y medición de la calidad de su software, en una escala de 1 a 100 conocido internamente como el test del "guante blanco". Cualquier lanzamiento que tenga más errores obtendría una puntuación por debajo de 60 mientras que los lanzamientos más estables estarían por encima de 80. Y ahora sabemos que iOS 13 obtuvo una puntuación en esta clasificación por debajo de la versión 12 que estaba mucho más pulida. Apple también marca con colores verde, amarillo y rojo las funciones para indicar su calidad durante el desarrollo. Y además para clasificar los fallos o bugs usan una escala de 0 a 5 en cada incidencia, donde 0 es un problema crítico a resolver y 5 una incidencia menor.
Número de versiones de cada versión mayor de iOS en los primeros dos meses tras su lanzamiento.
De hecho, según nos cuentan desde Bloomberg, el famoso lanzamiento de iOS 13.1 a finales de agosto vino provocado porque se dieron cuenta que no llegaban a la fecha de iOS 13 con la suficiente calidad, y decidieron dejar la versión con el nivel de calidad que tenía, y centrarse desde antes en la 13.1 con el objetivo de conseguir en esta versión el mismo nivel de puntuación que con iOS 12. Su única solución fue acabar la 13.1 lo antes posible y actualizar a todos lo antes posibles sabiendo que la 13.0 no tenía la suficiente calidad pero no les quedaba otra que lanzarla. Lanzada la 13.1, el objetivo era llegar a la 13.2 con un nivel superior a iOS 12. Pero por el camino se han dejado infinidad de pequeños bugs que han tenido que ir resolviéndose en versiones menores.
Esta medición nos da a entender claramente como aquí hay un problema serio y el equipo de software, en muchas ocasiones, se ve forzado a sacar cosas que no tienen la calidad suficiente por exigencias del marketing que aprieta porque el nuevo iPhone que sale el día X debe tener la nueva versión del software instalada. Y eso es, obviamente, un problema bastante grave. Con este nuevo sistema, Apple tendría una forma mucho más eficaz de desactivar aquello que no esté 100% probado o no haya obtenido una puntuación más alta. Así que cuando el marketing apriete una fecha, aquello que no esté acabado o suficientemente probado se desactiva y se evitan problemas. Sin duda, una buena solución.
Toda esta estrategia y cambios en los procesos de pruebas de las funciones, tiene como objetivo mejorar no solo las próximas versiones que ya hemos empezado a ver lanzadas en las últimas semanas: tienen como horizonte iOS 14, denominada internamente "Azul". Y en referencia a esa versión, ya se están planteando retrasar para 2021 funciones que estaban planificadas para esa versión, en la conocida como "Azul+1" de forma interna, que podríamos pensar que sería iOS 15. Sin dejar atrás los ambiciosos planes de ofrecer nuevas capacidades a través del software.
Esta estrategia no solo sería para iOS, afectaría a todos los sistemas de Apple. Con estos cambios en las pruebas, los ejecutivos de Apple esperan dar un salto más allá en la calidad del software.
La opinión de un desarrollador
No quiero dejar pasar la oportunidad de dar mi propia opinión como desarrollador y responsable de proyectos desde hace 20 años. ¿Qué se puede hacer ante esto? ¿Es suficiente lo que Apple plantea? En mi opinión, creo que hay ralentizar la velocidad de los lanzamientos y mejorar sus procesos de control de calidad y garantías de funcionalidad. En el caso de Apple está genial que hayan sacado tantas cosas nuevas. Pero el problema es que han abarcado mucho (como ya pasó en iOS 11) y no les ha dado tiempo a que todo esté lo suficientemente bien probado y carente de errores con los tiempos que manejan.
Lo que Apple plantea según Bloomberg es un paso muy interesante y necesario, porque da mayor enfoque a las pruebas, que sean más dirigidas y es una forma estupenda de poner orden en el caos ante decenas, cientos o miles de pequeñas, medianas o grandes funciones que se interrelacionan unas con las otras. Sin duda, este nuevo cambio nos garantizará una mejor calidad del software, estoy convencido.
Esto tendría gran utilidad para uno de los problemas más claros de Apple: si los nuevos iPhone deben estar en septiembre, está claro que no hay otra que cumplir esa fecha. ¿Qué hacemos entonces? No pretender sacar 40 cosas. Saquemos 10, bien probadas y depuradas. Y el resto las iremos sacando poco a poco. No hay prisa. Como Deep Fusion que ha llegado dos meses después.
La nueva capacidad de apagar y encender funciones, permitiría activar solo aquellas que tengan más garantías de forma selectiva. No todo son funciones específicas y grandes como Deep Fusion. En desarrollo se lleva muchos años trabajando con el concepto de "desarrollo continuado" donde cada pequeña aportación de un equipo al código general del proyecto debe ser aprobada de forma individual. Si ahora se puede probar también de forma aislada, una parte que en el proyecto del lenguaje Swift está muy bien resuelta, podremos tener más control aún.
Otra cosa que creo debería cambiar porque no está sirviendo como se espera son las betas de Apple. La gente se baja las betas por el ansia de querer probar antes que nadie las nuevas funciones, pero luego no reportan errores. Y si lo hacen, son tantos casos y requieren de tanta investigación para ser entendidos, replicados, localizados, gestionados o arreglados, que es una gran pérdida de tiempo.
Creo, en mi opinión, que Apple no debería delegar esa parte de QA a los usuarios o desarrolladores. Las betas tienen otro propósito: que los desarrolladores puedan probar que sus apps funcionen en las nuevas versiones antes de su lanzamiento y les de tiempo a adaptarlas. Más allá, debería ser Apple quien se encargara de darnos las versiones lo suficientemente pulidas, cosa que este año no ha hecho. Y personalmente, quitaría las versiones beta públicas porque en mi experiencia, dan más trabajo que soluciones prácticas y dejaría solo las betas para desarrolladores.
Para que se hagan una idea, un fallo que cuelga una app es el mejor para un desarrollador, porque el informe que se genera te dice exactamente qué ha fallado. Pero un error de una app que hace algo que no debe como que AirDrop localice o no nuestro ordenador de forma intermitente o que un contacto determinado nunca se sincronice en iCloud de forma correcta, son fallos muy difíciles de localizar y de buscar por qué sucede. De replicar.
Otra cosa que debería mejorar Apple y que no se menciona en el artículo de Bloomberg, es hacer un mayor uso de los test unitarios. Un test unitario es aquel que nos permite "atar" algo que funcione, para que si un cambio posterior lo estropea de forma colateral, se detecte y bloquee la creación de nuevas versiones hasta que se corrija. Cuando trabajamos con herramientas de Apple, y esto es algo en lo que coincidimos muchos desarrolladores a nivel mundial, está claro que Apple no está aplicando todo lo que debería lo que se conoce como TDD (Test-Drive Development o desarrollo conducido por pruebas).
Ciclo de desarrollo TDD (Desarrollo conducido por pruebas)
TDD es una forma de desarrollar que provoca que el mismo desarrollo sea más lento y más metódico, porque básicamente obliga no solo a crear el algoritmo que de función a lo que queremos hacer: también a crear otro algoritmo que pruebe este. Y eso se aplica a cada pequeña función de nuestro programa e incluso la interfaz. Esos algoritmos de prueba de nuestros algoritmos, serán ejecutados cada vez que se quiera generar una nueva versión, independientemente a si se ha tocado o no algo que lo afecte.
De esta forma, si yo tengo una función que al tocar un botón es llamada para poner una nueva tarea con la información que se le proporcione, hago una función de test que verifique que cuando llamo a esa función que crea la tarea, realmente la crea y la pone donde debe. Si alguien en algún momento cambia el sitio donde debería guardarse, el test dará error e impedirá que la versión pueda generarse. También puedo probar que el botón llame donde debe, y si llama a otro sitio porque alguien lo ha cambiado sin yo saberlo, dará un error.
Si Apple hace una implementación mucho más enfocada de esta técnica, conseguirá con ello solventar otros problemas a otros niveles, como que algo se estropee cuando ya está arreglado y nadie se de cuenta.
Otro paso que considero esencial es que haya equipos de desarrollo cuya labor sea usar y programar apps con las librerías que hace Apple, antes que se lancen. La única forma de comprobar si sé conducir es conduciendo. Tener equipos que hagan apps (aunque luego no lleguen a nada) reales con las herramientas de Apple permitirían aflorar fallos, problemas o incluso debilidades funcionales de cualquier herramienta y podrían mejorarse mucho antes de ser lanzadas. Esto mejoraría exponencialmente que los desarrolladores que hacemos los desarrollos no tengamos errores que nosotros no hemos creado o que nos dificulten excesivamente el trabajo porque hay que crear formas de sortear los fallos que a Apple se les escapan en sus librerías y que ellos mismos habrían detectado si tuvieran a alguien trabajando con esa herramienta de forma real.
Conclusiones
Esta claro que Apple obviamente sabe que tiene un problema importante encima de la mesa y que mantener el software es cada vez más complejo. Ir mejorando los procesos poco a poco es la mejor garantía y agradecemos mucho que esta información llegue hasta nosotros por medios como Bloomberg.
Sin duda, el trabajo es cada día más complejo, más difícil y afecta a muchos. No solo al usuario final, también a los desarrolladores. Y si Apple muestra que reacciona a tiempo y va mejorando, toda mejora será bienvenida. Dicen que el primer paso para arreglar algo es ser capaz de darse cuenta del problema.
Ser conscientes qué hemos de mejorar y mejorar cada día. Y nunca nos conformemos con que ya es suficiente y no hay que hacer nada más por seguir mejorando. Ni grandes compañías ni cada uno de nosotros.
Imagen de portada de Kārlis Dambrāns Enlace en Flickr
Ver 22 comentarios