Como afirmaron DeMarco y Lister en Peopleware hace unos 20 años, la gran mayoría de los proyectos de software fallidos fracasan no debido a desafíos técnicos, sino a problemas sociológicos . Esto no ha cambiado en las últimas décadas, sin importar cuánto hayan mejorado nuestras herramientas.
Mala gestión, expectativas poco realistas, no conseguir a las personas adecuadas para el trabajo, y / o no dejarlos hacer su trabajo, por lo tanto, no mantenerlos; lugares de trabajo y herramientas que no son adecuados para el trabajo de desarrollo de SW; conflictos personales no manejados; la política ; Estos son solo algunos de los problemas típicos que pueden hacer que un proyecto esté condenado desde el principio.
¿Por qué escribir un buen código es más difícil?
No estoy muy convencido de que sea realmente más difícil escribir un buen código ahora que hace décadas. De hecho, en comparación con el código de máquina o el ensamblaje, todo lo que tenemos ahora en la corriente principal es mucho más fácil de manejar. Es posible que necesitemos producir más.
¿Es solo por los factores mencionados, el tiempo y la complejidad?
Sí, la complejidad alcanzable ciertamente ha aumentado (y continúa aumentando) a medida que aumenta el poder de nuestras herramientas. En otras palabras, seguimos empujando los límites. Lo que para mí se traduce de manera que es igualmente difícil resolver los mayores desafíos de hoy como lo fue hace 30 años para resolver los mayores desafíos de ese día.
OTOH ya que el campo ha crecido enormemente, ahora hay muchos más problemas "pequeños" o "conocidos" que hace 30 años. Estos problemas son técnicamente (no deberían) (ser) un desafío más, pero ... aquí ingresa la máxima anterior :-(
También el número de programadores ha crecido enormemente desde entonces. Y al menos mi percepción personal es que el nivel promedio de experiencia y conocimiento ha disminuido, simplemente porque hay muchos más jóvenes que llegan continuamente al campo que personas mayores que podrían educarlos.
¿Es que las metodologías no se practican correctamente?
En mi humilde opinión, no. DeMarco y Lister tienen algunas palabras duras sobre las metodologías big-M. Dicen que ninguna Metodología puede hacer que un proyecto tenga éxito, solo las personas del equipo pueden hacerlo. OTOH, las pequeñas metodologías que elogian están bastante cerca de lo que ahora conocemos como "ágil", que se está extendiendo ampliamente (en mi humilde opinión, por una buena razón). Sin mencionar las buenas prácticas como las pruebas unitarias y la refactorización, que hace apenas 10 años no eran ampliamente conocidas, y hoy en día incluso muchos graduados lo saben.
Los problemas relacionados con la codificación en plazos poco realistas y el manejo de la deuda técnica se conocen desde Weinberg '71 y también Brooks '72. La literatura se vuelve difícil de desenterrar en línea antes de eso, pero estoy bastante seguro de que hay viejos informes de CDC, IBM y NASA que dicen lo mismo.
fuente
Creo que todos tenemos nuestras propias ideas y umbrales para el "Buen Código". Sin embargo, hay una serie de problemas que contribuyen todos:
Al final, creo que es mejor perseguir mejor que perseguir "bueno" o "mejor". Si viéramos el mejor código, ¿lo reconoceríamos como tal?
fuente
¿Por qué escribir un buen código es más difícil?
Porque el software se está construyendo cada vez más sobre capas de abstracción. Cada nueva tecnología que pretende hacer que el desarrollo sea más fácil y rápido solo agrega un nivel más de complejidad que un desarrollador necesita comprender. Ahora, esta abstracción puede tener un gran beneficio para la productividad, pero si no comprende lo que intentan ocultar, hace que el software sea más susceptible a errores y mala calidad.
fuente
De hecho, no es posible. Pero no por ninguna de las razones que ya has escuchado.
El alcance de la gran mayoría de los proyectos va mucho más allá de la capacidad de un cerebro humano. Es por eso que a las personas se les ocurrió la idea de la abstracción , es decir, seguir ocultando detalles y subir más alto el árbol de abstracción hasta que la densidad de las ramas (cantidad de información a manejar) disminuya a un ritmo aceptable.
Hemos hecho eso, hemos resuelto el problema de complejidad, pero eso no ha eliminado el problema más grande que teníamos antes.
Todavía es demasiado complejo para nosotros manejarlo.
Para crear una solución de alta calidad, necesitamos poder ver y comprender simultáneamente todo, al mismo tiempo, es decir, todos los módulos con detalles de implementación grandes y pequeños. De una vez para ver las discrepancias, vea cada parte del código en el contexto de todos los escenarios posibles y optimice toda la base del código al mismo tiempo.
Nunca podremos hacer eso.
Y si no podemos, nunca produciremos código de calidad.
Los gerentes verán la combinación de módulos, pero no conocerán los problemas internos y las limitaciones por módulo.
Los programadores de módulos conocerán las limitaciones locales, pero no podrán optimizarlo en el contexto de una imagen más amplia.
No hay forma de comunicar el entendimiento entre gerentes y programadores (e incluso entre programadores). E incluso si existiera, la capacidad del cerebro humano no podría manejar eso.
Hay poco que podamos hacer excepto seguir intentándolo (un ejercicio inútil). Simplemente mantengamos el código más o menos operativo y disfrutemos de la vida.
fuente
Niego la premisa de tu pregunta. Es más fácil que nunca escribir un buen código, y por eso estamos abordando problemas mucho más difíciles de lo que hemos abordado antes.
No quiero elegir ningún proveedor en particular, pero compare Windows 1.0 con Windows 7. Este último contiene miles de veces más código, pero el tiempo medio entre bloqueos se ha multiplicado por cien. Se supone que podemos incrustar una hoja de cálculo de Excel en un documento de Word desde Windows 3.1, pero en estos días realmente funciona más o menos.
Sin querer caer en el sentimentalismo de "Ustedes, niños hoy en día con su tipo de pato y VM", sugeriría que no tienen idea de lo difícil que fue escribir un buen código en los años 80: modelos de memoria TINY, SMALL y HUGE, superposiciones , llamadas de sistema operativo no rentista (estremecimiento). Buen viaje a todo eso.
fuente
Las aplicaciones modernas son más complejas que hace 20-30 años, porque su entorno es más rico y versátil.
Era típico que un programa DOS se sentara en un bucle cerrado esperando la siguiente pulsación de tecla del usuario, y luego invoque el código correspondiente, y vuelva a esperar la próxima pulsación de tecla.
Cualquier aplicación moderna en la que no pueda usar el mouse para nada, tiene un serio problema de explicación. Y las cosas pueden suceder en cualquier orden, ya que es perfectamente posible que el usuario escriba, haga clic con el mouse y continúe escribiendo mientras se actualizan las fuentes RSS en la aplicación que muestra las entradas más recientes para el usuario mientras escribe.
Todas estas cosas multitarea son intrínsecamente mucho más complejas que cuando todo lo que tenía que pensar eran las claves del usuario. Eso hace que sea más difícil escribir un código realmente bueno.
Con suerte, cuando los investigadores hayan descubierto cómo podemos hacer que los programas multitarea sean más utilizables desde el punto de vista de los desarrolladores, esto puede facilitarse, pero por ahora estamos atrapados con todos tratando de hacerlo bien, pero sin saber exactamente cómo hacerlo. eso.
fuente
Me parece que el software se ha expandido para llenar la velocidad del procesador disponible, la memoria, el disco y el tiempo del programador. Se podría afirmar que eso se debe a que el software logra mucho más. Bueno, estoy seguro de que logra mucho más, pero no lo suficiente como para justificar la hinchazón.
Creo que hay una antigua ley de la ciencia que vale la pena recordar:
Francois Rabelas (monje y satírico francés 1494-1553)
fuente
De hecho, creo que se ha vuelto más fácil escribir un buen código, es decir, programas que funcionan según lo esperado y que se pueden mantener durante la última década. Las herramientas disponibles son mejores ahora, las bibliotecas son más maduras y completas, el hardware se ha vuelto mucho más rápido, por lo que no tenemos que usar trucos de optimización.
Entonces, ¿por qué no lo hacemos?
En mi opinión, la razón principal es que constantemente buscamos formas y excusas para abusar de las cosas. En lugar de seguir el camino antiguo, fácil y probablemente aburrido, como crear un ejecutable de Windows, empujamos los límites de lo posible y buscamos formas de, por ejemplo, recrear algo como PhotoShop como una aplicación web. ¿Por qué? Porque podemos. O al menos eso creemos.
fuente
¿Cuándo fue la última vez que ALGUIEN no escribió una hazaña o no estudió para hacerlo? ¿Cuántos errores se han descubierto en las bibliotecas principales de C? Casi ninguno y unos pocos. Todo lo que digo es que las personas son capaces de tener un código excelente. Las mejores herramientas e idiomas lo hacen menos 'requerido' y más 'opcional'. No es que piense que todos deberíamos escribir un código realmente horrible, pero cuando pienso en construcciones lógicas complicadas ... nadie habría soñado con escribir algo con matrices hash en ensamblado. Tenía que haber una 'mejor' forma de manejar la lógica en lugar de usar una construcción complicada. Incluso si el código es hermoso, a veces el enfoque no es tan elegante. Creo que resuelve el problema que mencionaste. Un buen código no siempre está organizado,
fuente
Creo que se debe a que mejores herramientas y computadoras más rápidas y con mayor capacidad de respuesta significan que esperamos obtener mucho más tiempo de complejidad de producto final por unidad de lo que obtuvimos hace unos años (o algunas décadas). Por lo tanto, la complejidad de las aplicaciones sigue aumentando y nuestras suposiciones sobre qué nivel de productividad razonable sigue creciendo.
Donde trabajo, los desarrolladores siempre tienen prisa (porque siempre hay más cosas que los clientes desearían de las que tienen tiempo). Por lo tanto, se copian muchos bloques de código con una edición mínima y sin el esfuerzo realizado para comprenderlos realmente. Y, por supuesto, se cometen errores. Acabo de ver que se solucionó un error, en el que un desarrollador había copiado un código que había optimizado, sin darme cuenta de que las suposiciones que hacían válida la optimización no eran ciertas en el lugar donde lo estaba colocando.
Todo esto se reduce a las expectativas, tanto internas (nuestras propias expectativas) como de nuestras organizaciones. Intentamos hacer todo lo posible en el menor tiempo posible. Y los errores inevitablemente resultan.
Además, la capacidad de respuesta de la computadora fomenta una edición rápida y rápida, luego una ejecución de compilación y prueba. En los viejos tiempos (como hace 35 años), el tiempo de respuesta era tan lento que imprimía el código (la fuente era las tarjetas perforadas en ese momento) y hacía un paso manual del código antes de enviar mi mazo. Ahora, simplemente editamos compilar y ejecutar. Entonces, muchos errores que habríamos detectado, a través de un recorrido de código metódico, ahora contamos con el compilador y / o el conjunto de pruebas unitarias para detectar.
fuente
¿Cómo han empeorado las personas para producir un buen código?
Si se toma .NET y un lenguaje como C #, por ejemplo (y me doy cuenta que no es la única plataforma / idioma), yo diría que la codificación también se ha convertido en mucho, mucho más fácil debido a la automatización de muchas cosas dentro del Visual Studio ambiente.
En todo caso, el simple hecho de que ahora tenemos IDE muy sofisticados capaces de guiarnos a través del proceso de codificación y desarrollo hace que sea más fácil lograr un "buen código".
Los programadores ahora pueden enfocarse en producir una buena estructura en lugar de pasar tanto tiempo simplemente escribiendo corchetes y llaves y nuevas líneas y recordando llamadas a métodos y nombres de clases.
Mis dos centavos.
fuente
Sí, nosotros como industria no estamos practicando lo que se sabe que son buenas metodologías. Referencia: Desarrollo de software de Steve McConnell Software Low Fruit Hanging .
fuente
Gran tautología lógica.
El código no mejora porque la gente sigue moviendo la definición de "bueno".
Si puede "discutir un buen código", entonces no puede comparar y realmente no puede decidir si es "un desafío" o no.
fuente