¿Cuáles son las causas que conducen a un software sobrebloqueado? [cerrado]

Hoy decidí realizar una instalación limpia para los controladores Creative Sound Blaster, ya que siempre comienzan a fallar por sí solos después de un tiempo. Y eso significaba que tenía que pasar por todo el procedimiento de limpieza. Y eso me llevó casi 2 horas ...

Y honestamente, no puedo ver una razón ¿por qué? Y aunque Creative, en mi humilde opinión, es un ganador absoluto del primer lugar por producir software de baja calidad que nunca funciona, el problema de hinchazón no es exclusivo para ellos.

La PC con controlador de cámara digital Canon tendrá alrededor de 10 entradas Canon que están interconectadas con todo tipo de conexiones. Visual Studio también es un excelente ejemplo, hay alrededor de 50 entradas para la instalación completa, y la reparación de eso solo es posible con un nuking completo. Y una vez que incluso logró arruinar toda la instalación del sistema operativo cuando estaba actualizando de VS2k8 a VS2k8SP1 o algo así. Como resultado, 5GB de espacio libre no fueron suficientes para el parche de 300Mb ...

Así que esto realmente parece ser un problema generalizado. Casi todas las aplicaciones de hoy en día generalmente contienen desempacadores, múltiples "amigos" espías que están instalados, los controladores suelen rondar los 600Mb para todo, incluidas las impresoras, etc.

¿Pero por qué? ¿Es culpa del desarrollador? Aplicaciones como esa son una pesadilla para soportar, nunca funcionan al 100% hoy en día, y casi todos los usuarios que conozco son muy negativos acerca de toda la hinchazón que obtienen como instalación obligatoria de controladores para memoria USB / Impresora / Cámara / Tarjeta de sonido / Navegador.

Parece que NSIS de Nullsoft es el único sistema de configuración limpio que no está hinchado, por lo que sé, por ejemplo, la instalación de Firefox. Instalación limpia, basada en xcopy, sin problemas.

Entonces, ¿por qué las personas no utilizan configuraciones y aplicaciones simples que no están enraizadas en más de 30 capas de interconexión? ¿Es porque los desarrolladores son flojos? Uso de herramientas codegen? ¿Es porque las corporaciones fuerzan las aplicaciones pesadas como algo que los usuarios amarán? ¿Cuál es la causa, y hay alguna esperanza de que el software vuelva a lo básico algún día? ¿Cuáles son los pasos para evitar escribir hinchazón cuando inicias una nueva aplicación desde cero?

Supongo que hay muchas características que alguien pensó que era una buena idea. Sin embargo, si muchas personas tienen ideas separadas que se juntan en una sola aplicación, así es como puede volverse tan complicado. No culparía al desarrollador en el caso de productos corporativos grandes donde debería haber gerentes de producto que tengan la responsabilidad de lo que hay en el producto y cómo optimizarlo desde varias perspectivas.

Otro lado de esto sería la deuda técnica que probablemente no se gestione bien en la mayoría de los casos, ya que no se considera una gran inversión de tiempo. Sospecho que las nuevas características y las correcciones de errores tienen más sentido que las refactorizaciones u otras tareas de deuda que pueden parecer tener poco valor comercial inmediato. ¿Con qué frecuencia un equipo de desarrolladores tendría un par de semanas para limpiar el código heredado si la base del código es bastante antigua? Mi suposición no sería a menudo.

Para citar a Joel en la Carta de estrategia IV: Bloatware y el mito 80/20 :

[...] hay muchas buenas razones para el bloatware. Por un lado, si los programadores no tienen que preocuparse por el tamaño de su código, pueden enviarlo antes. [...] Si su proveedor de software se detiene, antes de enviarlo, y pasa dos meses apretando el código para hacerlo 50% más pequeño, el beneficio neto para usted será imperceptible. [...] Pero la pérdida de esperar dos meses adicionales para la nueva versión es perceptible, y la pérdida para la compañía de software que tiene que renunciar a dos meses de ventas es aún peor.

Muchos desarrolladores de software están seducidos por la antigua regla "80/20". Se parece hacer mucho sentido: el 80% de la gente usa el 20% de las características. Por lo tanto, se convence de que solo necesita implementar el 20% de las funciones, y aún puede vender el 80% de las copias.

Lamentablemente, nunca es el mismo 20%. Todos usan un conjunto diferente de características. [...]

Cuando comienzas a comercializar tu producto "lite", y le dices a la gente, "oye, es lite, solo 1 MB", tienden a estar muy contentos, luego te preguntan si tiene su característica crucial, y no lo tiene, entonces No compran su producto.

Una gran parte de esto tiene que ver con las dependencias de un producto. Su sistema operativo incluye muchas bibliotecas estándar para todo tipo de cosas. Sin embargo, estas bibliotecas estándar tienen diferentes versiones a lo largo de la evolución del sistema operativo, y cualquier instalador genérico no puede asumir que la versión específica con la que se creó estará realmente presente en el sistema operativo.

