¿Por qué es tan difícil hacer software?

A menudo pensamos en el Desarrollo de Software como una búsqueda basada en la lógica y la claridad. Hay estereotipos de los desarrolladores de software como devotos seguidores de la lógica, más interesados en los dígitos binarios que en sus semejantes humanos. Desde esta perspectiva puede ser chocante descubrir que los proyectos de software tienen altos índices de fracaso y que algunos proyectos fallan por miles de millones. ¿Cómo es posible este nivel de caos en una disciplina lógica con científicos al mando? si podemos entender mejor cómo los proyectos están tan sujetos al fracaso, entonces podemos aprender a abordar los proyectos de forma más segura en el futuro. Los riesgos más peligrosos son los que no vemos venir, especialmente si nuestra forma de pensar nos ciega. Estereotipos sobre el desarrollo de software Nuestra imagen del desarrollo de software como una búsqueda lógica se ejemplifica en las reglas sintácticas precisas y estrictas de los lenguajes de programación y las aplicaciones compuestas por ellos. Esto impregna la comprensión popular, así como el pensamiento técnico. Las reglas de algunas aplicaciones pueden ser claras para el usuario de la aplicación cuando la usa – los juegos simples como los invasores del espacio típicamente no tienen una página que explique las reglas tal y como las vemos simplemente. Otras veces puede ser claro que una aplicación tiene reglas, pero lo que es puede ser oscuro, lo que resulta en el conocido fenómeno de «la computadora dice no». De cualquier manera, el rigor de las reglas tiende a sentirse y esto influye en nuestras suposiciones sobre el desarrollo de software.Famosos ejemplos de problemas informáticos son también una gran parte de nuestra imagen del software y estos tienden a estar muy estrictamente definidos. Los vendedores ambulantes de los libros de texto están sujetos a más restricciones que en la vida real (rara vez se levantan o comparten trabajo con sus colegas o se van a tomar una copa). Tendemos a asociar la ingeniería de software con ejemplos de cómo romper códigos secretos, no tanto con software que ayuda a evaluar las reclamaciones de seguros.Pero los desarrolladores de software no son todos académicos y no todos trabajan en problemas bien definidos. El desarrollo profesional de software consiste en codificar reglas para producir un sistema que cumpla una serie de objetivos de negocio. Su objetivo es producir artefactos de lógica que servirán a los propósitos en un mundo desordenado.Así que, a pesar de la imagen dominante del desarrollo de software como estrictamente lógico, el desorden del mundo tiene un papel importante en el proceso de hacer software – el software está hecho para jugar un papel en el mundo. Los proyectos pueden salir mal al hacer suposiciones incorrectas sobre el mundo o al estar confundidos sobre lo que están tratando de hacer.Aún así, esta es sólo una explicación parcial. ¿Cómo es que los proyectos de software pueden ser tan arriesgados y fallar tan a menudo? ¿Cómo hacemos para escribir software? Fotos de Desarrollo de Software Los proyectos de software pueden variar enormemente y el ciclo de vida de cómo se implementan los proyectos puede variar mucho. Es bastante difícil formar y mantener una imagen clara en la cabeza del proceso de creación de software. Varía tanto que hasta cierto punto uno simplemente tiene que aprender de la experiencia. Pero tener una idea más clara del desarrollo de software nos ayudará a apreciar mejor las fuentes de riesgo en el desarrollo de software, dado lo abstracto que es el desarrollo de software, puede ser tentador recurrir a analogías con disciplinas más concretas. Especialmente tentador puede ser una analogía con la construcción o la ingeniería física. Tan tentadora es esta analogía que históricamente ha influido mucho en la metodología de gestión de proyectos de software (especialmente en el modelo de cascada). Pero debemos ser cautelosos al respecto:

Sospecho mucho de usar metáforas de otras profesiones para razonar sobre el desarrollo de software. En particular, creo que la metáfora de la ingeniería ha hecho daño a nuestra profesión, ya que ha fomentado la idea de separar el diseño de la construcción. Martin Fowler

Como señala Fowler, es peligroso pensar que sabemos de antemano cuáles son los problemas.También es peligroso pensar que sabemos de antemano cuáles son las herramientas. Es tentador pensar que los programadores escriben código y por lo tanto las herramientas principales son los lenguajes de programación. Pero el desarrollo comercial contemporáneo depende en gran medida de las herramientas y bibliotecas existentes, que deben ser elegidas y aplicadas a la tarea en cuestión. Los programadores no sólo escriben código para resolver problemas – los programadores escriben mucho código para unir las soluciones parciales de otros. Dependiendo de la elección, puede ser difícil hacer que una herramienta funcione para un propósito en particular (que requiere mucho pensamiento y código de costura) o una rutina, o puede ser prácticamente imposible.La construcción también implica problemas de selección de herramientas. Por ejemplo, hay que elegir tipos de ladrillo o material para soportar la carga y la durabilidad. La diferencia con el software es que las herramientas mismas son conceptuales, por lo que los límites de lo que hacen son más difíciles de ver claramente, al menos sin dedicar un tiempo muy considerable. No es inusual descubrir en el futuro que una herramienta elegida no soporta

Etiquetas

Ingeniería de SoftwareGestión de ProyectosNuevas Historias TécnicasGestión de IngenieríaCodificaciónProgramaciónDesarrollo de SoftwareAgiles

Comentarios

Continúe la discusión