Llegamos a ustedes gracias a:



Columnas de opinión

Cómo reducir el problema de la productividad que está matando a la industria del software

Por: Adam Kolawa, Ph.D. en física teórica del California Institute of Technology

[05/03/2009] En octubre del 2008 escribí un artículo para CIO.com titulada, Cómo un mejor software puede salvar al mundo. En el artículo expresé mi sorpresa y frustración por los trágicamente defectuosos métodos para producir software.

Ha pasado tanto desde octubre que se siente como si hubiese pasado un siglo. Mi sorpresa y frustración por el estado del desarrollo de software ha sido reemplazado por tristeza y furia.
Entonces, ¿ahora a donde vamos? ¿En qué parte de los escombros vamos a encontrar los recursos que necesitamos para ingeniarnos una verdadera recuperación empresarial? La mayoría de las compañías ya han reducido sus inversiones en capital humano al mínimo.
Muchos de los gerentes y ejecutivos con los que he hablado en semanas recientes ahora utilizan el recorte de personal como una excusa generalizada para la inacción. Una sensación de parálisis se ha establecido. Mi mayor temor es que si esta sensación de desesperanza se convierte en el pensamiento común, seremos incapaces de generar la energía emocional necesaria para lograr una recuperación duradera.
Las TI se encuentran en una posición privilegiada para actuar contra esta amenaza. En Automated Defect Prevention (Wiley, 2007), Dorota Huizinga y yo describimos una infraestructura de desarrollo de software que automatiza las tareas repetitivas, organiza las actividades del proyecto, rastrea el estado del proyecto, y desapercibidamente recolecta datos del proyecto para facilitar la toma de decisiones. Como señalamos en nuestro libro, esta infraestructura forma una línea de producción de software. También representa un cambio de paradigma en la industria del software, y por añadidura, un cambio de paradigma en la forma en que las TI miran la productividad.
Mi nuevo libro, The Next Leap in Productivity (El Próximo Salto en la Productividad), se basa en este concepto para generar una fuerte conexión entre la productividad en las TI y la productividad de las empresas. Impulse la productividad de las TI e impulsará la productividad de las empresas.
El mejor y más lógico lugar para comenzar a hacer esto es al nivel de desarrollo de software, ya que todos los servicios proporcionados por las TI se basan en el software.
Cuando la empresa necesita cambiar rápidamente de dirección, se requiere de nuevo software que permita el cambio. Esa es la realidad fundamental de las empresas modernas. Uno no puede realmente hacer mucho de nada, hasta que el departamento de TI tenga el software adecuado para hacer que ello suceda.
Pero como todos sabemos, puede tomar una eternidad desarrollar una nueva pieza de software. Cuando la economía mundial se encontraba en auge, el lento ritmo del desarrollo del software se daba por hecho. La gente podía decir, Es lo que es, como el mal clima o visitar a un preso.
Su fatalismo quizás era comprensible. Hasta hace poco, la única forma de acelerar el ritmo del desarrollo de software eran lanzando más personas a la línea de producción. Ocasionalmente esta estrategia funcionaba, pero generalmente solo daba como resultado altos niveles de ineficiencia, más bugs y ninguna apreciable ganancias en velocidad.
Con el empeoramiento de la economía, ya no podemos darnos el lujo de tener actitudes fatalistas del pasado reciente. Hoy, 30 o 40 personas adecuadamente capacitadas y administradas pueden hacer el trabajo de 300 a 400 desarrolladores, en una parte del tiempo.
Esto no es ciencia ficción. Esto es real. Y tiene consecuencias. Déjenme darles un ejemplo. Recientemente conversé con un ejecutivo en una compañía tecnológica y discutimos sobre la actual crisis económica. El ejecutivo me dijo que la compañía había despedido a muchos de sus desarrolladores y que estaba reduciendo el tamaño de sus proyectos de software como resultado de esto.
Le dije al ejecutivo que mi firma, Parasoft, recientemente había concluido un proyecto basado en Java para crear la versión 6.0 de nuestro producto SOAtest. El proyecto requirió que escribiéramos cerca de 5.5 millones de líneas de código. Completamos el proyecto en 18 meses con solo 34 desarrolladores.
Basado en lo que sabía acerca de su enfoque de la productividad, estimé que la compañía del ejecutivo hubiese necesitado 500 desarrolladores para completar un proyecto similar en el mismo lapso.
Estuvimos en capacidad de completar este milagro siguiendo la metodología descrita en Automated Defect Prevention. No hubo una bala de plata o salsa secreta, simplemente una metodología clara que permitió una continua mejora del proceso dentro de una infraestructura automatizada.
Honestamente, no creo que se necesite ser un ingenio para apreciar cómo este tipo de productividad puede ser transformado en un gigantesco salto en la productividad de la empresa.
Por ejemplo, una empresa que obtiene un software nuevo y corriendo más rápido que el de su competidor hará llegar sus innovaciones al mercado mucho antes que sus competidores que se han apegado a las metodologías de desarrollo tradicionales.
Quizás solo le estoy gritando al viento, pero me parece que ya no tenemos otra oportunidad. Si las compañías desean seguir siendo competitivas, van a necesitar software nuevo. Pero ellas no tienen suficientes personas para desarrollar software nuevo utilizando las formas antiguas.
Las tecnologías básicas para mejorar el ritmo y la calidad del desarrollo de software, tales como la distribución del trabajo y su monitoreo, el análisis estático, testeo de unidades, revisión del código, testeo del protocolo y similares, ya existen.
En el pasado, el temor al cambio evitaba que la gerencia examinara seriamente estas tecnologías. Ahora es el momento para que nos liberemos de nuestros miedos y demos el salto a un nuevo mundo de mucha mayor productividad. La clave es que la gerencia cambie su visión del proceso de desarrollo de software y lo vea como una moderna línea de producción en la que la calidad del trabajo se valida en cada etapa y los defectos son notados durante el proceso, en lugar de hacerlo al final de él.
Adam Kolawa tiene un Ph.D. en física teórica del California Institute of Technology, y se le han otorgado 16 patentes por sus recientes invenciones. Él y Dorota Huizinga son los coautores de Automated Defect Prevention: Best Practices in Software Management (Wiley, 2007). El nuevo libro de Kolawa es, The Next Leap in Productivity: What Top Managers Really Need to Know About Information Technology (Wiley, 2009).
CIO, USA