Los errores más habituales del desarrollo de software

El desarrollo de software es una disciplina desafiante basada en millones de parámetros, variables, bibliotecas y más, y todo debe ser exactamente correcto. Si algo está fuera de lugar, toda la pila puede caer.

Y esa es sólo la parte técnica. Programadores obstinados, partes interesadas exigentes, contadores tacaños y gerentes dispuestos a reunirse se mezclan en una capa política que hace que cualquier trabajo de desarrollo de software se realice como un milagro.

Aún así, es imposible enumerar las infinitas innovaciones que el software por sí solo ha hecho posibles. Y mucho de eso depende de los esfuerzos de los codificadores y de las personas que los gestionan. A lo largo de los años, los equipos de software han descubierto algunas reglas para realizar el trabajo. Desde metodologías elaboradas hasta disciplinas y filosofías emergentes, los libros de reglas del desarrollo de software ayudan a que todos puedan colaborar y llegar a la meta con algo que funcione.

Lamentablemente, a pesar de toda la innovación, todavía existen fallos: formas en que los desarrolladores de software y sus gerentes hacen las cosas mal. A veces las metodologías están mal aplicadas. O las buenas ideas se llevan demasiado lejos. A veces los desarrolladores simplemente olvidan, a veces a propósito, lo que se supone que deben hacer.

Estos pecados del desarrollo de software pueden descarrilar casi cualquier proyecto. Preste atención porque la única manera de garantizar que su equipo pueda crear grandes cosas es hacer una pausa y considerar el código no tan bueno que se puede crear cuando somos víctimas de estos errores y tentaciones.

 

Elegir la metodología equivocada

Todas las metodologías de desarrollo de software tienen seguidores apasionados por las reglas que definen su forma favorita de organizar un equipo. El problema suele estar en elegir el adecuado para su equipo.

Un gran error es imponer estas reglas desde arriba. Si los programadores creen firmemente en un enfoque diferente, a menudo se quejarán y se quejarán con cínico desdén si se les obliga a utilizar otro. Lamentablemente, otro error es dejar que los programadores en las trincheras elijan su favorito porque es posible que no comprendan qué es lo mejor para todo el equipo.

Elegir la metodología adecuada no solucionará todos los problemas, pero reducirá la fricción que surge al organizar el flujo de trabajo. El equipo conocerá su función y entenderá cómo codificar dentro de ella.

 

Ignorando la escalabilidad

Algunos problemas de desarrollo de software se pueden solucionar más adelante. Crear una aplicación que se amplíe eficientemente para manejar millones o miles de millones de eventos no es una de ellas. Crear un código eficaz sin cuellos de botella que sorprenda a todos cuando la aplicación finalmente se ejecute a gran escala requiere mucha previsión y liderazgo de alto nivel. No es algo que pueda solucionarse más adelante con un poco de codificación específica y cinta adhesiva virtual.

Los algoritmos y las estructuras de datos deben planificarse desde el principio. Eso significa que los arquitectos y la capa de gestión deben pensar detenidamente sobre los datos que se almacenarán y procesarán para cada usuario. Cuando aparecen un millón o mil millones de usuarios, ¿qué capa abruma la avalancha de información? ¿Cómo podemos planificar con anticipación esos momentos?

A veces, esta previsión arquitectónica significa acabar con algunas grandes ideas. A veces, la capa de gestión necesita sopesar los beneficios con los costes de ofrecer una función a escala. Algunos análisis de datos simplemente no funcionan bien a gran escala. Algunas fórmulas crecen exponencialmente con más usuarios. Los cálculos abruman el hardware y obstruyen las comunicaciones.

Los desarrolladores no siempre quieren pensar en el panorama general. Es demasiado fácil sumergirse y empezar a crear. Pero los equipos de desarrollo inteligentes y sus gerentes dedican tiempo a anticipar estos problemas porque si no lo hacen, fracasarán más adelante.

 

Caer en la última tendencia

Los desarrolladores de software pueden sentirse notoriamente atraídos por ideas nuevas y llamativas. Quizás sea un nuevo tipo de base de datos que ofrece consultas más complejas. Tal vez sea un nuevo lenguaje de programación que solucione todos los errores causados por el anterior.

