¿La reutilización del software impide la repetibilidad del proceso?

Reutilización de código como problema

Estaba pensando en esta pregunta sobre la entrega de software, y seguí volviendo al tema de la repetibilidad y / o reproducibilidad . Importan, porque si no repites un proyecto, entonces se vuelve más difícil mejorar el proceso que usaste para construir el proyecto. La ingeniería implica mejorar constantemente los procesos relacionados con el diseño y la construcción para producir proyectos de mayor calidad.

El software puede depender en gran medida de la reutilización debido a su forma digital. En lugar de reescribir un módulo, simplemente lo llamamos nuevamente o lo copiamos al otro sistema. Algunos ejemplos son autenticación / inicio de sesión o quizás una función de registro. Hay muchos ejemplos bien conocidos para esas categorías, y la sabiduría convencional es reutilizar lo que existe en lugar de crear uno propio.

Algunas comparaciones con otras disciplinas

Construcción

En contraste, la construcción de sistemas físicos (edificios, puentes) no es tan reutilizable. Es cierto que el plano de una casa se puede reutilizar muchas veces para construir la misma copia de la casa, pero la construcción debe realizarse cada vez. Cortar y pegar no funciona así en el mundo analógico. Los planos del puente son menos reutilizables que las casas porque las condiciones del sitio variarán.

