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

  

¿Los desarrolladores en 2014 producen software a una velocidad inferior a 10 veces más rápido que sus homólogos en 1986?

Me imagino que desde entonces ha habido al menos una mejora de la productividad de al menos un orden de magnitud. Pero no se aprovecha un solo desarrollo, ni en tecnología ni 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 poderosas
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. escritura fuerte
10. Pruebas unitarias
11. Mejor diseño del lenguaje de programación
12. generación de código
13. Sistemas de control de código fuente
14. Reutilización de código

Y así sucesivamente. 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 solo han observado un reconocimiento y una adopción generalizados recientemente.

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

Cuando comencé mi carrera no existía STL, .NET, QT, etc. Tenías C o C ++ sin procesar, y eso era todo.

Las cosas que solían tardar 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 mejorado los pedidos de magnitud 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 uso de la API de 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ó por sí sola una mejora de la magnitud de la productividad: 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 al instante una respuesta a casi todos los problemas que puede encontrar como desarrollador permite un gran aumento de la productividad. ¿No sabes cómo seleccionar el elemento nth en JQuery? La búsqueda de Google conduce a una respuesta de la pregunta exacta sobre Desbordamiento de pila . ¿No sabes cómo usar overflow en CSS? MDN de Mozilla está aquí . ¿Olvidaste qué significa virtual palabra clave en C #? Google ayuda , de nuevo.

Cuando comencé a programar, no tenía internet. Tenía libros, así como algunos documentos en formato digital almacenados localmente, pero buscarlos a través de libros y documentación fue un proceso lento, y no importa cuántos libros tuviera, había muchos problemas que no eran mencionado allí.

Y, lo que es más importante, casi todos los problemas con los que nos encontramos ya se habían encontrado antes. Internet ayuda a encontrar personas que tuvieron este error y lo resolvieron con éxito. Este no es un tipo de información que encontrará en libros o documentación oficial como MSDN. En su lugar, dicha información suele encontrarse:

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

• En blogs. Encontré mucha de ayuda en los blogs cuando tuve problemas particulares, ¿sería con la configuración de WCF o un servidor proxy que no lo hace? t iniciar o un error críptico cuando se utiliza una API específica en una máquina con una cultura diferente a la de en-US.

• En informes de errores relacionados con software de código abierto. Por ejemplo, fue muy útil recientemente cuando intenté usar 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 para la mayoría de los problemas que se pueden encontrar es especialmente notable si tenemos en cuenta que la mayor parte del tiempo que un equipo dedica a un proyecto es 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, están ahí cuando la ayuda de otros a través de Internet parece crucial . Ejemplo básico: un servicio WCF funciona perfectamente bien en mi máquina , pero falla sin excepción alguna cuando se implementa en producción, mientras que 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 que encuentra una respuesta inmediatamente, mientras que podría haber pasado días buscándola solo (o forzado a volver a escribir una gran parte de la aplicación).

• Por otra parte, la productividad general mejoró en función de múltiples factores, como una mejor gestión de proyectos (Agile, TDD, etc.), una mejor gestión de equipos ( Radical Management por Stephen Denning me viene a la mente), mejores herramientas (depuradores, perfiladores, IDE, etc.), mejor hardware (no, no seré muy productivo si es forzado a escribir en Assembler para una CPU lenta y una 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 instantáneo de conocimientos a nivel mundial! En estos días no necesita conocer las respuestas, solo necesita saber cómo conocer las respuestas, y ese es un sustituto perfectamente adecuado que permite a los desarrolladores dedicar menos tiempo a leer y más tiempo. Codificación, y por lo tanto ser productivo. Significa que todos los programadores del mundo tienen acceso a todas de las respuestas, y todo lo que necesitan hacer es saber cómo formular las preguntas correctas.

Sugeriría que las tendencias que nos empujan en la otra dirección (es decir, hacia una menor productividad) sean al menos tan fuertes como las tendencias que usted preguntó. La experiencia de hacer una herramienta de desarrollo cliente / servidor como VB6 o PowerBuilder estuvo muy cerca del ideal de "Rapid Application Development" (RAD). Debía dibujar sus formularios, y había obvios ganchos para su 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 cliente / servidor dejaron de ser desarrolladores, o se aferraron desesperadamente a, por ejemplo, VB6.

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

Todas estas transiciones tienen buenas razones, y no es justo comparar un proceso que produjo un .EXE nativo (que requiere instalación y administración en cada cliente) con el desarrollo web, ni es completamente justo comparar un proceso que se basa en gran medida en devoluciones de datos con uno que produce una experiencia más perfecta. Pero diré que las prácticas actualmente en boga dan como resultado 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 ciertamente uno no tuvo que preocuparse por los canales de datos subyacentes que obtuvieron datos de los controladores de eventos que hicieron que esto sucediera.

A la inversa, 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 devoluciones de datos) tenemos una tendencia a recurrir a los accesos directos (y eso significa de mala manera). Eso es comprensible, pero sigo pensando que la forma en que se realiza 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 burlarnos de quienes cuestionamos la sabiduría de la minería y 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 ser requisitos cambiantes . 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 suceden una vez que un proyecto del mundo físico como un edificio está casi hecho.

