A crise do software
(wryl.tech)- A expressão “software crisis”, surgida na NATO Software Engineering conference de 1968, passou a ser menos usada, mas o peso criado pela complexidade do software e pela abstração ainda permanece
- Em sua palestra do Turing Award de 1972, Edsger Dijkstra avaliou que, enquanto o desempenho e a complexidade do hardware cresceram rapidamente, os métodos organizacionais para lidar com isso não acompanharam
- A comercialização da computação pessoal e os ciclos rápidos de lançamento fizeram os usuários quererem mais capacidade antes mesmo de dominar suficientemente as ferramentas, e “abstract it away” se tornou a reação padrão
- Camadas de abstração aninhadas criam custos de desempenho e modelos mentais distorcidos, dificultando o acesso a funções básicas da máquina, como gráficos e som
- A solução não está em voltar às plataformas limitadas do passado, mas em reduzir as camadas de abstração e preservar as informações entre elas, devolvendo o protagonismo aos usuários das ferramentas
A preocupação de 1968 ainda não acabou
- O termo “software crisis” foi criado na primeira NATO Software Engineering conference, em 1968
- Essas conferências foram uma das primeiras tentativas de organizar e sistematizar as práticas de programação de máquinas de cálculo automático
- Em 16 de julho de 1969, a missão Apollo 11 foi lançada e, em outubro do mesmo ano, ocorreu a última NATO Software Engineering conference
- Em sua palestra do Turing Award de 1972, Edsger Dijkstra identificou a causa da crise nas máquinas que se tornaram poderosas e na ausência de métodos organizacionais capazes de dar conta delas
- Ele deixou uma observação no sentido de que “quando não havia máquinas, programar não era um problema; quando havia alguns computadores fracos, era um problema leve; e, quando surgiram computadores gigantescos, a programação também se tornou um problema gigantesco”
- Hoje, a expressão “software crisis” não aparece com frequência nas práticas de programação
- O avanço de novas linguagens e métodos organizacionais, somado à distância temporal em relação aos problemas do passado, deu ao setor certo alívio de que a questão teria sido resolvida em alguma medida
- Mas esse alívio permanece mais próximo de uma derrota e aceitação do que de um conforto verdadeiro
A abstração afasta o controle do usuário
- Os avanços da computação inicial e de áreas adjacentes ocorreram em máquinas e ambientes nos quais construir uma torre de abstrações tinha um custo direto
- Quando não era possível contornar as limitações, havia um ciclo de crescimento acompanhado por upgrades de hardware
- Na prática, passava-se a desejar maior capacidade antes mesmo de compreender plenamente as limitações existentes
- Depois da comercialização da computação pessoal, as empresas que vendiam equipamentos não esperavam até que os usuários dominassem completamente seus produtos, e o ciclo de crescimento continuou acelerando
- Com ciclos rápidos de lançamento de hardware, “abstract it away” se tornou a forma de pensar padrão
- Ao empurrar detalhes indesejados para dentro de uma estrutura controlável, ganha-se certa independência, mas há um custo de desempenho
- Múltiplas camadas de abstração e ocultação de informação deslocam o problema de construir software para níveis mais altos
- Essas camadas são integradas tanto ao software necessário para usar computadores quanto ao software que move a vida cotidiana
- A indústria de software mais ampla acelerou os ciclos de lançamento e a influência do capital, enquanto o espaço de fácil acesso para desenvolvedores individuais ficou mais fraco
- A crise do software não é um problema apenas dos desenvolvedores; ela também se estende aos usuários de software
- Fora das funções permitidas pelo autor, os usuários têm pouquíssimo controle
- Fica obscurecido o fato de que tanto criar quanto usar software são atividades humanas
O lugar para onde voltar não é o passado, mas camadas mais rasas
- A solução proposta não é voltar a plataformas mais restritivas
- É preciso limitar o número de camadas de abstração permitidas
- É necessário preservar informações entre as camadas
- Modelos de programação, interfaces de usuário e o hardware subjacente devem ser rasos e combináveis
- Movimentos como as comunidades Handmade, Permacomputing e retrocomputing contribuem para aumentar a consciência sobre a crise do software
1 comentários
Opiniões do Hacker News
Olá, sou o autor do texto. Acho importante esclarecer alguns pontos que costumam ser mal interpretados neste artigo. Não sou contra a abstração em si, mas contra aplicá-la sem limites
A solução também não é voltar a plataformas mais restritivas, nem dizer que o usuário deve “aguentar e se tornar mais técnico”. O ponto central para entender a crise do software é a curva entre “proficiência na plataforma” e “ciclos de crescimento/lançamento”. Ao longo dos últimos mais de 40 anos, salvo em algumas áreas, essas curvas se afastaram; não resolvemos o problema quando elas estavam próximas, mas o segundo melhor momento é agora
Também há reações dizendo que este texto é clickbait, mas é o primeiro post do meu log e reúne minhas reflexões sobre a situação em que me encontro como desenvolvedor. Sentimentos parecidos aparecem de várias formas em diversas comunidades, especialmente em algumas comunidades de base contracultural. Quero mostrar parte da solução do problema, então pretendo escrever um post de sequência do tipo “vou mostrar como fazer”. Como estou fazendo isso sozinho, peço tempo e paciência
Enquanto houver milhões de pessoas criando software, não dá para corrigir completamente esse problema. Inevitavelmente vou discordar de algumas delas, e nem todo mundo conseguirá se tornar tão habilidoso quanto o autor. Por isso, no fim, leio este texto como uma defesa de que o padrão do que conta como “abstração aceitável” deveria ser mais alto do que é hoje
É fácil falar em termos amplos, mas, ao examinar uma área específica que se considera “abstraída demais”, é bem provável que a pessoa fique mais humilde. Em geral, há motivos bastante bons até para essa “abstração excessiva”, e os engenheiros daquela área também acham que a situação das abstrações é bagunçada, mas a veem como necessária ou irrealista de corrigir
Por exemplo, muito software é construído colocando boas abstrações sobre abstrações intermediárias amplamente usadas. É o caso do Kubernetes rodando sobre Linux, runtimes de contêiner, e a estrutura tradicional de plano de controle/camada de configuração/plano de dados. Toda essa lógica poderia ser implementada diretamente em um novo sistema operacional, mas isso criaria problemas de compatibilidade para os usuários. Mesmo que fosse possível construir, talvez não houvesse usuários; e, nesse caso, seria preciso reimplementar as abstrações ruins que se tentava evitar. Além disso, uma solução assim é muito mais difícil de implementar. Eu detesto o design do Kubernetes e gostaria de resolver esse problema, mas vejo isso como algo em que fazer do “jeito certo” se torna tão difícil ou caro que deixa de valer a pena
Dependendo de quando e com que contexto alguém entrou nesta área, é bem provável que abstrações de gerações anteriores já tenham sido incorporadas como práticas aceitas. Por exemplo, em certo momento passou a ser uma premissa óbvia usar um sistema operacional com um sistema de arquivos de uso geral
Acho que o problema mencionado agora está mais próximo das dificuldades enfrentadas ao entrar na área hoje. Se presumirmos que é preciso entender em detalhe todas as abstrações usadas para poder contribuir, o conhecimento prévio exigido é considerável. Isso pode ser esmagador, mas também existe o caminho de aceitar as abstrações até que seja possível compreendê-las mais a fundo
0 - https://en.wikipedia.org/wiki/Clarke's_three_laws
Ainda assim, acho que o motivo de essa situação não mudar é claramente econômico. Não quero dizer que software ruim seja mais barato. Mas cortar cantos permite que um indivíduo ou uma organização economize custos agora, enquanto custos maiores acabam sendo assumidos depois pela própria organização, pelos clientes e pela sociedade como um todo; por isso há um forte incentivo a práticas baratas e ruins. Além disso, é difícil aplicar ao software os padrões de outras áreas da engenharia, o que também dificulta criar contratos ou regulamentações que exijam software de determinado padrão ou qualidade
A única solução imaginável seria uma revolução tecnológica que permitisse criar software melhor e mais barato com a mesma tecnologia e, ao mesmo tempo, impedisse criar software pior e mais barato
Há software demais em plataformas demais, e o terreno é fragmentado demais para fazer generalizações. Alguns projetos balançam e desmoronam, enquanto outros funcionam bem
Existe software hostil ao usuário, mas isso é intenção de design. Há cinismo e ganância por trás. Não é porque os programadores não sabem o que estão fazendo, mas porque fazem o que mandam
Os próprios usuários também incentivam isso. Mesmo que você crie um bom software para eles, não se interessam; os usuários pedem outras coisas que não um bom software. Um usuário que quer bom software acaba sendo vítima de cinquenta usuários que não querem. Software de mercado de massa agora é cultura de massa
O Word daquela época também não era tão inferior assim quando comparado à versão atual. Mas hoje Windows e Office precisam de 50 a 100 GB de disco apenas para funcionar. O que ganhamos para justificar um aumento de 1000 vezes?
É completamente insano, mas simplesmente deixamos passar. Sistemas modernos têm cerca de 5000 a 10000 vezes mais disco, RAM e CPU, e a internet doméstica é literalmente um milhão de vezes mais rápida que os modems iniciais
Este texto parte do pressuposto de que a crise do software existe de fato ou é um problema grave. Ele cita como elementos da crise estouro de orçamento, estouro de prazo, ineficiência, baixa qualidade, não atendimento de requisitos, projetos ingovernáveis, código difícil de manter, entregas não realizadas etc.
Mas, se tirarmos a palavra “software” daqui, quantas atividades humanas não passam por pelo menos um desses problemas? Por outro lado, também existe muito software realmente muito bom. Temos a tendência de olhar apenas para falhas e defeitos, e ignorar os sucessos como se fossem uma linha de base natural, mesmo quando eles continuam melhorando
Do momento em que você aperta o botão de ligar do computador até chegar ao desktop, já passa por centenas de abstrações. Só esse desktop já é o objeto mais complexo com o qual você vai interagir ao longo do dia. Isso acontece dezenas de bilhões de vezes por dia no mundo todo e, em geral, sem problemas. E esse é apenas um exemplo muito pequeno
Ainda assim, acho que a motivação real desse tipo de texto não está nesses itens, e sim na sensação de que tudo parece impossível de dar conta. Um programador experiente precisa equilibrar essa sensação de sobrecarga com o trabalho que precisa ser feito. Levei tempo para chegar a esse ponto, mas acredito que seja importante. As coisas nunca ficam totalmente organizadas, e é preciso aceitar isso
No software, quase não há esse tipo de limite além de restrições de desempenho e memória. Só que ambas são generosas o bastante para permitir empilhar lixo indefinidamente e seguir em frente. Todos nós já tivemos um momento em que pensamos ou dissemos: “como é que isso ainda funciona?”. Até que o usuário pise numa condição de contorno errada, não dá para saber quão precário é o código por baixo
“Você já tentou desligar e ligar de novo?” é a prova disso. Sistemas de software frequentemente entram em estados ruins tão sutis e desconhecidos que a única solução é apagar tudo e subir de novo do zero. Como quando o celular continua vibrando depois de uma ligação até chegar a próxima chamada ou mensagem, ou quando parte de uma aplicação web não carrega 100% e uma opção desaparece, ou quando o pareamento Bluetooth é inconsistente
A comunicação é a forma de propagar entendimento e corrigir sua falta, e o entendimento é a base do sucesso em qualquer atividade. Sem entendimento, um ou mais dos sintomas acima aparecem. Mesmo com entendimento eles ainda podem aparecer, mas pelo menos passa a existir um caminho para o sucesso
Pela minha experiência, a maior parte dos problemas da indústria de engenharia de software são problemas de pessoas. Não são a tecnologia, nem a tecnologia em si, nem os processos. Por isso comunicação e entendimento são essenciais para o sucesso
Ao olhar para o histórico das lideranças de empresas de engenharia ou montadoras, vê-se uma progressão em que elas assumem responsabilidades cada vez maiores em projeto de peças, componentes e produtos, ou na operação de instalações de produção. CEOs ainda enfatizam conhecimento técnico, e até pessoas não técnicas pelo menos fingem isso
Em contraste, no desenvolvimento ágil de software, a competência técnica em geral termina no nível mais baixo. Em uma equipe Scrum há pessoas que fazem software, e só. É muito provável que muitos Scrum Masters e analistas de negócios nunca tenham programado muito, e o primeiro chefe de fato na hierarquia quase não olha código, pois seu trabalho é em grande parte de secretaria e gestão
O ponto não é apenas que o desenvolvimento de software acontece em unidades do tamanho de tickets, dificultando refletir filosoficamente sobre quantas camadas de abstração você cria e mantém. Desenvolvedores de software nem sequer têm assento à mesa de decisão. São cuidados pelo Scrum Master, fazem concessões em code reviews, sofrem pressão para não pensar fora dos tickets, e geralmente não há um caminho de promoção que leve a competência técnica para a liderança
Por isso, o movimento para alertar sobre a “crise do software” parece ter grande chance de permanecer, como diz a expressão no fim do texto, em áreas de hobby como Handmade, Permacomputing e computação retrô. Acho que Hollywood também tem parte da culpa, ao retratar pessoas de software/TI de forma incessantemente humilhante, enquanto dá infinitos papéis principais a médicos e advogados e transforma jargão profissional complexo em histórias interessantes. Será que do nosso lado isso é mesmo impossível? Talvez em breve uma IA de roteirização consiga fazer algo
Desenvolvimento de software é passar o dia inteiro conversando de forma rigorosa com um computador. Envolve resolver em uma nova aplicação coisas comuns que já foram resolvidas, ou lidar com problemas que são difíceis até de entender sem formação técnica. Sou desenvolvedor e programo por diversão há mais de 20 anos, mas a maior parte do trabalho é entediante a ponto de enlouquecer. Nem tento explicar a não desenvolvedores. É tão pouco divertido quanto contabilidade, e muita gente provavelmente obteria informações mais úteis em outra história
A empresa mais profundamente mergulhada em Agile em que trabalhei tratava juniores e seniores como engrenagens intercambiáveis. A única diferença era que seniores precisavam entregar mais pontos por sprint. Havia uma repressão ativa a pensar fora do escopo dos tickets, e o clima era de abaixar a cabeça e ficar calado
Mas há dois problemas. Eles não conseguem se aprofundar nos detalhes de implementação e também estão presos a incentivos distorcidos que recompensam a criação de complexidade. Claro que há pessoas que se opõem a isso, mas essas pessoas têm pouca probabilidade de ser promovidas. Ninguém é recompensado por reduzir o número de pessoas abaixo de si ou por eliminar a própria função
A explicação curta para desenvolvedores lidarem apenas com unidades do tamanho de tickets dentro dos requisitos reais é que eles são burros demais. Não conseguem manter o todo na cabeça e não entendem. Isso soa frustrante? Sim. É realmente difícil de entender. Desculpe
Este texto retrata a abstração como algo maligno, mas ela é uma ferramenta inevitável para criar software feito por humanos acima de certo nível de capacidade
Rich Hickey já disse algo no sentido de que “um malabarista iniciante consegue lidar com duas ou três bolas, mas até o melhor malabarista do mundo provavelmente chega ao limite por volta de nove. A capacidade humana não varia por ordens de grandeza e logo bate no teto”. Para superar esse limite, não há alternativa a não ser abstrair
É claro que, em casos específicos, pode haver abstrações ruins ou abstrações demais, e acho que é disso que o autor está irritado. Mas essa distinção é importante
A parte que diz que “agora não é fácil criar software, e nada vem com manual” está claramente errada. Criar software ficou mais fácil do que nunca, e a documentação também está melhor
Não é indispensável haver indireção para entender um todo complexo. Para lidar com a complexidade, é preciso desemaranhar o que está entrelaçado para que cada parte possa ser entendida de forma independente. Quando escondemos a complexidade por meio de indireção, criamos distância entre nós e aquilo sobre o qual precisamos raciocinar
Abstração é boa para o usuário. Seja ele desenvolvedor ou não, não precisa se preocupar com os detalhes. Mas ela não torna mais fácil o nosso trabalho de construí-la
Ao contrário da ideia de que “agora é difícil criar software”, é muito fácil quando você conhece a ferramenta certa para a tarefa certa. Só que as informações sobre essas ferramentas são reprimidas, então quase não ouvimos falar delas
O ecossistema de ferramentas tecnológicas que a maioria imagina é muito diferente da realidade. A maior parte das ferramentas que conhecemos é horrível. Elas tentam parecer soluções universais, mas na prática não são muito boas para nada. Mesmo assim, são as ferramentas mais populares. Como o texto sugere, acredito que isso se deva à influência do capital
Por exemplo, com a ferramenta que uso hoje, gravei um vídeo criando do zero, em 3 horas, um app de marketplace relativamente complexo, com login, controle de acesso, validação de esquema e visualizações com filtros complexos, apenas no navegador, sem baixar nenhum software, de forma serverless. O app inteiro tem menos de 700 linhas de marcação HTML e 12 linhas de JavaScript. Teve cerca de 10 visualizações
Ao contrário do twist conspiratório, as ferramentas modernas são mais flexíveis e fáceis de usar do que nunca. Elas têm defeitos, mas não são nada comparadas ao que desenvolvedores precisavam enfrentar décadas atrás. Não existe uma grande conspiração para encobrir a sua ferramenta
Eu acredito muito em no-code/low-code e em ferramentas que possam rodar em qualquer lugar. Só que o que quero dizer com isso talvez seja diferente do que você está pensando. De todo modo, reconheço o mérito de ter criado algo
Ao começar a assistir ao vídeo, as primeiras perguntas que me vieram foram estas: o que é Codespaces? Como fica a segurança? Onde o app final roda? Posso rodá-lo no meu próprio hardware? Posso rodá-lo sem acesso à nuvem? Qual nuvem? Ele ainda existirá na semana que vem, no mês que vem, no ano que vem, daqui a 10 anos? Claro, não se preocupe demais com um único exemplo
A situação de no-code/low-code pode ser comparada à editoração eletrônica. DTP não tem pipeline de CI/CD. Você aperta imprimir. É um ambiente totalmente integrado. Em contraste, literalmente todo ambiente de “integração contínua” parece estar gritando tão desesperadamente que acaba se devorando. Em algum lugar deve haver ferramentas para separação de cores, configuração de margens, importação de fontes, bibliotecas de cabeçalhos PostScript ou geração de LaTeX, mas a maioria das pessoas nem as vê nem as usa. Em algum lugar também deve haver gente fazendo impressão em múltiplas chapas, nítida apenas sob luz natural, com uma variedade de pigmentos muito maior que CMYK; mas, como a maioria só vê snapshots ruins no celular, não vê sentido nisso
Isso não é um problema apenas dos criadores. Os consumidores não sabem o que é possível e tampouco têm dispositivos capazes de revelar todo o leque de possibilidades. Dispositivos de consumo degradam ativamente esse leque por inúmeros motivos de ecossistemas fechados e por descuido e ignorância comuns
Alguns anos atrás recebi um Cadillac como carro alugado, e nunca compraria um Cadillac moderno; se possível, também evitaria dirigi-lo. Eu não conseguia controlar os limpadores de para-brisa, e a tela do console exibiu várias vezes o aviso mais chamativo dizendo que eu não estava olhando para a estrada. Provavelmente não conseguiu perceber que eu usava óculos. Como eu estava em tráfego rápido numa estrada desconhecida, de fato não olhei para a tela e perguntei ao passageiro: “o que diabos essa tela piscando está dizendo?”. Muito bem, Cadillac
Estruturas rasas e combináveis são algo que todo mundo vivencia ao usar ferramentas UNIX
É aqui que a GUI desmorona. GUIs são literalmente ilhas que não se comunicam entre si de uma forma combinável
Estou fazendo um experimento que mistura GUI com a ideia de pipelines de shell em uma ferramenta chamada guish
https://github.com/williamcotton/guish
Fico curioso para saber se alguém conhece ferramentas parecidas ou abordagens de GUI combinável
https://hisham.hm/userland/
https://arcan-fe.com/2021/04/12/introducing-pipeworld/
http://conal.net/papers/Eros/
Também estou trabalhando em ideias relacionadas a isso, e por fora elas até parecem semelhantes às suas. Mas recomendo observar como isso funciona no emacs. Não examinei a fundo, mas sua abordagem não parece muito “combinável”
Caso não conheça, isto também pode servir de inspiração: https://gtoolkit.com/ É um ambiente Smalltalk em que, como no emacs, literalmente tudo é programável, mas quase na direção oposta. A GUI não é o resultado de comandos; ela é a própria linguagem
Mas o problema maior não é a GUI. A GUI também é um problema, mas, como inevitavelmente fica no topo da pilha de abstrações, o problema não se combina e se propaga tanto. Curiosamente, por ser um problema grande demais, acaba deixando de ser um problema
O elefante enorme de hoje são os sistemas distribuídos
Mas GUI é um ponto fraco há muito tempo. Acho que é porque há muitas considerações “globais” sobre uma UI ser boa ou não, então isso não é uma propriedade modular
Pessoalmente, eu gostaria de ter mais UI, mas mantendo a automação. Aquela propriedade de poder salvar em um arquivo o que digitei no shell para executar de novo depois, modificar e executar novamente, copiar um comando e enviar por e-mail para um amigo
Para dar contexto, há anos venho criando um shell do zero, e ele tem um headless mode para GUI. Também há demos reais feitas por outras pessoas, mas no momento ninguém está trabalhando nisso
Capturas de tela:
https://www.oilshell.org/blog/2023/12/screencasts.html#headl...
https://www.oilshell.org/blog/tags.html?tag=headless#headles...
Há mais links aqui - https://github.com/oilshell/oil/wiki/Interactive-Shell - incluindo projetos interessantes, mas inativos, como o Xiki
Se você precisar de um shell compatível separado do terminal, ou de um novo shell desse tipo, avise por e-mail ou em https://oilshell.zulipchat.com
Basicamente, precisamos de pessoas que testem o protocolo headless e apontem melhorias. Acho que deveríamos criar uma GUI de shell que “tenha” um terminal, mas que não “seja” o terminal em si. Isso também parece relacionado ao que você está construindo
No momento estou trabalhando principalmente na nova linguagem YSH, mas gostaria de reativar o trabalho de GUI também. Não tenho muita experiência como programador de UI, então seria bom ter outras perspectivas
E fico feliz que você tenha incluído ggplot, porque gosto dele. Na verdade, o ggplot é justamente um ponto em que eu sinto falta de ter gráficos no shell
A frase final, “pode ser melhor. vou mostrar como”, simplesmente parece uma abertura caça-cliques
A afirmação de que “é muito raro esses modelos refletirem a realidade. Quando refletem, é uma feliz coincidência; quando não, é um desastre” não corresponde à minha experiência
Em geral, a maior parte do software disponível no mercado não é crítica. Muitas aplicações web inchadas e malfeitas podem sugar recursos demais o dia inteiro, apresentar bugs irregulares aqui e ali e ainda assim executar pessimamente aquilo que o usuário esperava. Tudo isso é verdade
Mas elas não são tão críticas quanto softwares que lidam com marca-passos ou foguetes espaciais. A maior parte do software pode ser uma bagunça. Isso porque a maioria dos projetos está ligada aos caprichos humanos, e o pior da falta de qualidade é alguma frustração, não uma catástrofe ou morte
Além disso, a maioria dos desenvolvedores de software provavelmente não trabalha sob incentivos financeiros ao estilo do Silicon Valley, nem ganha a vida com projetos que gostaria de criar por paixão. A maior parte do software que chega ao mercado é produzida por meio de estruturas externas de recompensa ruins. O que se espera que seja o produto desse processo, além de lixo?
Eu realmente odeio degraus faltando
Estamos muito distantes do uso real do software que criamos e só vivenciamos sinais executáveis, breves e de formato curto, que orientam o processo de desenvolvimento. A menos que possamos trocar de corpo com um novo usuário, é difícil sentir de fato a dor real dessa “morte por mil cortes”
Vejo programação como uma profissão, e acho que temos poder para governar a qualidade do software. Só existem incentivos, financeiros ou não, que nos levam a desviar o olhar
Não acho que exista uma crise de software. Milhões de programadores no mundo todo criam programas úteis em alguma medida, e quase tudo, até torradeiras, executa software com sucesso suficiente. A comunidade também criou programas acessíveis a todos, de crianças de 5 anos a avós. Onde está a crise nisso?
Mas existe uma crise de gerenciamento de projetos. Ela não se limita ao software; é um problema de distanciamento entre quem planeja e quem entrega. E parece que não conseguimos preencher essa lacuna. Agile, Scrum etc. são indicadores dessa lacuna, em que “gurus” tratam todos nós como idiotas, e nós também não estamos conseguindo criar algo melhor
A comoditização do desenvolvimento de software também contribui para essa confusão. Pela natureza de um campo com baixa barreira de entrada, pessoas de todos os níveis podem participar, com taxas variadas de sucesso. Não é uma questão de bom ou ruim; é a natureza do fenômeno. Não é muito diferente de o setor de alimentação ter tanto restaurantes com estrela Michelin quanto McDonalds, ambos com seus consumidores. Nem por isso chamamos de crise dos restaurantes
Isso reduz a vida útil da torradeira. Antigamente talvez houvesse torradeiras que duravam 10 anos. Agora, por causa de software ruim e talvez de uma conexão WiFi ou Bluetooth forçada, elas viram lixo depois de 2 anos quando o fornecedor interrompe as atualizações. Talvez nunca tenha havido atualizações. A crise nem sempre fica visível, seja porque não a enxergamos diretamente, seja por causa do consumismo atual e da compra interminável de produtos novos
Se a torradeira para depois de 2 anos, achamos que está tudo bem, e talvez não nos importemos com o motivo ou nem saibamos. Mas ela pode ter feito parte da botnet Mirai https://www.cloudflare.com/learning/ddos/glossary/mirai-botn...
Como torradeiras usam chips mais simples, provavelmente não, mas quem sabe?
Para constar, minha torradeira Dualit não executa software
O trecho “desenvolvemos formas de empilhar camadas aninhadas de abstração e esconder informações em vários níveis. Transformamos o problema de construir software em camadas imponentes” me lembra abstrações vazadas e a Torre de Babel
https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a...
https://en.wikipedia.org/wiki/Tower_of_Babel
https://en.wikipedia.org/wiki/Hierarchy
https://en.wikipedia.org/wiki/Abstraction
https://en.wikipedia.org/wiki/Abstraction_(computer_science)
Vale compará-los entre si