¿Cómo decidimos lo que va en Xojo?

A continuación encontrarás, traducido al castellano, el artículo publicado originalmente por Geoff Perlman (CEO y propietario de Xojo) en el blog oficial de Xojo.

Probablemente te hayas preguntado cómo decidimos las características y correcciones de bugs que se incluirán en una release concreta de Xojo. Lo que más nos importa es aquello que tendrá un mayor beneficio para los usuarios y el coste que tendrá proporcionar dicho beneficio.

Utilizando términos de negocio, es lo que se denomina un análisis de coste-beneficios. Algo que tiene un coste pequeño y proporciona un gran beneficio es mucho mejor que algo que cuesta mucho pero proporciona poco beneficio. Esto es bastante evidente. Por supuesto, la mayoría de los casos se producen en el medio en vez de en los extremos.

La superficie de impacto es el beneficio en nuestro análisis de coste-beneficio. Cuanto mayor sea la cantidad de usuarios afectados por un bug o característica, mayor será la superficie de impacto. Cuanto mayor sea la superficie de impacto, también será más probable que nos pongamos a ello antes. Incluso en el caso donde la superficie de impacto es grande, algunos problemas pueden solucionarse rápidamente mientras que otros requieren de más tiempo. Un error tipográfico en un cuadro de diálogo puede resolverse en segundos. Añadir soporte para una plataforma completamente nueva, lleva más tiempo.

Peticiones de los Usuarios

Feedback es la app que proporcionamos a los usuarios de modo que puedan solicitar nuevas características y también para informar de fallos. En Feedback, los usuarios pueden indicar qué 5 casos son los más importantes para ellos, ya se trate de bugs o bien solicitud de nuevas características. Al hacerlo se asignan puntos al caso; siendo el #1 el que recibe más puntos y el #5 el que menos. El listado de Favoritos en Feedback muestra los 100 casos principales que han recibido la mayor cantidad de puntos. Si bien este es sólo un criterio, es uno realmente importante dado que nos ayuda a determinar la superficie de impacto sobre cada problema.

En ocasiones los usuarios se ponen en contacto con nosotros para preguntar por qué aun no se ha solucionado o implementado un caso que ha sido reportado y verificado por nuestro equipo hace tiempo (o revisado, en el caso de una solicitud de nueva característica).

Esto nos lleva nuevamente a la superficie de impacto. Los casos con una mayor superficie de impacto serán gestionado, normalmente, antes que aquellos con una superficie de impacto menor. Muchos (pero no todos) de los informes de bugs abiertos en Feedback sólo impactan a una pequeña cantidad de usuarios (y muchos de ellos sólo a un usuario), de modo que centramos nuestra atención primero en aquellos que tienen un impacto sobre la mayoría.

La antigüedad de un caso no es un criterio para solucionar un problema. La superficie de impacto es lo que importa (con las excepciones indicadas a continuación).

Es importante darse cuenta de que las herramientas de desarrollo siempre tendrán más informes abiertos sobre fallos en comparación con cualquier otro software. ¿Por qué es así? Porque las herramientas de desarrollo tienen, por lo general, tal cantidad de APIs que no es posible calcular todas las posible interacciones.

En una app pequeña y muy enfocada, la cantidad total de interacciones son muy pocas en comparación, por lo que resulta más sencillo testearla. Cada gran herramienta de desarrollo, incluyendo aquellas cuyos equipos están compuestos por muchos más miembros que el equipo de Xojo, tienen miles y miles de informes de bugs abiertos.

Revisar la base de bugs para Microsoft Visual Studio es una buena comparación. En términos de ratios (casos abiertos vs cerrados), somos parecidos pero con un equipo y presupuesto varias órdenes de magnitud más pequeñas. El que haya miles de casos abiertos no significa que Visual Studio y Xojo no sean potentes y útiles. La mayoría de estos casos se encuentran ciertamente en los márgenes y no afectan a muchas personas.

Nuestras Ideas

Como puedes imaginar, pensamos en Xojo todo el tiempo y también lo usamos todo el tiempo. Gran parte del código que escribimos está en Xojo. Mientras que el IDE está escrito en Xojo, muchos de nuestros sistemas internos también están escritos en Xojo. Algunas veces tenemos ideas sobre capacidades que ningún usuario ha solicitado. Por ejemplo, cuando añadimos la capacidad de crear aplicaciones Web, ningún usuario había preguntado antes por dicha capacidad; e incluso hoy una gran porción de usuarios Xojo crean aplicaciones Web.

Bugs que no se pueden circunvalar

En ocasiones un usuario nos contacta sobre un bug que le impide desplegar su app a sus usuarios. Puede que no impacte a muchos otros usuarios, pero tiene un gran impacto sobre ellos. Lo primero que vemos es si existe algún modo inmediato para circunvalar el problema y, luego, determinar si tiene sentido aplicar una corrección al problema. Menciono esto porque en ocasiones la forma de evitar el bug es muy fácil y la solución del bug increíblemente difícil. Todos estos factores han de ser considerados.