Los maestros constructores son expertos reconocidos por haber diseñado y / o construido decenas, cientos o miles de cosas en su área. Por ejemplo, Frank Lloyd Wright , un arquitecto y diseñador de renombre mundial designed more than 1,000 structures and completed 532 works. Compare eso con Anders Hejlsberg, quien ha diseñado "solo" cinco idiomas (Turbo Pascal; Delphi; J ++; C #; Typecript). En muchos sentidos, es una comparación injusta porque los dominios son diferentes. Pero en un nivel amplio, la producción cuantificable de dos personas muy inteligentes es muy diferente.

Artes marciales

Los artistas marciales dirán que el dominio de un movimiento proviene solo de miles de repeticiones. Después de que una buena parte de esas repeticiones se han realizado, muchos artistas marciales se sorprenden de cómo un kata o forma compleja previamente percibida se ha vuelto simple. Los instructores de esos estudiantes también notarán cómo el movimiento se vuelve más fluido y decidido, además de tener una economía de movimiento. Del mismo modo, los artistas marciales experimentados pueden recoger katas más complejas más rápidamente que los estudiantes menos experimentados. La experiencia de la repetición les ha dado un marco o proceso que les permite aprender más rápidamente.

Carpintería

Los trabajadores de la madera experimentan una transformación similar. Los carpinteros aficionados siempre se refieren a su primer proyecto que requería muchos cajones. Si completan el proyecto, obtienen una nueva apreciación de las eficiencias que producen las líneas de ensamblaje. Hay otros beneficios, como una mejor comprensión de cómo colocar las piezas de los cajones en el material de la lámina para maximizar el uso de la madera. En comparación con los aficionados, los carpinteros profesionales pueden diseñar, comenzar y construir más rápidamente artículos que han hecho muchas veces antes. También obtienen la capacidad de ver problemas inherentes dentro del diseño de otra persona después de haber cometido ese error en su trabajo.

Entonces, ¿la reutilización del software impide que los desarrolladores de software se vuelvan más competentes?

En muchos sentidos, el diseño y la construcción del software siempre son nuevos. No repetimos trabajos pasados, porque si podemos reutilizar un módulo, biblioteca o sistema, entonces lo hacemos. Preferiblemente extenderemos un sistema existente antes de reescribir todo desde cero. Pero la repetición es lo que nos permite encontrar eficiencia en el diseño y la construcción. Cualquiera que haya practicado un deporte o actividad física le dirá que la repetición es la clave para convertirse en un buen practicante.

Mi pregunta: ¿la capacidad del software para ser reutilizado impide la mejora y eficiencia del proceso necesarias que se obtienen al repetir un proyecto?

La capacidad de reutilizar el software no impide la mejora del proceso.

Si piensa en los procesos que intervienen en la creación de software: desarrollo de requisitos, diseño del sistema, implementación del sistema, implementación del sistema, gestión de requisitos, gestión de configuraciones, verificación y validación del producto de trabajo, seguimiento de cambios y una serie de otros (consulte el Áreas de proceso de CMMI para un posible desglose de actividades clave en el desarrollo de software): se repiten en cada proyecto, independientemente de la cantidad de reutilización que tenga. Además, cada uno tiene algún tipo de medidas cuantitativas y cualitativas que se pueden utilizar para determinar qué tan bueno es ese proceso o actividad particular y, como resultado, qué tan bueno es el proceso de desarrollo en su conjunto.

En un extremo del extremo, podemos asumir una línea de productos de software robusta .. En el otro, puede asumir el desarrollo greenfield. Todavía es necesario realizar todos estos procesos, en diversos grados, aunque pueden ocurrir a diferentes velocidades o incluso en diferentes secuencias. Por ejemplo, en una gran cantidad de reutilización, se puede dedicar un mayor porcentaje del tiempo asignado a actividades de integración y verificación / validación a nivel de sistema (requisitos V&V, pruebas de integración, pruebas de sistema, pruebas de aceptación). Con nuevos esfuerzos de desarrollo, se puede requerir un mayor porcentaje del tiempo en el diseño y la implementación. Siempre que realice un proceso al menos una vez durante el curso de un proyecto, puede medirlo (cuantitativa y cualitativamente). Una vez que realice los ajustes y vea cómo esos ajustes afectan alguna medida del área del proceso o de la capacidad general para entregar software,

La clave para la mejora del proceso es tener algún tipo de desglose lógico de sus actividades y procesos, determinar cómo medirlos (preferiblemente de manera consistente) y cómo comprender esas mediciones para realizar cambios en el proceso hacia algún final. No se trata de repetir el proyecto, sino de la coherencia en la forma en que repites el proceso.

Creo que la idea de que otras disciplinas de ingeniería no hacen uso de la reutilización es incorrecta. Incluso al diseñar edificios / máquinas, todavía tiene componentes que son utilizados por muchos otros proyectos. Por ejemplo, ¿diseñas tus propios tornillos? Motores? Puertas o ventanas? Por supuesto no. Esos a menudo están diseñados por diferentes personas que luego los usan en diferentes productos. Y a menudo están estandarizados, lo que promueve aún más la reutilización.

Creo que el problema le gusta en complejidad. Simplemente no puede comparar la complejidad de incluso los edificios más complejos con el software complejo. Es una idea generalmente aceptada que la complejidad del software es lo que dificulta el acercamiento desde el lado de la ingeniería. En el momento en que tiene un proceso establecido que le permite crear software de calidad aceptable, descubre que la complejidad del software que necesita para crear saltos en orden de magnitud. Entonces el proceso no puede ser utilizado. Entonces, si tuviéramos que repetir alguna parte del software varias veces hasta que estemos satisfechos con el resultado, nunca terminaríamos ese software.

Por eso se promueve el código limpio. Se puede decir que la capacidad de cambiar el código pasado en base a nuevas experiencias es una forma de reutilización del diseño. Entonces, en lugar de crear diferentes softwares varias veces, refactorizamos y refinamos una sola pieza de software reutilizando nuevas experiencias y diseños sobre viejos problemas. Todo mientras intenta que el software haga lo mismo.

El software es diferente a la mayoría de las otras disciplinas, por lo que la economía de dónde mejor pasamos nuestro tiempo a menudo es diferente.

En construcción, gastas una cierta cantidad de tiempo y dinero en un plano (y el software es mucho más parecido a producir un plano que como construir un edificio), luego, en términos generales, mucho más en construirlo una o más veces. Por lo tanto, vale la pena dedicar mucho trabajo a obtener el plan correcto. Más específicamente a su pregunta: vale la pena repetir el esfuerzo de hacerlo desde cero para mejorar un poco el producto final.

En el software, cuando tiene el modelo, es mucho más barato construir el producto que crearlo. Al menos la mayor parte del tiempo: si el software se incrustará en un marcapasos, estará mucho más cerca de la situación de un constructor de puentes de alguna manera. Pero, en general, la reutilización del software puede ahorrar el 90% del costo de su partida presupuestaria más grande, frente a ahorrar el 90% de una partida presupuestaria mucho más pequeña para construir un puente. Por lo tanto, la reutilización gana mucho más a menudo.

En cuanto a la productividad: cuando construyes, por ejemplo, un puente, te enfrentas a restricciones realmente importantes del mundo real. Imagínese si a los arquitectos se les pagara grandes sumas de dinero para diseñar puentes para juegos multijugador masivos en línea, donde los costos de construcción estuvieran cerca de 0 y la limitación fuera significativamente menor que en el mundo real. Diseñarían puentes que son extrañamente complejos para los estándares de puentes del mundo real. La fase del plan podría llevar un poco más de tiempo.

Además, hay un número limitado de puentes para construir y, dado que el diseño es una parte pequeña del costo, puede pagar por lo mejor, y algunos de los mejores pueden hacer la mayor parte del diseño. Hay cientos de miles de desarrolladores de software y, básicamente, todos ellos tienen una enorme acumulación de cosas que harían si tuvieran tiempo. No vas a encontrar a un chico que haga una gran parte de todo eso; es sorprendente que haya personas que realmente se acerquen.

Su punto real parece ser que podemos estar perdiendo algo al reutilizarlo en lugar de intentar repetirlo y mejorarlo. Creo que tienes un punto. El problema es que, aunque probablemente sería más eficiente a nivel mundial reescribir algunas de las cosas fundamentales y tratar de mejorarlas, quien sea que se haga cargo de ellas asumirá todo el riesgo y probablemente no tanta recompensa. (También existe un gran problema práctico del infierno de la dependencia, que probablemente le quite parte de la victoria al reescribir las cosas, pero no hasta el punto de que no valga la pena, al menos mirando la imagen global. Los derechos de autor y las patentes también pueden forzar un esfuerzo de reingeniería propuesto, hacer un poco de trabajo de reescritura para rehacer piezas más pequeñas de código existente).

En términos de aprendizaje a partir de la repetición - en todas las disciplinas esto ocurre menos en el diseño de la construcción, debido a que es menos repetición, por lo menos la oportunidad de aprender, y tal vez menos beneficios. Además, el proceso de diseño probablemente no sea tan repetible. Es un poco como tener un proceso para escribir una novela. Es casi seguro que un buen proceso puede ayudar, y el software generalmente es mucho más colaborativo que una novela, pero repetir un proceso cuando el objetivo es inventar algo nuevo es problemático. Incluso los novelistas aprenden mucho del pasado, pero un proceso repetible es un factor secundario para los esfuerzos creativos. Y si alguna parte del desarrollo de software es realmente repetible, ¿por qué no lo hace una computadora?

¿La capacidad del software para ser reutilizado impide la mejora y eficiencia del proceso necesarias que se obtienen al repetir un proyecto?

He trabajado como ingeniero de sistemas y software en el mismo gran proyecto durante los últimos 17 años, por cierto (pensando en la referencia del Airbus A380 en su primer enlace) en la industria aeronáutica, aunque mis responsabilidades recaen en el sector de la aviación militar. Historias como esa son básicamente pura ficción, y en realidad son muy divertidas de ver cuando tienes información privilegiada.

Pero para su breve y concisa pregunta: desde mi experiencia, diría que sí y no.

Permítanme decir primero que estoy a favor del reciclaje de software en todas sus formas (bueno, tal vez no todas ...). Las ventajas de reutilizar casi cualquier cosa, desde cortar y pegar fragmentos de código y algoritmos, hasta módulos de código completos y bibliotecas de funciones, en general son mucho mejores que comenzar siempre desde el principio nuevamente (para empujarlo un poco).

La desventaja es, como señala (o al menos infiere), que cuando agrega funcionalidad simplemente reuniendo un conjunto dado de componentes (y, sí, estoy simplificando esto al extremo), realmente no evoluciona como un programador, ingeniero o lo que sea.

Solo mirando a los ingenieros de software que me rodean en el trabajo, sé por una larga experiencia que la mayoría de ellos no lo saben, y lo que es peor: no tienen interés en aprender, nada sobre el producto que estamos construyendo, aparte del mínimo que necesitan para producir el documento o el fragmento de código que se les asignó hacer.

Me estoy desviando un poco del tema aquí, pero mi punto es que cuando los programadores no necesiten aprender para qué se utilizará realmente el código que están construyendo, y no necesitan aprender el funcionamiento interno del sistema, ya que pueden reutilice los componentes ya escritos y probados, entonces la mayoría de ellos simplemente no se molestarán en hacerlo.

De acuerdo, esto también se debe a otras circunstancias, como que el producto que estamos construyendo es increíblemente complejo, y sería imposible que una persona se enterase de todo (y solo estoy hablando de una de las computadoras en el avión, el más complejo de ellos, pero aún así).

Si nuestros ingenieros de software no tuvieran la opción de reutilizar la mayor cantidad de código, estoy convencido de que mejorarían en su profesión en general, y de activos mucho mayores para el proyecto específicamente.

Ah, y es posible que hayas notado que hablo mucho de ellos aquí. Por supuesto, también estoy incluido entre estos ingenieros de software. La excepción es que parezco mucho más curioso y ansioso por aprender cosas nuevas que los demás :-) Cuando me enfrento a una nueva tarea, siempre me encargo de aprender todo lo que pueda, tanto en el forma de hechos y estudiando el código fuente (sí, realmente disfruto eso también).

