¿Realmente no ha habido una cosa en los últimos 20 años que haya proporcionado grandes ganancias en el desarrollo de software? [cerrado]

En No Silver Bullet , Fred Brooks hace una variedad de predicciones sobre el futuro de la ingeniería de software, resumidas mejor por:

No existe un desarrollo único, ni en tecnología ni en técnica de gestión, que por sí solo prometa una mejora de un orden de magnitud en productividad, confiabilidad y simplicidad.

Su argumento es muy convincente. Brooks estaba escribiendo en 1986: ¿tenía razón? ¿Los desarrolladores en 2014 producen software a un ritmo menos de 10 veces más rápido que sus contrapartes en 1986? Según alguna métrica apropiada: ¿qué tan grande ha sido realmente la ganancia en productividad?

¿Los desarrolladores en 2014 producen software a un ritmo menos de 10 veces más rápido que sus contrapartes en 1986?

Me imagino que desde entonces ha habido una mejora de al menos un orden de magnitud en la productividad. Pero no aprovechando un solo desarrollo, ya sea en tecnología o en técnica de gestión.

Los aumentos en la productividad se han producido por una combinación de factores. Nota: Esta no es una lista completa:

1. Mejores compiladores
2. Computadoras mucho más potentes
3. Intellisense
4. Orientación a objetos
5. Orientación funcional
6. Mejores técnicas de gestión de memoria
7. Comprobación de límites
8. Análisis de código estático
9. Mecanografía fuerte
10. Examen de la unidad
11. Mejor diseño del lenguaje de programación.
12. Codigo de GENERACION
13. Sistemas de control de código fuente
14. Reutilización de código

Y así. Todas estas técnicas se combinan para producir ganancias de productividad; No hay una sola bala de plata que haya producido una aceleración de orden de magnitud.

Tenga en cuenta que algunas de estas técnicas han existido desde los años sesenta, pero recientemente solo han observado un amplio reconocimiento y adopción.

La respuesta de Robert Harvey es buena, pero creo que omitió la que puede ser la razón más importante por la que los programadores son más productivos que nunca: la disponibilidad generalizada de bibliotecas de software.

Cuando comencé mi carrera no había STL, .NET, QT, etc. Tenías C o C ++ en bruto, y eso fue todo.

Las cosas que solían llevar días o semanas o trabajar (análisis XML, conexiones TCP / IP, comunicación HTTP) ahora se pueden hacer con un puñado de líneas de código C #. Aquí es donde hemos obtenido órdenes de magnitud mejores en términos de productividad general del desarrollador.

Nuestro producto actual utiliza un marco de ventana de acoplamiento que compramos a un proveedor. Esto me permitió tener una interfaz de usuario de ventana de acoplamiento completamente funcional en cuestión de minutos. Me estremezco al pensar en lo que se necesitaría para hacer eso en los días de usar la API win32.

En aras de la discusión, no estoy de acuerdo con la afirmación de Fred Brooks .

Hay una mejora en la tecnología que permitió solo una mejora en la productividad de un orden de magnitud: Internet , y más precisamente la disponibilidad progresiva de conexión a Internet en cada hogar en las últimas dos décadas.

Ser capaz de encontrar instantáneamente una respuesta a casi todos los problemas que puede encontrar como desarrollador permite un gran impulso en la productividad. ¿No sabe cómo seleccionar el enésimo elemento en JQuery? La búsqueda en Google lleva a una respuesta de la pregunta exacta sobre Stack Overflow . ¿No sabes cómo usar overflowCSS? El MDN de Mozilla está aquí . ¿Olvidó qué virtualpalabra clave significa en C #? Google ayuda , de nuevo.

Cuando comencé a programar, no tenía internet. Tenía libros, así como también documentación en formato digital almacenada localmente, pero buscar en libros y documentación fue un proceso lento, y no importaba cuántos libros tuviera, había muchos problemas que no se mencionaban allí.

