Llevando la programación al extremo

Mansour Raad tuvo un gran problema. Su empresa de nueva creación, DiscoverCast, estaba desarrollando un software de detección de colisiones para la industria de las aerolíneas; los errores en el código podían costar vidas. Pero el dinero se agotó después de una primera ronda de financiación, y era imposible contratar programadores adicionales para terminar una versión a prueba de errores.

Así que Raad instigó una disciplina de codificación relativamente nueva llamada programación extrema. En lugar de trabajar solos en asignaciones individuales, los programadores se emparejaron, uno escribiendo código mientras el otro observaba y criticaba, proporcionando tanto un ojo crítico como una copia de seguridad de importancia crítica. [Mi esposa] tuvo un bebé, pero el proyecto tenía que continuar, dice Raad. Como se lo estaba mostrando a las otras personas, alguien podría ponerse en mi lugar. La empresa cumplió con los plazos sin aumento de errores por la comunicación.

La mayoría de los programadores no están más satisfechos con la calidad del software que sus clientes. Ahora, un número creciente está tratando de encontrar formas de crear software sólido en un mercado que espera nuevos productos y mejoras y los quiere rápidamente. Cada vez más, las empresas de software están recurriendo a estrategias de desarrollo con nombres como desarrollo ágil y frases de programación extremas cargadas de adrenalina que se adaptan bien a la autoimagen de los programadores como héroes duros de la era de la información. En realidad, la tendencia -que tiene una larga trayectoria- señala un rechazo de la programación prima donna a favor del trabajo en equipo y la colaboración.

En la industria del software, el código con errores se ha aceptado durante mucho tiempo como un hecho de la vida, aunque agravante y costoso ( ver por qué el software es tan malo, NIÑOS Julio / agosto de 2002 ). El problema es que en el software, la gente confía demasiado en su propio ingenio, dice Michael Stiefel, consultor que capacita a los clientes en métodos de confiabilidad del software. Veía a todos estos jóvenes de veintitantos años cometiendo los mismos errores que nosotros cometimos en los setenta y ochenta, y me pregunto por qué tenemos que pasar por todo esto de nuevo.

Para reducir los errores, los reformadores están promocionando enfoques de la ingeniería de software, conocidos en la industria como desarrollo ágil, que enfatizan el trabajo en equipo, la colaboración con los usuarios finales y un enfoque flexible para el cambio. Para construir su software para evitar colisiones, la compañía de Raad utilizó un tipo de desarrollo ágil, llamado programación extrema, que enfatiza tanto las pruebas constantes como la colaboración.

Si puede aplicar [un entorno colaborativo] en toda su potencia, la calidad de los productos será mejor, dice Michele Marchesi, una destacada defensora de la programación extrema y profesora de ingeniería eléctrica en la Universidad de Cagliari en Italia.

Uno de los aspectos más poderosos de la programación ágil es la llamada programación entre pares, en la que los desarrolladores se asocian y se turnan para escribir código y explicar su lógica al otro. Los pares son temporales, se dividen e intercambian periódicamente para fomentar aún más la interacción. Nuevos ojos examinan cada fragmento de código, creando un proceso de revisión continua.

Dos personas pueden intercambiar ideas, dice Frank Arkell, ingeniero jefe de software del contratista de defensa General Dynamics Decision Systems, que ha utilizado técnicas colaborativas durante dos décadas. Para mantener a los equipos actualizados, General Dynamics los cambia para cada proyecto.

¿Otra ventaja de la programación entre pares? Presión de grupo. Nadie quiere ser la persona que holgazanea, por lo que ambos trabajan más duro, dice Scott W. Ambler, presidente de Ronin International y autor y orador sobre desarrollo ágil.

Poner a prueba

Los enfoques colaborativos también están transformando la forma en que se prueba el software. Tradicionalmente, las pruebas han sido un proceso de dos pasos. Primero, los programadores escriben código según los requisitos. Luego, un grupo separado prueba el resultado. Pero cuando el software incluye millones de líneas de código, el proceso de dos pasos es análogo a diseñar un automóvil en papel, construirlo y luego verificar si el diseño funcionó.

Ese enfoque simplemente no funcionó para desarrolladores como Nicholas Stamos, director técnico de Phase Forward, con sede en Waltham, Massachusetts. Phase Forward desarrolla software para ejecutar ensayos clínicos farmacéuticos y sus productos deben cumplir los estrictos requisitos de la Administración de Drogas y Alimentos de EE. UU.

Stamos dice que Phase Forward cumple con esos requisitos, en parte debido a la estrecha y constante colaboración entre los programadores de la empresa y el personal de control de calidad. No se puede tirar por el espejo de popa y esperar, dice. La calidad debe incorporarse desde el primer día. Cuando los programadores completan un componente, el equipo de calidad verifica su trabajo. Luego, los equipos intercambian lugares para otra ronda de correcciones de errores. Finalmente, la aplicación integrada se prueba para encontrar problemas con la interacción entre componentes. En lugar del antiguo enfoque de dos pasos, las pruebas se convierten en un proceso interactivo y continuo.

Algunas empresas están probando un enfoque iterativo similar no solo para las pruebas, sino para diseñar el código en primer lugar. Cognizant Technology Solutions, una empresa de consultoría con sede en Teaneck, Nueva Jersey, descubrió que los métodos existentes para comenzar con especificaciones formales y luego escribir código para satisfacerlas podrían haber funcionado hace 20 o 30 años. Pero en un mundo que se ejecuta en la Web y necesita flexibilidad, lo formal puede significar rígido.

Cuando intentamos utilizar los procesos tradicionales para estos nuevos tipos de proyectos, los clientes se sintieron realmente frustrados porque los obligamos a congelar el proceso o los equipos de proyectos simplemente no siguieron el proceso, dice Kumar Mahadeva, CEO de Cognizant. En cambio, los proyectos utilizan una serie de prototipos seguidos de un ciclo de industrialización, lo que permite que la empresa maneje los cambios repentinos de los clientes de una manera que tenga menos impacto en la confiabilidad que ajustar un programa una vez completado. Los futuros usuarios brindan un flujo constante de comentarios a medida que la aplicación toma forma.

Pero los límites finales de la calidad del software pueden no estar en las habilidades de los programadores o en la fuerza del proceso de desarrollo. Este es el enigma al que nos enfrentamos hoy en día nosotros y muchos fabricantes: ¿cuál es un nivel aceptable de calidad? dice James Hymel, director de ingeniería de software de Motorola. Si tiene competidores que resultan en [productos] bonitos, baratos, pero con errores y los clientes dicen que eso es aceptable, es decir, que gastan su dinero en ellos, tendrá un desafío.

Con métodos como el desarrollo ágil, la asociación de desarrollo y pruebas, y la participación de los usuarios finales, los desarrolladores de software están tomando medidas para mejorar su producto. Pero al final del día, la mayor limitación para la calidad pueden ser las mismas personas que la exigen más fuerte: los consumidores.

esconder