Por lo tanto, el instalador completo deberá incluir la versión correcta de cada dependencia para asegurarse de que todo funcione definitivamente después de la instalación, sin importar el estado inicial de cada dependencia en la computadora de destino. Esto puede ser una hinchazón bastante importante para ciertos tipos de aplicaciones, por ejemplo, aplicaciones basadas en .NET que deben implementarse en sistemas Windows XP.

Hasta hace poco, un sistema de instalación con el que trabajaba necesitaba que se instalara cada versión anterior de .NET para poder implementar la última versión, por lo que cualquier aplicación de .NET 3.5 requería binarios de instalación para .NET 1, 2, 2.5 y 3 EN LA PARTE SUPERIOR de 3.5. En este caso, solo el instalador está hinchado.

Una solución alternativa es un instalador web, que descarga solo aquellos componentes que en realidad no están presentes en el sistema de destino, y esto puede ser un gran beneficio de tamaño / hinchazón. Por supuesto, limita sus instalaciones a sistemas que tienen conectividad a Internet.

Creo que mucho tiene que ver con capa tras capa de código de biblioteca. Obviamente, cuando usa una biblioteca, no usa todo en ella, por lo que el exceso se suma a medida que incluye más y más bibliotecas.

Combine eso con el hecho de que el costo de una hora de trabajo de un programador se está volviendo cada vez más costoso mientras que la potencia de procesamiento / almacenamiento de la computadora típica se está volviendo más barata cada año, verá que en realidad es más rentable de esta manera.

• "Necesitamos algo que hacer X. Usemos la biblioteca $ BIGFATLIBDESIGNEDFORSOMETHINGELSE, porque la usé en un proyecto diferente"
• "Creo que ya no necesitamos esta parte del código, pero para asegurarnos de que nada se rompa, solo manténgalo"
• No o no hay suficientes pruebas unitarias, lo que lleva a
• Sin refactorización
• Sin seguimiento, donde las configuraciones se han almacenado a lo largo de los años, por lo que ahora las configuraciones están en todas partes
• ...

Es un círculo vicioso donde todos en los ciclos de desesperación pueden ser culpados . Un ciclo de desesperación consta de los siguientes pasos:

1. La gente de negocios pide características hinchadas.
2. Los desarrolladores implementan las características hinchadas aunque saben que no deberían.
3. Los clientes pagan por características hinchadas aunque solo quieran el producto pero no la estúpida característica.
4. La gente de negocios cree que los clientes quieren las características hinchadas.
5. Ve al paso uno y repite.

¿Cómo lo paras? No hay una respuesta fácil sobre cómo, pero está claro que para detener el ciclo, se debe romper uno de los pasos. Por lo tanto, solo pueden romperlo empresas, desarrolladores o consumidores que tomen una acción revolucionaria.

1. Un ingeniero intentó optimizar un módulo pero introdujo varios problemas con los clientes. Entonces, su gerente dijo que no. Entonces, el ingeniero decidió no "causar problemas" hasta que los problemas lo molesten.
2. Para un sistema complejo, el proveedor ya agregó muchos parches y corrigió miles de errores para que sea estable en el entorno del cliente. No tiene buena calidad desde el punto de vista del software, pero funciona. Nadie quiere reescribirlo para corregir la misma cantidad de errores nuevamente.
3. por razones de compatibilidad con versiones anteriores, incluso si una característica no es popular en el mercado, debemos mantenerla allí.

Su invariablemente pereza, eso es lo que causa la hinchazón. (o el lodo como en el artículo seminal sobre este tema, la gran bola de barro )

Por ejemplo, donde trabajo tenemos una aplicación C ++ "heredada" que, sin embargo, está bastante bien diseñada. Los clientes hablan con una API que habla con un servidor que funciona con DB. Todo bien hecho. Recientemente necesitábamos un módulo adicional, pero en lugar de implementarlo correctamente, el desarrollador decidió implementarlo en .NET, y lo que es peor, decidió que acceder a los datos a través de la API era demasiado difícil (no es pero ...) haría conexiones DB directamente. Así que ya ves cómo ocurre este tipo de desastre. (y todo con el acuerdo de la AT que puso "rápido" sobre "bueno")

También he visto este tipo de cosas antes: en un lugar antiguo, una pequeña parte de la GUI era html, ya que algunos desarrolladores pensaron que era una buena idea escribir los datos en html y que la GUI lo mostrara. Entonces 1 parte pequeña hace algo diferente al resto.

En resumen, la pereza es mala y la consistencia es buena (independientemente de la tecnología utilizada). Prefiero tener una aplicación totalmente MFC que una que sea en parte MFC y en parte Winforms y en parte WebGL con muchas arquitecturas de fondo diferentes que lo unen todo.