Ah, maldición, volví a desviarme ... Mi excusa es que no he dormido durante 32 horas, así que mi capacidad de enfoque es un poco ... ¿qué estaba diciendo?

Si alguien sigue leyendo, mi conclusión es que:

Sí , la reutilización excesiva de software hace que los ingenieros de software tengan menos conocimientos, lo que los hace notablemente menos eficientes cuando realmente necesitan saber cómo funcionan las cosas. El análisis de problemas es un buen ejemplo, o incluso solo es capaz de saber si una solución de diseño sugerida es viable. Y, por supuesto, la mejora del proceso también es más difícil de lograr cuando realmente no sabes lo que estás haciendo :-)

y No , reutilizar el software con cuidado puede darle mucho tiempo libre para considerar y planificar mejoras en el proceso.

Como se señala en la respuesta aceptada en otra pregunta de los Programadores, las analogías con la construcción deben tomarse con cuidado:

Una lectura recomendada para esto es La Analogía de la Construcción del Software está rota

El software a menudo se compara con la construcción. Desafortunadamente, esta analogía es defectuosa y las lecciones aprendidas de la industria de la construcción son sospechosas ...

Lo que observé es que los buenos proyectos de software "cambian" mucha repetibilidad en garantía de calidad.

Cuando era un probador en un proyecto de 1,5 años, realizamos ciclos de prueba en lanzamientos semanales de "puntos de control", aproximadamente 70 veces en total durante el proyecto. Eso fue ... bastante repetible, en voz baja (no cambian muchas cosas en una semana). Probar las compilaciones nocturnas ha sido, naturalmente, aún más repetible: aproximadamente 500 veces a través del proyecto (pocos errores entretenidos eran demasiado raros para hacer la diferencia).

