- O papel essencial do software é saber com clareza qual problema deve resolver e reconhecer seus limites
- Um bom software não tenta incluir todos os recursos; ele lida apenas com o que precisa ser melhorado e não se desvia de seu propósito
- Apresenta um caso hipotético em que o comando
ls é substituído por recursos de IA e satiriza o fenômeno de expansão desnecessária de ferramentas existentes
- Citando os princípios apresentados em ‘Getting Real’ e ‘Rework’ da 37Signals, enfatiza que é preciso transformar restrições em vantagem e recusar solicitações de recursos desnecessários
- Mesmo em meio à febre da IA, relembra que a estabilidade dos padrões existentes e uma definição clara do problema têm mais valor do que novas modas
O papel e os limites do software
- O texto começa com uma cena imaginária em que, após atualizar uma distribuição Linux, o comando
ls é transformado em uma inteligência de diretórios baseada em IA
- O novo comando
als prevê a intenção do usuário, ranqueia arquivos e exibe uma mensagem informando que o ls tradicional deixará de ser suportado em 30 dias
- Essa cena é um exemplo satírico de excesso de funcionalidades e inovação desnecessária
- Afirmando que “felizmente isso não acontece de verdade”, o texto destaca que um bom software sabe quando deve parar
Princípios centrais de um bom software
- Um bom software sabe qual propósito cumpre, não tenta fazer tudo e distingue quando deve parar do que realmente precisa melhorar
- A ‘mentalidade maximalista’ humana tende a querer tornar tudo maior e mais complexo
- Porém, o software precisa definir com clareza seu papel e seu lugar e, se uma nova ideia não combina com a visão existente, ela deve ser separada em um projeto distinto
A filosofia de produto da 37Signals
- ‘Rework’ e ‘Getting Real’, escritos pelos fundadores da Basecamp, oferecem lições importantes para o design de produtos
- Restrições são vantagens (Constraints are advantages): equipes pequenas, orçamento limitado e escopo restrito conduzem a decisões melhores
- Ignore solicitações de recursos (Ignore feature requests): em vez de implementar exatamente o que o usuário pediu, é necessário entender o problema de fundo
- Lance cedo e lance com frequência (Ship early, ship often): um produto imperfeito, mas que realmente funciona tem mais valor do que um produto perfeito que nunca é lançado
- Design a partir do epicentro (Epicenter design): em vez de começar pela navegação ou por elementos periféricos, deve-se projetar primeiro a interface central e a interação principal
- Diga ‘não’ por padrão (Say no by default): novos recursos trazem custos ocultos de complexidade, manutenção e aumento no tratamento de exceções
- Crie o que você mesmo precisa (Scratch your own itch): produtos que resolvem problemas que você realmente precisa resolver permitem decisões melhores
O valor da continuidade acima da mudança
- Recentemente, vários produtos vêm seguindo uma tendência de reorganizar seus nomes e funções em torno da IA
- MinIO → AIStor
- Oracle Database → Oracle AI Database
- Nem tudo precisa mudar de forma dramática
- Tornar-se um padrão de fato (de facto standard) em um domínio específico de problemas tem um valor ainda maior
1 comentários
Comentários do Hacker News
Ao ver o conselho de “ignorar pedidos de recursos”, lembrei do caso da Blizzard e World of Warcraft Classic
Durante anos, os usuários pediram uma versão clássica, mas a Blizzard recusava dizendo “vocês não vão querer isso”
No fim, lançou o WoW Classic e teve um sucesso avassalador
Depois, a equipe de desenvolvimento admitiu que “os usuários realmente sabiam o que queriam”
Ou seja, em vez de sempre ignorar pedidos de recursos, às vezes é preciso reconhecer que o usuário pode estar exatamente certo
Já um usuário rude ou egocêntrico torna a conversa cansativa, e aí você acaba nem querendo responder
No fim, a lição é que, ao pedir algo, é preciso ser educado
Depois disso, é preciso avaliar se é um pedido válido e pensar em como implementar
O problema fundamental era um “jogo que perdeu a sensação original”, e, se isso tivesse sido compreendido, talvez desse para resolver de outra forma que não fosse com o clássico
O WoW Classic era a expressão de um desejo superficial de recuperar a nostalgia do passado, mas por baixo disso havia desconfiança em relação a uma direção de desenvolvimento considerada pouco confiável
Num mundo ideal, talvez fosse possível criar uma forma perfeita misturando as vantagens das duas versões, mas, na realidade, os conflitos de opinião só aumentariam a confusão
Ao adicionar instâncias sem PVP por pedido dos usuários, a tensão desapareceu e o jogo ficou sem graça
Nesse caso, os desenvolvedores sabiam mais do que os usuários
Acho que deveria haver mais softwares completos que pararam de adicionar recursos
É preciso ter coragem para dizer: “isso já é suficiente”
Há muitos casos, como Evernote e Dropbox, que depois de um período em que eram perfeitos ficaram confusos por excesso de recursos
Eram vendidos em caixa, e quando saía uma nova versão você comprava outra caixa
Era a época anterior aos webapps com atualização constante de hoje
Na verdade, em muitos casos, quanto mais atualiza, pior fica
Os produtos que realmente melhoram são raríssimos
No fim, recriou o mesmo problema que originalmente tentava resolver
Mas, com o passar do tempo, ele deixou de ser compatível com versões do iOS e acabou se tornando inutilizável
Foi possível sentir ao mesmo tempo a beleza de algo completo e a crueldade da evolução tecnológica
Quando fiz a transição de infraestrutura para desenvolvedor Java em 2020, vi que as principais bibliotecas estavam em modo de manutenção e pensei: “Java morreu?”
Mas depois percebi que aquilo era um estado de maturidade funcional
Era uma condição estável, com inúmeros casos de borda já resolvidos
O problema é que as pessoas não querem esse tipo de estabilidade e sempre querem algo novo
No fim, continuam recriando o mesmo framework, só trocando a linguagem
Por isso prefere projetos que ainda estão em desenvolvimento
Além disso, algumas empresas só podem usar softwares que continuam recebendo atualizações por causa de requisitos de compliance
Brinquei dizendo “ela só está pronta, não há mais o que melhorar”, mas acabei trocando mesmo assim
Gosto do Sublime Text por causa da simplicidade e da velocidade
Ele não enfia IA nem recursos complexos, e se concentra em um único propósito
Software bom não é necessariamente software que dá dinheiro
Mas, para dar dinheiro, ele precisa ter recursos que as pessoas realmente usam
Como cada usuário usa 20% de recursos diferentes, é preciso levar essa diversidade em conta
Eu achava que o Notepad.exe era um exemplo representativo de software completo,
mas fiquei surpreso ao ver que, no Windows 11, é preciso fazer uma manipulação quase de nível hack para mudar a associação de arquivos
Pelo blog do Windows Insider e pelo aviso de segurança,
o problema seriam justamente as atualizações que nunca sabem parar
Reconheço a beleza de um software completo, mas hoje em dia a maioria vive em estado de “beta eterno”
Com a internet como pressuposto, surgiu uma estrutura em que “dá para atualizar a qualquer momento”,
e correções de bugs e adição de recursos indesejados não ficam separadas
Em serviços web como o YouTube, nem sequer é possível escolher a versão
Especialmente com a adição do recurso Canvas, a filosofia simples original começou a balançar
Se fosse open source, talvez eu tivesse feito um fork naquele momento
O Signal é gratuito, open source e focado em privacidade, então tem poucos recursos
Mas isso justamente me agrada
O WhatsApp só continua acumulando recursos inúteis
Antes eu não entendia a importância do conceito de “evergreen”, aquilo que é sempre necessário, no livro da 37signals, especialmente a velocidade
Mas, com o tempo, ao ver os apps ficando cada vez mais lentos, percebi o quanto o valor de um software rápido é enorme
Lembrei da frase “escritores gostam de residência” em REAMDE, de Neal Stephenson
Assim como escritores continuam criando trabalho para manter uma residência, desenvolvedores também têm a tendência de mudar código para criar trabalho
No fim, nós também seguimos repetindo mudança pela mudança