A veces estas ideas tienen mérito. Sin embargo, muchas veces terminan frenando el desarrollo cuando todos intentan aprender la nueva tecnología. A veces, las nuevas ideas tienen defectos ocultos que se hacen evidentes sólo cuando todos están hundidos hasta las rodillas en el lodo, justo antes de que el proyecto deba entregarse.

La precaución suele ser la mejor regla para adoptar nuevas tecnologías. Hay una razón por la cual algunas de las empresas más grandes y antiguas continúan ejecutando software escrito en COBOL. Las tendencias van y vienen, pero la lógica de funcionamiento al ejecutar código no se desgasta.

 

Retener demasiados datos

Los programadores son ratas de manada por naturaleza. Les encanta almacenar información en caso de que sea necesaria en el futuro. Sin embargo, mantenerlo disponible porque “nunca se sabe cuándo lo necesitaremos” puede ser una receta para una fuga de seguridad o una violación de la privacidad de los usuarios.

El problema puede ser aún mayor con información personal como fechas de nacimiento u otros detalles. Algunas áreas, como los registros financieros o los registros médicos, están fuertemente reguladas, lo que facilita el incumplimiento de las reglas.

Una buena arquitectura de software implica planificar con anticipación para minimizar la cantidad de datos almacenados. Protege a todos y puede ahorrar costes de almacenamiento, e incluso acelera el sistema al reducir la cantidad de datos en movimiento.

 

Subcontratar el trabajo equivocado

El debate sobre la creación o compra de software es un debate tradicional que no tiene una conclusión definitiva. Aun así, los desarrolladores de software suelen elegir mal. Tal vez haya una solución perfectamente buena a buen precio y sean demasiado orgullosos para dejar de lado su pila personalizada con su costoso equipo interno. También ocurre lo contrario. Algunos gerentes compran la línea de productos de un proveedor externo sólo para ver cómo el proveedor aumenta los precios dramáticamente cuando se completa el bloqueo.

Desafortunadamente, decidir qué herramientas externas utilizar es un desafío constante para los equipos de desarrollo de software y sus gerentes. Contratar a la fuente externa adecuada es una genialidad, pero adoptar al proveedor equivocado es un billete a una prisión muy cara.

 

Evitar las pruebas

Los desarrolladores de software eficaces y sus gerentes saben que las pruebas son un desafío constante y una parte tan importante del trabajo como escribir código recursivo o diseñar una estructura de datos elegante. Las pruebas deben incluirse desde el principio porque las pruebas unitarias y las pruebas de integración son vitales para garantizar que el código siga siendo viable durante todo el proceso de desarrollo.

Pero las pruebas también son importantes cuando se manipulan cargas grandes. Es demasiado fácil escribir código que se ejecute sin problemas en nuestro escritorio cuando somos el único usuario. Si la aplicación va a tener cientos, miles o tal vez cientos de miles de usuarios, debe asegurarse de que el código sea eficiente y que la implementación pueda manejar una gran escala.

Muchos equipos contratan evaluadores de control de calidad que vigilan los tipos de errores que cometen los programadores. Saben cómo, por ejemplo, establecer un parámetro en cero sólo para ver si causa un error de división por cero. Saben que deben comprar 3,14159 camisetas o -4.000 calcetines sólo para ver si se rompe el código. Esta atención a las pruebas es esencial cuando los casos de uso se vuelven tan complicados que es difícil para cualquier humano pensar en todas las variaciones y escribir código limpio que las anticipe a todas.

 

Subestimar el poder de la planificación

La mayor parte del código requiere cierta dedicación a la planificación. Desgraciadamente, la mayoría de los programadores a menudo simplemente quieren saltar y comenzar a ametrallar el código.

Uno de mis amigos me dice que le tomó varios años reconocer que el mejor paso es detenerse, planificar, probar los planes y planificar un poco más. Escribir planes puede parecer tedioso, pero puede ser 10 veces más rápido probar ideas cuando se piensa de forma abstracta. Ahora es un gerente muy exitoso.

La planificación también significa incluir las aportaciones de los otros equipos y partes interesadas. Ellos serán quienes usarán el código en el futuro, por lo que dedicar tiempo a discutir el proyecto y conocer sus necesidades les ahorrará mucha frustración después. Esta es la mejor manera de evitar muchos de los pecados enumerados aquí.