Algunas veces el bug es reportado por sólo un usuario y aun así podemos ver que dicho fallo tendrá un impacto sobre una gran cantidad de usuarios, por lo que no esperamos para corregirlo.

Bugs que nos molestan

Dado que desarrollamos gran parte de Xojo en Xojo, también nosotros nos vemos afectados por bugs y, afortunadamente, estamos en la posición única de corregirlos en ese mismo punto. Esta es una de las ventajas de escribir gran parte de Xojo en Xojo.

Problemas de los Usuarios Xojo Pro Plus

Los usuarios Pro Plus pagan más para que sus problemas se solucionen antes. Este es un nivel extra de soporte. Por ejemplo, quizá sea un bug al que normalmente no daríamos prioridad porque no impacta a una gran cantidad de usuarios o requiere de ayuda para encontrar el problema en tu código. Los usuarios Xojo Pro Plus reciben prioridad.

Desarrollo Patrocinado

En ocasiones recibimos peticiones para características que, si bien suponen un añadido valioso en Xojo, no tienen el suficiente impacto como para que las prioricemos en ese momento. El usuario que solicita dicha característica puede patrocinar el desarrollo de dicha característica, lo cual paga por el coste de oportunidad para nosotros de hacerlo ahora en vez de estar trabajando en algo solicitado por una mayor cantidad de usuarios. Dos ejemplos que me vienen a la cabeza son el soporte de Linux con Seguridad Mejorada y, más recientemente, la capacidad para guardar y cargar XojoScript compilado.

¿No debería estar Xojo libre de bugs? En el mundo ideal, sí. En la realidad, el coste de intentar llevar el contador de bugs (o incluso aproximarse) a cero aumenta exponencialmente con el tamaño del proyecto. Por ejemplo, el software que ejecutó el transbordador espacial tenía 420.000 líneas de código y supuestamente sólo tenía un bug en una versión concreta.

Como dijo uno de los programadores, “Si el software no es perfecto, algunas de las personas que vemos en las reuniones pueden morir.” Este nivel de fiabilidad no es barato. NASA proyectó que el software costaría 20 millones de dólares, pero terminó gastando 200 millones de dólares. Teniendo en cuenta que el código fuente de Xojo es bastante más largo que el utilizado en la lanzadera espacial, también sería mayor el coste para lograr que estuviese libre de bugs.

Revisar los 100 casos principales en Feedback también arroja luz. El 80% de estos son peticiones de características. Sólo 8 de los 50 casos principales son bugs, el primero de los cuales incluso no se encuentra en el top 10. Por tanto, invertimos una gran cantidad de tiempo en nuevas características pero esto no significa que la corrección de fallos no sea una prioridad. De hecho, solucionamos cientos de bugs cada año.

Corrección de Bugs

Solucionamos cientos de bugs cada año. Las correcciones de bugs indicadas en cada release de Xojo son bugs correspondientes a versiones previas. Por ejemplo, cuando Xojo 2020r1 indica que incorpora un total de 161 correcciones de errores, dicho número no incluye los fallos que se puedan haber introducido en 2020r1.

El Mapa de ruta

Planificamos con una antelación de 18 meses todas las nuevas grandes características que aparecerán en futuras versiones de Xojo. Describimos estas en nuestro Mapa de ruta. Es importante reconocer que nuestro equipo de ingenieros es bastante diverso y, como resultado, trabajamos generalmente en varias características diferentes al mismo tiempo, algunas de ellas se publicarán antes y otras quizá lo hagan a varios meses vista. Y, por supuesto, cada nueva versión soluciona una gran cantidad de bugs.

En conclusión

El equipo de Xojo es un grupo de personas muy dedicadas y que trabajan duro, y realmente nos preocupan los mismos problemas que también te preocupan a ti.

El principal punto de Feedback es el de guiarnos a la hora de priorizar y encontrar un equilibrio entre las necesidades y deseos de todos. A lo largo de nuestros más de 20 años, hemos probado múltiples formas de gestionar este proceso. Todo esto se reduce a que apreciamos mucho toda la ayuda de la comunidad y nuestros evaluadores que nos ayudan a hacer de Xojo el creciente éxito que es; y continuaremos utilizando Feedback y las anteriores líneas maestras a la hora de evaluar tus informes de bugs y solicitud de nuevas características.

Queremos que sepas que si has informado de un bug o necesitas un modo de evitar un problema dad, Xojo quiere ayudarte a encontrar una solución, de modo que puedes ponerte en contacto a través de Feedback, o bien enviando un email a nuestro equipo de soporte, o bien a través de los Foros.