Quais são as causas que levam a um software sobrecarregado? [fechadas]

Hoje, decidi executar uma instalação limpa dos drivers Creative Sound Blaster, pois eles sempre começam a funcionar sozinhos depois de algum tempo. E isso significava que eu tinha que passar por todo o procedimento de limpeza. E isso me levou quase 2 horas ..

E honestamente, não vejo uma razão para isso ?! E, embora a Creative, IMHO, seja a vencedora absoluta do 1º lugar por produzir software de baixa qualidade que nunca funciona, o grande problema não é exclusivo deles.

O PC com o driver da câmera digital Canon terá cerca de 10 entradas Canon interconectadas com todos os tipos de conexões. O Visual Studio também é um excelente exemplo, existem cerca de 50 entradas para instalação completa e a reparação dessa coisa só é possível com nuking completo. E uma vez ele conseguiu arruinar toda a instalação do sistema operacional quando eu estava atualizando do VS2k8 para o VS2k8SP1 ou algo assim. Acontece que 5 GB de espaço livre não eram suficientes para o patch de 300 Mb ...

Então, isso realmente parece ser um problema generalizado. Quase todos os aplicativos hoje em dia geralmente contêm desempacotadores, vários "amigos" spywarish que estão instalados; os drivers geralmente têm cerca de 600 Mb para tudo, incluindo impressoras e assim por diante.

Mas por que? É culpa do desenvolvedor? Aplicativos como esse são um pesadelo para oferecer suporte, eles nunca funcionam 100% hoje em dia, e quase todos os usuários que conheço são muito negativos sobre todo o inchaço que recebem como instalação obrigatória de driver para pen drive USB / Impressora / Câmera / Placa de som / Navegador.

Parece que o NSIS da Nullsoft é o único sistema de instalação limpo que não está inchado, pelo que sei, por exemplo, a instalação do Firefox. Instalação limpa, praticamente baseada em xcopy, sem problemas.

Então, por que as pessoas não estão usando configurações e aplicativos simples que não estão enraizados em mais de 30 camadas de interconexão? É porque os desenvolvedores são preguiçosos? Uso de ferramentas de codegen? É porque as empresas forçam aplicativos pesados ​​como algo que os usuários vão adorar? Qual é a causa e existe alguma esperança de que o software volte ao básico algum dia? Quais são as etapas para evitar escrever inchaço quando você inicia um novo aplicativo a partir do zero?

Meu palpite é que existem muitos recursos que alguém achou uma boa ideia. No entanto, se muitas pessoas têm idéias separadas que são reunidas em um aplicativo, é assim que isso pode se tornar tão complicado. Eu não culparia o desenvolvedor no caso de grandes produtos corporativos, onde deveria haver gerentes de produto responsáveis ​​pelo que está no produto e como otimizá-lo sob várias perspectivas.

Outro lado disso seria a dívida técnica que provavelmente não é bem gerenciada na maioria dos casos, pois não é vista como um grande investimento de tempo. Suspeito que novos recursos e correções de bugs façam mais sentido do que refatorações ou outras tarefas de dívida que possam parecer ter pouco valor comercial imediato. Com que frequência uma equipe de desenvolvedores levaria algumas semanas para limpar o código herdado se a base de código fosse bastante antiga? Meu palpite não seria frequente.

Para citar Joel na Carta de Estratégia IV: Bloatware e o Mito 80/20 :

[...] existem muitas ótimas razões para bloatware. Por um lado, se os programadores não precisarem se preocupar com o tamanho do seu código, poderão enviá-lo mais cedo. [...] Se o fornecedor do software parar antes do envio e passar dois meses pressionando o código para torná-lo 50% menor, o benefício líquido para você será imperceptível. [...] Mas a perda para você de esperar mais dois meses pela nova versão é perceptível, e a perda para a empresa de software que precisa desistir de dois meses de vendas é ainda pior.

Muitos desenvolvedores de software são seduzidos pela antiga regra "80/20". Ele parece fazer muito sentido: 80% das pessoas usam 20% dos recursos. Então você se convence de que precisa implementar apenas 20% dos recursos e ainda pode vender 80% do número de cópias.

Infelizmente, nunca são os mesmos 20%. Todo mundo usa um conjunto diferente de recursos. [...]

Quando você começar a comercializar o seu produto "lite", e você diz às pessoas: "Ei, é lite, única 1MB", eles tendem a ser muito feliz, então eles lhe perguntar se ele tem a sua característica essencial, e isso não acontecer, então eles não compram seu produto.

Grande parte disso está relacionada às dependências de um produto. Seu sistema operacional é fornecido com muitas bibliotecas padrão para todos os tipos de coisas. No entanto, essas bibliotecas padrão têm versões diferentes ao longo da evolução do sistema operacional e qualquer instalador genérico não pode assumir que a versão específica em que foi criada estará realmente presente no sistema operacional.

