Insights

¿Cómo construir software de calidad?

Photo of the author: Camilo Nova

Camilo Nova

  •  

6 min read.

El mal software es algo que le pasa a las buenas personas

El mal software es una de las pocas cosas en el mundo que no se resuelven con dinero. Grandes empresas cuentan con plataformas digitales que en muchos casos son inferiores a las que son construidas por un grupo de estudiantes. Compañías de taxi alrededor del mundo que cuentan con aplicaciones terribles, a pesar que compiten con Uber, Lyft y otras. 

Grandes proyectos corporativos de IT con presupuestos enormes, construidos a lo largo de varios años, no logran ser los proyectos digitales exitosos que todos esperan. Cualquiera que sea la razón para terminar con mal software no parece que sea por falta de recursos económicos.

Sorprendentemente, la causa principal del mal software no guarda mucha relación con decisiones a nivel de ingeniería. Más bien tiene que ver con la manera cómo los proyectos son administrados. Los peores proyectos siguen las mismas características:

El cliente del proyecto arranca por querer construir una solución especifica que tiene en mente y nunca identifica explícitamente el problema que quiere resolver. Luego junta una larga lista de requerimientos de un gran grupo de personas para posteriormente entregarla al equipo de trabajo, quienes comienzan a desarrollarla. Una vez todos los puntos de la lista han sido realizados, el proyecto se lanza a producción y se declara como finalizado.

La causa principal del mal software no guarda mucha relación con decisiones a nivel de ingeniería. Más bien tiene que ver con la manera cómo los proyectos son administrados.

A pesar de que el software cumple con el listado de especificaciones, surgen bastantes problemas cuando se pone en manos de los usuarios reales. Es lento, difícil de usar, y lleno de errores que hacen un verdadero dolor utilizar el software y desafortunadamente en este punto no hay más presupuesto para realizar cambios o mejoras que puedan corregir estos problemas.

El lenguaje de programación, la arquitectura de software, y el diseño de interfaces son procesos que siempre van a cambiar de proyecto a proyecto. Din embargo hay características particulares de los proyectos de software que causan que fallen mientras que permiten a los equipos más pequeños moverse mejor y más rápido.

  • Reutilizar buen software es fácil; es lo que permite construir buenas cosas rápidamente.
  • El software no está limitado a la cantidad de recursos que pones en su desarrollo, sino de que tan complejo se vuelve a lo largo del tiempo.
  • El valor principal del software no es el código que se produce, sino el conocimiento acumulado del equipo que lo realiza.

Anque entender estas características no garantiza obtener del todo los resultados, nos ilustra un panorama para entender el porqué tantos proyectos digitales siempre fracasan.

Analizar esta situación nos lleva a definir unos principios básicos para aumentar la probabilidad de éxito en los proyectos de software:

  1. Comienza tan simple como sea posible.
  2. Ejecuta, encuentra los problemas, y vuelve a comenzar.
  3. Trabaja con el mejor equipo de personas que puedas encontrar.

Seguramente existen otros factores a tener en cuenta, pero estos principios te ayudarán a construir buen software.

Reutilizar nos permite construir rápidamente

El software es muy fácil de copiar. A nivel más bajo, las líneas de código pueden ser literalmente copiadas de un lugar a otro, incluso en Internet se encuentran miles de plugins, tutoriales, y toda clase de ayudas para construir software de todo tipo. El software de la actualidad nunca se construye completamente desde cero. Hasta las aplicaciones más innovadoras se han construido sobre plataformas existentes que modificadas y combinadas generan un nuevo resultado.

El más grande conjunto de software reutilizable esta disponible en la comunidad de software libre. El software de código abierto se encuentra disponible abiertamente al público para que lo vea y lo utilice. 

Muchas de las contribuciones al software de código abierto son realizadas por empresas de tecnología en el mundo. Si hoy en día quieres utilizar una base de datos tan escalable como la de Facebook, solamente tendrías que descargar el código de Cassandra, del cual ellos liberaron su código al público en el 2008. Si quieres probar la última herramienta para machine learning, solo hay que descargar TensorFlow que fue publicado en 2015. 

Utilizar software de código abierto no solo hace mas rápido el desarrollo, sino que te da acceso a tecnología mucho mas sofisticada que lo que pudieras desarrollar por tu cuenta. Para los proyectos de código abierto más populares incluso hay mayor seguridad puesto que muchos desarrolladores en el mundo trabajan en mejorarlo. Esta es la razón principal por la cual la tecnología ha tenido un desarrollo tan rápido, incluso los nuevos ingenieros comienzan a construir sobre lo que los demás ya han desarrollado.