Más importante aún, casi todos los problemas con los que te encuentras ya fueron encontrados por alguien más. Internet ayuda a encontrar personas que tuvieron este error y lo resolvieron con éxito. Esta no es una especie de información que encuentre en libros o documentación oficial como MSDN. En cambio, dicha información generalmente se encuentra:

• En Stack Overflow, obviamente. Por ejemplo, no he visto ningún libro que mencione este problema .

• En los blogs Encontré mucha ayuda en los blogs cuando tuve problemas particulares, ya sea con la configuración de WCF o con un servidor proxy que no se inicia o con un error críptico al usar una API específica en una máquina con una cultura diferente de en-US.

• En informes de errores relacionados con el software de código abierto. Por ejemplo, fue muy útil recientemente cuando intenté usar el MAAS de Ubuntu y cuando usé PXE. Tampoco encuentras este tipo de información en los libros.

La importancia de la disponibilidad inmediata de una respuesta a la mayoría de los problemas que uno puede encontrar es especialmente notable si tenemos en cuenta que la mayor parte del tiempo que un equipo dedica a un proyecto se dedica a mantenerlo .

• Internet no ayuda mucho durante las fases de arquitectura y diseño (Programmers.SE podría ayudar, pero sería mucho más valioso para un arquitecto leer libros sobre arquitectura y diseño, aprender patrones de diseño, etc.).

• Comienza a ser útil durante los pasos de prueba e implementación, cuando surgen problemas reales.

• Pero la mayoría de los problemas que aparecen durante el mantenimiento, es allí cuando la ayuda de otros a través de Internet parece crucial . Ejemplo básico: un servicio WCF funciona perfectamente en mi máquina , pero falla sin excepción alguna cuando se implementa en producción, mientras funcionó durante las últimas dos semanas. Esto me sucedió y estoy agradecido a los escritores de blogs y a la comunidad de Stack Overflow por ayudarme a resolver el problema en cuestión de horas en lugar de semanas.

¿Justificaría un aumento de x10 en la productividad? Difícil de decir.

• Por un lado, hay casos en los que encuentra una respuesta de inmediato, mientras que podría haber pasado días buscándola solo (o verse obligado a reescribir una gran parte de la aplicación).

• Por otro lado, la productividad general mejoró en función de múltiples factores, como una mejor gestión de proyectos (Agile, TDD, etc., viene a la mente), una mejor gestión del equipo ( viene a la mente la Gestión Radical de Stephen Denning), mejores herramientas (depuradores, perfiladores , IDEs, etc.), mejor hardware (no, no seré muy productivo si me veo obligado a escribir en Assembler para una CPU lenta y RAM muy limitada), etc.

Yo diría que internet es un buen candidato. StackOverflow y Google son las herramientas más poderosas de un desarrollador moderno. ¡Intercambio de conocimiento instantáneo a nivel mundial! En estos días no necesita saber las respuestas, solo necesita saber cómo conocer las respuestas, y ese es un sustituto perfectamente adecuado que permite a los desarrolladores pasar menos tiempo leyendo y más tiempo codificando, y así ser productivos. Significa que todos los programadores del mundo tienen acceso a todas las respuestas, y todo lo que necesitan hacer es saber cómo hacer las preguntas correctas.

Sugeriría que las tendencias que nos empujan en la otra dirección (es decir, hacia una menor productividad) son al menos tan fuertes como las tendencias sobre las que preguntó. La experiencia de hacer una herramienta de desarrollo cliente / servidor como VB6 o PowerBuilder estuvo muy cerca del ideal de "Desarrollo rápido de aplicaciones" (RAD). Debes dibujar tus formularios, y hay ganchos obvios para tu código de procedimiento o SQL.

El desarrollo web, al menos inicialmente, destruyó muchas de las técnicas e infraestructura que hicieron posible estas cosas, y muchos desarrolladores de clientes / servidores simplemente dejaron de ser desarrolladores o se aferraron desesperadamente a, por ejemplo, VB6.