Portanto, o instalador completo precisará incluir a versão correta de todas as dependências para garantir que tudo funcione definitivamente após a instalação, independentemente do estado inicial de cada dependência no computador de destino. Isso pode ser um inchaço bastante significativo para certos tipos de aplicativos, por exemplo, aplicativos baseados em .NET que precisam ser implantados em sistemas Windows XP.

Até recentemente, um sistema instalador com o qual trabalhei precisava que todas as versões anteriores do .NET fossem instaladas para poder implantar a versão mais recente, o que significava que qualquer aplicativo .NET 3.5 exigia binários de instalação para .NET 1, 2, 2.5 e 3 Em cima de 3.5. Nesse caso, apenas o instalador está inchado.

Uma solução alternativa é um instalador da Web, que baixa apenas os componentes que realmente não estão presentes no sistema de destino - e isso pode ser um benefício gigantesco de tamanho / inchaço. É claro que limita suas instalações a sistemas que possuem conectividade com a Internet.

Eu acho que muito disso tem a ver com camada após camada do código da biblioteca. Obviamente, quando você usa uma biblioteca, não usa tudo nela, de modo que o excesso aumenta à medida que você inclui mais e mais bibliotecas.

Combine isso com o fato de que o custo de uma hora de trabalho de um programador está ficando cada vez mais caro, enquanto o poder de processamento / armazenamento de um computador típico está ficando mais barato a cada ano, você vê que é realmente mais econômico dessa maneira.

• "Precisamos de algo para fazer o X. Vamos usar a biblioteca $ BIGFATLIBDESIGNEDFORSOMETHINGELSE, porque eu a usei em um projeto diferente"
• "Acho que não precisamos mais dessa parte do código, mas para garantir que nada quebre, apenas mantenha-a"
• Testes unitários insuficientes ou insuficientes, que levam a
• Sem refatoração
• Sem rastreamento, onde as configurações foram armazenadas ao longo dos anos, agora as configurações estão em toda parte
• ...

É um ciclo vicioso, em que todos os ciclos de desespero podem ser responsabilizados . Um ciclo de desespero consiste nas seguintes etapas:

1. Pessoas de negócios solicitam recursos inchados.
2. Os desenvolvedores implementam os recursos inchados, mesmo sabendo que não deveriam.
3. Os clientes pagam por recursos inchados, embora desejem apenas o produto, mas não o recurso estúpido.
4. Os empresários acreditam que os clientes desejam os recursos inchados.
5. Vá para o passo um e repita.

Como você para isso? Não há uma resposta fácil sobre como, mas é claro que, para interromper o ciclo, uma das etapas precisa ser quebrada. Assim, ele só pode ser quebrado por empresas, desenvolvedores ou consumidores que adotam uma ação revolucionária.

1. Um engenheiro tentou otimizar um módulo, mas apresentou vários problemas do cliente. Então, seu gerente disse que não. Então, o engenheiro decidiu não "criar problemas" até que os problemas o perturbassem.
2. Para um sistema complexo, o fornecedor já adicionou muitos patches e corrigiu milhares de bugs para torná-lo estável no ambiente do cliente. Não possui boa qualidade do ponto de vista do software, mas funciona. Ninguém quer reescrevê-lo para corrigir a mesma quantidade de erros novamente.
3. por motivos de compatibilidade com versões anteriores, mesmo que um recurso não seja popular no mercado, precisamos mantê-lo lá.

Sua invariavelmente preguiça, é isso que causa o inchaço. (ou a lama como no artigo seminal sobre esse assunto, a Grande Bola de Lama )

Por exemplo, onde trabalho, temos um aplicativo C ++ "legado" que, no entanto, é muito bem projetado. Os clientes conversam com uma API que fala com um servidor que trabalha com DB. Tudo sensatamente feito. Recentemente, precisávamos de um módulo adicional, mas, em vez de implementá-lo corretamente, o desenvolvedor decidiu implementá-lo no .NET e, pior ainda, ele decidiu que acessar dados via API era muito difícil (não é, mas ...) ele faria conexões de banco de dados diretamente. Então você vê como esse tipo de bagunça acontece. (e tudo com o acordo do AT que colocou "rápido" sobre "bom")

Também já vi esse tipo de coisa - em um local antigo, uma pequena parte da GUI era html, pois alguns desenvolvedores acharam uma boa idéia escrever os dados em html e fazer com que a GUI a exibisse. Então, uma pequena parte faz algo diferente do resto.

Em suma, a preguiça é ruim e a consistência é boa (independentemente da tecnologia usada). Prefiro ter um aplicativo totalmente MFC do que um que seja parte do MFC e parte do Winforms e parte do WebGL com muitas arquiteturas de back-end diferentes, unindo tudo.