Con la aparición de los servicios cloud esto se ha llevado a un mayor nivel, ofreciendo plataformas propietarias muy avanzadas por solo un pequeño pago mensual. ¿Necesitas un sitio web pequeño? Solamente con unos clics en una herramienta como WIX o Squarespace lo puedes lograr. ¿Necesitas una base de datos? Puedes obtener una fácilmente en Amazon Web Services o Microsoft Azure. Los servicios cloud han permitido a los desarrolladores la especialización. 

El proveedor de servicio garantiza su puesta en marcha, mantenimientos y mejoras, que al final llevan a tener un servicio de alta disponibilidad, muy sofisticado, por un pequeño costo distribuido en millones de clientes. Esto permite que los clientes puedan ahorrar dinero solamente pagando por el software que realmente les agrega valor.

No es posible realizar avances tecnológicos si todo el tiempo se destina a volver a construir herramientas ya existentes. La ingeniería de software es sobre construir procesos automatizados, y las primeras cosas que se automatizan provienen de las herramientas ya existentes. El punto es entender cuándo es mejor utilizar un producto que ya existe y cuándo utilizar uno a la medida de los requerimientos únicos del negocio.

El software está limitado a la complejidad

La utilidad de una plataforma de software esta generalmente limitada por su complejidad y no por la cantidad de recursos invertidos en ella. Las plataformas de IT comúnmente están llenas de funcionalidades y sin embargo son odiadas por sus usuarios por lo complicadas que se vuelven. En contraste, las aplicaciones mas valoradas por los usuarios son aquellas que se reconocen por su sencillez y facilidad. 

Aprender a utilizar software es difícil. Después de cierto punto, nuevas características hacen las cosas peor para los usuarios por razón de la complejidad acumulada de tantas opciones.

Desde una perspectiva de usabilidad, el límite no es la cantidad de funcionalidades que se pueden desarrollar, sino la cantidad que puede encajar en una interfaz intuitiva.

Incluso ignorando la usabilidad, el progreso en ingeniería comienza a ser más difícil cuando los proyectos se vuelven muy complejos. Cada nueva línea de código que se agrega a una aplicación tendrá un impacto en todas las que la preceden. Entre más grande sea la cantidad de código, más serán los errores que surgirán cuando una nueva característica es construida.

Eventualmente la cantidad de trabajo requerida para corregir errores será mayor a la cantidad de trabajo agregando nuevas funcionalidades. Esto es conocido como "deuda técnica" y es uno de los desafíos más grandes de la Ingeniería de Software. Esta es la razón por la cual grandes proyectos de software no se modifican por años y sus errores nunca son corregidos. 

Agregar más personas al proyecto solamente agrega más caos, y lleva a tener más problemas de comunicación interna a que efectivamente logre un impacto positivo.

Construir buen software requiere ciclos alternados de expandir funcionalidad y reducir complejidad.

En estos casos, la única forma de avanzar es volver a estudiar todo el proyecto y simplificar la base de código. La arquitectura de la plataforma se puede rediseñar limitando la cantidad de interacciones. Funcionalidades de poco uso para los usuarios deben ser removidas sin importar lo que se haya invertido en ellas. 

Bill Gates alguna vez dijo "Medir el progreso en la construcción de software por líneas de código es cómo medir la construcción de aviones por su peso en kilos". La mente humana solamente es capaz de manejar una cantidad finita de complejidad, entonces el desafío está en que tan eficientemente se distribuye dicha complejidad.

En resumen

Crear buen software requiere ciclos alternados de expandir funcionalidad y reducir complejidad. Tanto como las nuevas funcionalidades son desarrolladas, la complejidad se acumula en el sistema. Cuando esta complejidad es demasiado alta se debe hacer un alto y trabajar en limpiarla. Este proceso de dos etapas es necesario porque no hay una solución mágica para regular el comportamiento. 

Incluso una interfaz de usuario tan simple como la barra de búsqueda de Google contiene una masiva cantidad de complejidad que no es visible a los usuarios, y que no puede ser realizada nuevamente en poco tiempo. El reto es lograr mantener el ciclo, agregar funcionalidad y luego reducir complejidad.

Subscribe to our monthly newsletter

Learn more

Good Product Manager / Bad Product Manager

This is a classic piece written by Ben Horowitz about product management

Author Ben Horowitz Ben Horowitz

Own your tech to own your destiny