La velocidad mata
- Detalles
- Publicado: Miércoles, 16 Septiembre 2009 09:02
- Escrito por Leonardo De Seta
Sos un programador. Eso signifca que tenés una presión tremenda por trabajar rápido. Hay fechas que cumplir. Hay bugs que arreglar antes de la gran demo. Hay calendarios productivos a los que llegar. Y tu trabajo depende de cuán rápido vayas y qué tan confiable seas para cumplir las planificaciones. Y esto significa que tenés que tomar atajos, compromisos, ser rápido y desprolijo.
Que estupidez.
Es dificil construir un buen espacio de trabajo para un equipo de desarrollo. Hay que balancear muchos factores: humanos, sociales, ambientales, económicos y personales. No existe una solución universal, pero si podemos compartir algunas lecciones aprendidas durante los años.
Mientras más simple, mejor. Esto es algo que a menudo olvidamos cuando desarrollamos software: nos vemos tentados por usar patrones de diseño, frameworks, tecnologías, herramientas... sin considerar otras opciones más simples aunque menos populares. Si hay dos formas de implementar algo y son funcionalmente equivalentes y no añaden ninguna repetición al sistema, hay que elegir la solución más simple.
Una y otra vez aparece el tema de la documentación, durante y después de los proyectos. ¿Qué documentación deberíamos crear? ¿Por qué necesitamos documentos de diseño? ¿Cómo podemos asegurarnos de estar construyendo el software indicado si no tenemos un Documento de Diseño Funcional? Y si el Documento de Diseño Funcional no está alineado con el software que se está construyendo, ¿cómo podemos comprobar que obtenemos lo que pagamos? Y más...
Lamentablemente, en algunas organizaciones todavía se considera al testing como la última etapa del proceso de desarrollo. Los desarrolladores entonces cruzan los dedos para programar todo lo más perfecto posible, de manera que la etapa de testing sea una formalidad donde a lo sumo se encuentren errores menores. Por suerte ya hace un tiempo que nos estamos alejando de esta utopía ridícula y vamos avanzando hacia un concepto en donde el testing es una parte integrada al proceso de desarrollo.
El diseño de interacciones es un proceso para diseño software enfocándose en los usuarios más importantes. A diferencia de las técnicas tradicionales para capturar requirimientos, el diseño de interacciones se ecentra en los objetivos de una clase particular de usuarios, representados como una persona. Estos son los objetivos que se consideran cuando se definen los escenarios que representan cómo esta persona usará el software. La combinación de objetivos y escenarios lleva a la creación de la especificación funcional del producto, fuertemente centrada en resolver la vida de un grupo particular de personas.
La industria del desarrollo de software cambia tanto y tan rápido que todos los días nos convertiremos en peores desarrolladores a menos que aprendamos y nos adaptemos de forma continua. Esta verdad tiene tres consecuencias principales. 
Mi primer libro sobre métricas, Controlling Software Projects: Management, Measurement, and Estimation (Prentice Hall/Yourdon Press, 1982) jugó un rol importante en la forma en la que muchos ingenieros de software cuantificaron el trabajo y planificaron sus proyectos. En retrospectiva, me pregunto, ¿fue un buen consejo en ese momento, todavía es un buen consejo relevante en la actualidad, y todavía creo que las métricas son algo fundamental para el éxito de un desarrollo de software? Mis respuestas son no, no y no. 
Esta vez me gustaría compartir con ustedes una visión del paradigma de los servicios, basada en un 