• Otro aspecto importante es que la programación continúa siendo muy manual . Rara vez o nunca, el código generado por RAD entra en producción sin ser modificado manualmente primero.

• El código sigue siendo altamente complejo , y esa complejidad no parece disminuir con las nuevas tecnologías.

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

• Algo que, sin lugar a dudas, ha ocurrido es que ha ocurrido compartimentación . La gran cantidad de tecnologías que uno tiene que saber es que los programadores han tenido que especializarse en un pequeño número de tecnologías para poder ser realmente buenos en ellas, y requieren 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 compañías capaces de crear y mantener un sistema operativo , (computadora de escritorio, móvil, integrado o de otro tipo), se puede contar con los dedos de sus 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 idea de la madurez de la industria del software es que las licencias de software continúan indicando "< companyX > no hace ninguna declaración 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 declara que su producto no es adecuado para ningún propósito en particular. Ese es el estado actual de la técnica.

Si bien se podría discutir con métricas específicas (es decir, ¿han mejorado las cosas en 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 poco la tecnología realmente nueva desde 1970. Sí, los circuitos integrados se han vuelto más largos, más anchos, más anchos, y la fibra de vidrio ha mejorado las velocidades de comunicación, pero por cada paso adelante hay uno atrás. p>

La tecnología del compilador ha permitido una mejora 10x en la "productividad" del programador en comparación con 1970, cuando una función de cifras se produce dividida por el tiempo de codificación real, pero la proliferación de lenguajes de programación y entornos nuevos o "revisados" significa que el programador promedio está gastando más y más tiempo en el modo "ponerse al día", y menos en la actividad productiva. Apple, Google y Microsoft lanzan "actualizaciones" nuevas y sustancialmente incompatibles a sus entornos a una tasa que está justo por debajo de la que provocaría la revuelta entre sus servidores y clientes de programación. Del mismo modo, HTML / CSS / Javascript / lo que sea cada vez más complejo.

En un momento dado, la velocidad a la que podría producirse y propagarse la documentación habría limitado y acorralado toda esta "innovación", pero, gracias a Internet, ya no es realmente necesaria una documentación rigurosa, solo escupe las funciones y confía en los bloggers para descubrir los detalles y ponerlos a disposición.

Añadido: he estado pensando en esto desde ayer, y en particular en el proyecto en el que trabajé desde 1978 hasta 2008. Este proyecto (el IBM System / 38 y sus sucesores) fue algo único ya que desde el principio se hicieron esfuerzos para controlar su complejidad (una de ellas es la división del software en dos partes aproximadamente iguales, con una interfaz de "máquina" entre ellas). En el área particular donde trabajé, varios de mis compañeros de trabajo se dedicaron de manera similar a controlar la complejidad (aunque no usamos ese término mucho en ese momento). 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, como tocar en una orquesta bien entrenada.

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

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

Las tecnologías incluidas en esta máquina 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 de memoria manual, recolección de basura, tipos estáticos, tipos dinámicos, alcance léxico , alcance dinámico, punteros "seguros", punteros "inseguros", ausencia de punteros como concepto de lenguaje, formatos de archivos binarios, formatos de archivos de marcado estructurado, macros, plantillas, evitación de macros y plantillas, Memoria compartida, paso de mensajes, subprocesos, corrutinas, bucles de eventos asíncronos, servicios remotos centralizados, servicios distribuidos, software instalado localmente, arreglos, listas enlazadas, tablas hash y árboles.

El hecho de que muchos de los elementos de la lista anterior se agrupen en grupos que agotan el espacio de solución conocido es muy intencional y debería, por sí solo, informarle algo. Se podría argumentar que las únicas mejoras inequívocas y generales en la praxis que hemos tenido desde que se encendieron por primera vez en el Z3 son la programación estructurada por bloques (a diferencia del código spaghetti) y la protección de la memoria ( muchacho, ¿alguna vez no me pierdo los días en que un error tipográfico podría acabar con toda mi computadora?