La transición al desarrollo web fuertemente orientado al cliente fue otra experiencia de tala y quema; Microsoft estaba volviendo al ideal RAD con WebForms, y luego rápidamente cayó en desgracia. En cambio, se esperaba que los desarrolladores abusaran de la infraestructura (por ejemplo, XMLHttpRequest, que rara vez se usa para XML) y de lo contrario se monitorean con un bajo nivel de abstracción en un esfuerzo por hacer que sus sitios web sean más interactivos

Hay buenas razones detrás de todas estas transiciones, y no es justo comparar un proceso que produjo un .EXE nativo (que requiere instalación y administración en el cliente individual) con el desarrollo web, ni es completamente justo comparar un proceso que depende en gran medida en devoluciones con una que produce una experiencia más fluida. Pero diré que las prácticas actualmente en boga resultan en algunos procesos de pensamiento sorprendentemente de bajo nivel entre las personas que se perdieron el cliente / servidor, RAD y similares. Los botones de cliente / servidor simplemente funcionaron, y uno ciertamente no tuvo que preocuparse por los canales de datos subyacentes que llevaron los datos a los controladores de eventos que hicieron que esto sucediera.

Por el contrario, los desarrolladores más contemporáneos tienden a pensar que aquellos de nosotros que hicimos el desarrollo cliente / servidor (o incluso el desarrollo web basado en postback) tenemos una tendencia a recurrir a atajos (y significan eso de mala manera). Eso es comprensible, pero sigo pensando que la forma en que se lleva a cabo el desarrollo contemporáneo es sorprendentemente bajo, y los días de búsqueda de una "bala de plata" parecen haber dado paso a la era de burlarse de aquellos de nosotros que cuestionamos la sabiduría de la minería y la minería. fundiendo nuestro propio plomo.

La tecnología ha avanzado mucho y ahora tenemos todas las cosas que Robert Harvey enumera en su respuesta, pero:

• El problema parece estar cambiando los requisitos . El cliente sabe que no habrá desperdicio de materiales al cambiar los requisitos de un proyecto de software, por lo que lo hacen. Ese tipo de cambios en los requisitos casi nunca ocurren una vez que un proyecto del mundo físico, como un edificio, está a medio hacer.

• Otro aspecto importante es que la programación continúa siendo altamente manual . Raramente, si alguna vez, el código generado por RAD entra en producción sin ser modificado a mano primero.

• El código continúa siendo muy complejo , y esa complejidad no parece disminuir con las nuevas tecnologías.

• La tasa de plazos no cumplidos o los presupuestos excedidos continúa siendo mayor que los de otras disciplinas, y muchas veces se incurre en deudas técnicas para cumplirlos, generando costos ocultos.

• Algo que, sin duda, sucedió es que ha ocurrido la compartimentación . La gran cantidad de tecnologías que uno debe conocer es que los programadores han tenido que especializar un pequeño número de tecnologías para ser realmente buenos en ellas, lo que requiere diferentes tipos de expertos para completar un gran proyecto.

• Una cosa que habla de la complejidad del software es que, si bien hay literalmente cientos de fabricantes de automóviles en el mundo, la lista de empresas capaces de crear y mantener un sistema operativo (de escritorio, móvil, integrado o de otro tipo) se puede contar con los dedos. de tus manos

• Todo lo anterior ha creado una situación en la que no hay suficientes personas estudiando para ser programadores , por lo que los gobiernos han creado campañas para motivar a más estudiantes a tomar esa carrera.

• Una muestra de la madurez de la industria del software es que las licencias de software continúan afirmando que "<empresa X> no hace representaciones sobre la idoneidad de este software para ningún propósito en particular. Se proporciona" tal cual "sin garantía expresa o implícita". Imagine un fabricante de hardware que dice que su producto no es adecuado para ningún propósito en particular. Ese es el estado del arte en este momento.

Si bien uno podría discutir con métricas específicas (es decir, ¿han mejorado las cosas por un factor de 9.98?), Yo (hablando como algo antiguo) tengo que estar de acuerdo con el sentimiento general del comentario de Brooks.

En primer lugar, se ha inventado muy poca tecnología verdaderamente nueva desde quizás 1970. Sí, los circuitos integrados se han vuelto más largos, más bajos, más anchos, y la fibra de vidrio ha mejorado las velocidades de comunicación, pero por cada paso adelante hay uno atrás.