Ahora, siguiendo esa analogía "sospechosa", dígame una empresa constructora que ha construido 500 puentes, todos con el mismo equipo.

• Siguiéndolo más, dígame una compañía que ha estado utilizando principalmente los mismos ladrillos y hierro en cada uno de sus nuevos puentes (aquí, me refiero al hecho de que las versiones que probamos tenían en su mayoría los mismos fragmentos de código día a día, semana tras semana - "no cambian muchas cosas").
  

Los maestros constructores son expertos reconocidos por haber diseñado y / o construido decenas, cientos o miles de cosas en su área.

Bien, siguiendo su explicación de repetibilidad citada anteriormente, puedo decir ¿y qué? En aquel entonces, nuestro pequeño grupo de evaluadores no muy especial ha verificado, ver arriba ("aproximadamente 500") cientos de cosas en nuestra área.

En cuanto a los desarrolladores de proyectos, literalmente han construido ("compilaciones nocturnas"). Vea, la palabra es la misma y el significado es correcto en este contexto: cientos de cosas en su área.

Si se quiere continuar con esa analogía "sospechosa" más allá de "miles de cosas", estas cantidades son, nuevamente, nada espectacular en el desarrollo de software cuando se miran las cosas correctas.

• Como ejemplo, otro de mis proyectos pasados ​​(una vez más, nada espectacular, más bien regular), esta vez en el rol de desarrollador, ha estado en marcha durante más de 5 años (8 lanzamientos principales, varias docenas menores). Hubo puntos 5x52~=250de control semanales similares ( de ellos), lanzamientos nocturnos similares ( 5x365~=1800de ellos) y del mismo modo, los mismos equipos de desarrollo / control de calidad que trabajan en estos. Día a día, semana a semana, mes a mes, principalmente cosas repetitivas (no hay muchos cambios entre dos versiones nocturnas), como se prometió, en el rango de miles de veces (1800).

Los proyectos más longevos como Windows o Java, o AutoCAD pueden abarcar 10, 20, 30 años, lo que explica fácilmente la repetición de tantas "miles" de compilaciones y pruebas nocturnas como sea posible.

El concepto de cambio de repetibilidad a QA se vuelve aún más prominente con la integración continua ...

la práctica ... de fusionar todas las copias de trabajo del desarrollador con una línea principal compartida varias veces al día ... CI puede verse como una intensificación de las prácticas de integración periódica ...

