Brooks niega la posibilidad de Silver Bullets en un futuro

Jorge Amione A01193321

Alejandro Soriano A01232051

Abstract

El artículo de Brooks trata de muchos conceptos acerca del desarrollo de software, con el fin de enseñar a gente que el desarrollo del mismo es algo muy complejo y difícil, eliminando así el pensamiento de que algún día habrá un “Silver Bullet” (una herramienta) que algún día haga sencillo el desarrollo para cualquier persona.

Brooks comenta que hay dos clases de cualidades (dificultades) en cada software:

• Cualidades esenciales: Éstas son las difíciles de tratar, debido a que son las que tienen que ver con el diseño del software. En ellas incluye:

• Complejidad
• El software siendo invisible (haciendo el diseño más difícil de desarrollar)
• Cambiable
• Conformidad

• Cualidades accidentales: Éste tipo de cualidades pueden ser tratadas más fácil que las esenciales, debido que tienen que ver con el código y con las herramientas. En ellas incluye:

• Los lenguajes de alto nivel
• Tiempo compartido (en proyectos)
• Ambientes de programación unidos

Brooks niega la posibilidad de Silver Bullets en un futuro. Ejemplifica la programación orientada a objetos, lenguajes de mucho más alto nivel (como Ada), la prueba de verificación basado en el diseño, herramientas mejoradas, estaciones de trabajo y la AI (inteligencia artificial). A partir de la inteligencia artificial nombra sistemas expertos, programación artificial y programación gráfica. A las herramientas las nombra como útiles, pero que en ningún futuro harán el desarrollo de software una tarea sencilla.

En fin, Brooks señala tres áreas prometedores en contra de las dificultades esenciales como las siguientes: la compra de software, la refinación de requisitos (debido a que el usuario nunca sabe exactamente lo que quiere), y apoyar el crecimiento, no la construcción, de software por medio de la preservación de buenos diseñadores.

Si uno es capaz de comprar el software existente en lugar de desarrollar desde cero, los costos de diseño, investigación, desarrollo, pruebas, documentación y soporte se evitan por un costo mejor y fijo. La replicación del software es barato, y la compra en lugar de construir por lo regular está más barato y más predecible. Por la refinación de requisitos dice que tratar de tener un software que trabaja tan temprano, frecuente y con certeza como sea ayuda a los clientes a que verifiquen que el producto cumpla con sus necesidades (porque ellos nunca saben qué es lo que necesitan en un inicio). Por último, Brooks señala que hay elementos que no se pueden enseñar a los diseñadores casuales, por lo que hay que preservar a los grandes. Por grandes, Brooks no se refiere a los veteranos, sino que también se debe identificar a los que presentan un potencial grande de diseñador, ya que no siempre son los que tienen más experiencia.

Con qué estamos de acuerdo

        Nosotros también asumimos que uno de los principales problemas al momento de desarrollar software es la mala comunicación entre miembros de un equipo, como lo dice Brooks al describir la cualidad esencial de la complejidad, porque en el momento en que no hay comunicación, dicho recurso tan importante puede causar muchas repercusiones como el mal-entendimiento del programa, lo que conlleva a las fallas del mismo y así se va como un camino de dominós pegados uno al otro.

Por otro lado, estamos bastante de acuerdo que el software debe ser cambiable y conforme. El cambio de alguna pieza durante el desarrollo del software es esencial cuando éste no está marchando bien o cuando el usuario requiere más conformidad, y por ende se debe poder optar por hacer cambios sin repercusiones negativas en él.

Con qué no estamos de acuerdo

        En nuestra opinión, el software siendo invisible como un reto más para los diseñadores no es una cualidad a la que se le debe dar mucha importancia. Al comparar el diseño del software con aquél de un arquitecto o con alguno otro que sea físico, sí, es más retador por no ser físico, pero esto no significa que traerá muchos problemas a un equipo de trabajo. “This lack not only impedes the process of design within one mind, it severely hinders communication among minds” (Brooks, p.5, 1987). Para nosotros, el hecho de que el software sea invisible atrae más comunicación entre las mentes que lo desarrollan para que puedan desarrollar la estructura del software en diagramas.

...