La tecnología del compilador ha permitido una mejora de aproximadamente 10 veces en la "productividad" del programador frente a 1970, cuando se calcula que la función se produce dividida por el tiempo de codificación real, pero la proliferación de lenguajes y entornos de programación nuevos o "revisados" significa que el programador promedio gasta más y más tiempo en modo "ponerse al día" y menos en actividad productiva. Apple, Google y Microsoft arrojan "actualizaciones" nuevas y sustancialmente incompatibles a sus entornos a un ritmo justo por debajo del que provocaría una revuelta entre sus servidores ... er, programando clientes. Del mismo modo, HTML / CSS / Javascript / lo que sea se vuelve más complejo.

Hubo un tiempo en que la velocidad a la que se podía producir y propagar la documentación habría limitado y acorralado toda esta "innovación", pero, gracias a Internet, la documentación rigurosa ya no es realmente necesaria: simplemente expulse las funciones y confíe en los bloggers para descubra los detalles y póngalos a disposición.

Agregado: He estado pensando en esto desde ayer, y en particular pensando en el proyecto en el que trabajé desde 1978 hasta 2008. Este proyecto (el Sistema IBM / 38 y sus sucesores) fue algo único ya que desde el principio los esfuerzos fueron hecho para controlar la complejidad del mismo (uno es la división del software en dos partes más o menos iguales, con una interfaz de "máquina" entre ellos). En el área particular donde trabajé, varios de mis compañeros de trabajo se dedicaron de manera similar a controlar la complejidad (aunque en ese momento no usamos mucho ese término). El resultado fue un producto que (al principio) era bastante robusto y un "éxito" con los clientes prácticamente desde el principio. Y fue un placer trabajar en él, como tocar en una orquesta bien entrenada.

Por supuesto, a lo largo de los años, la complejidad se deslizó, generalmente a instancias de los planificadores y gerentes de mercado que no apreciaban el control de la complejidad (que de alguna manera es diferente de simplemente mantener la simplicidad). No tengo la sensación de que esto fuera inevitable, pero era imposible de evitar en este caso sin un gerente (como Glenn Henry hizo originalmente) que rechaza las fuerzas de la confusión.

Gran parte de lo que hemos aprendido en la práctica de ingeniería de software en los últimos 30 años es la forma "la tecnología X puede acelerar el desarrollo inicial de un nuevo software, pero si no pasa tanto o más tiempo pensando en cómo y cuándo usarlo como lo guardó al usarlo, a la larga convertirá su aplicación en un pantano de deudas técnicas, lo que le costará órdenes de magnitud más tiempo y esfuerzo en mantenimiento ".

Las tecnologías que se incluyen en esta maquinilla de afeitar incluyen: lenguaje ensamblador codificado a mano, compiladores, intérpretes, bibliotecas de procedimientos, programación imperativa, programación funcional, programación orientada a objetos, asignación manual de memoria, recolección de basura, tipos estáticos, tipos dinámicos, alcance léxico, alcance dinámico , punteros "seguros", punteros "inseguros", la ausencia de punteros como concepto de lenguaje, formatos de archivo binario, formatos de archivo de marcado estructurado, macros, plantillas, evitación de macros y plantillas, memoria compartida, transmisión de mensajes, hilos, corutinas, bucles de eventos asíncronos, servicios remotos centralizados, servicios distribuidos, software instalado localmente, matrices, listas vinculadas, tablas hash y árboles.

El hecho de que muchos de los elementos de la lista anterior vengan en grupos que agoten el espacio de solución conocido es muy intencional y, en sí mismo, debería decirle algo. Se podría argumentar que las únicas mejoras generales inequívocas en la praxis que hemos tenido desde que encendieron el Z3 por primera vez son la programación estructurada en bloques (a diferencia del código de espagueti) y la protección de la memoria (chico, nunca me pierdo los días en que un error tipográfico podía destruir toda mi computadora).