Además de las pruebas unitarias automatizadas, las organizaciones que usan CI generalmente usan un servidor de compilación para implementar procesos continuos de aplicación de control de calidad en general: pequeños esfuerzos, aplicados con frecuencia. Además de ejecutar la unidad y las pruebas de integración, dichos procesos ejecutan pruebas estáticas y dinámicas adicionales, miden y perfilan el rendimiento, extraen y formatean la documentación del código fuente y facilitan los procesos manuales de control de calidad. Esta aplicación continua de control de calidad tiene como objetivo mejorar la calidad del software y reducir el tiempo necesario para entregarlo, al reemplazar la práctica tradicional de aplicar el control de calidad después decompletando todo el desarrollo. Esto es muy similar a la idea original de integrar con mayor frecuencia para facilitar la integración, solo se aplica a los procesos de control de calidad ...

Repetibilidad está ahí, tanto como se pueda imaginar.

Con un control de calidad frecuente / continuo, las cosas que salen mal vuelven rápidamente a los desarrolladores que se ven obligados a repetir los intentos de hacerlo bien hasta que las pruebas que no pasan satisfactoriamente pasen. En cierto sentido, ese ciclo de repetición hasta que pasa se asemeja al código cata ,

un ejercicio de programación que ayuda a un programador a perfeccionar sus habilidades a través de la práctica y la repetición ...

Algo de lo que usted dice es cierto: por ejemplo, las bibliotecas resuelven funciones no resueltas por lenguajes de alto nivel que resuelven problemas no resueltos por ensamblaje que resuelven problemas no resueltos por código máquina. Cuando llama a System.out.println () en java, está perdiendo de vista cómo sale una CPU a un dispositivo.

Entonces sí, estás perdiendo algo. Lo que gana es la capacidad de concentrarse en problemas no resueltos. Ahora puede ser que necesite sumergirse en otros aspectos de la tecnología (por ejemplo, cómo funcionan las redes) para resolver un problema. Pero no necesita convertirse en un experto en lectura de lenguaje de máquina cuando todo lo que quiere hacer es crear una página web.

Del mismo modo, los constructores de puentes están resolviendo un problema ligeramente diferente cada vez (es un río diferente). No se preocupan por cómo crear vigas de acero de cierta resistencia a la tracción, o cómo mecanizar tornillos con una cierta tolerancia. Se lo dejan a los especialistas que han resuelto ese problema.

Mire de cerca y verá que toda nuestra sociedad e infraestructura están construidas en un 99% de reutilización y solo en un 1% de progreso real. La mayoría de las cosas nuevas son solo cosas viejas con un poco de algo extra agregado o eliminado. Es la acumulación de conocimiento humano. Puede escribir código en un lenguaje de alto nivel con bibliotecas decentes porque alguien descubrió todas las cosas increíblemente complicadas necesarias para llegar a este punto. Te permite resolver problemas nuevos e interesantes.

Para unir todo esto y responder a los comentarios: no es necesario resolver los problemas que ya se han resuelto para desarrollar la competencia. Además, gran parte de lo que hagas será reinventar la rueda. En resumen, la respuesta es no: no es necesario volver a implementar las funciones de las bibliotecas para dominarlas. Hay muchas oportunidades, algunas de memoria, otras creativas para perfeccionar tu oficio.

Se trata de recursos. Hace años, si desarrollaba proyectos de software para computadoras mainframe grandes, podrían existir durante aproximadamente 15 años con un entorno de desarrollo estático. El programa FORTRAN escrito para calcular la nómina o el programa COBOL se perfeccionó durante décadas porque se usaba constantemente. Había recursos para ver cómo esto podría mejorarse. Ya no tenemos ese tipo de ambiente lento para afinar y pulir las habilidades para un proyecto específico. Pero tomamos las habilidades y las adaptamos a los recursos del próximo proyecto que lo permitan. Pero al final se convierte en una opción de dinero gastado en el nuevo proyecto para hacer el trabajo, o para hacer el nuevo trabajo con una gran cantidad de chapado en oro. Un proyecto chapado en oro significa mejorarlo en el enésimo grado y agregar un montón de campanas y silbatos, incluso si el usuario no

Lo mejor que podemos hacer es mirar el diseño general de un nuevo proyecto y ver cómo se puede mejorar en función de la experiencia pasada del equipo. Pero se necesita una experiencia real del arquitecto de software para tener una visión sobre lo que realmente se considera mejorar el diseño para mejorar las habilidades en lugar de simplemente presentar la última palabra de moda en desarrollo, como Agile, OOP, etc.