É preciso muito código para produzir software.
E os bugs são inevitáveis porque os desenvolvedores são humanos, e porque é isso que acontece com um sistema cujas muitas, muitas partes móveis estão mudando constantemente com uma consciência incompleta umas das outras e das dependências entre elas. Para testar com eficácia, é necessário replicar o maior número possível de condições sob as quais o produto pode ser executado. E para corrigir um bug, um desenvolvedor precisa reproduzi-lo, fazer acontecer novamente para que ela possa ver o que realmente está acontecendo.
Assim, as equipes de software gastam uma grande porcentagem de seu tempo encontrando e corrigindo bugs. Quanto mais variação, mais testes e mais difícil se torna replicar um bug quando ele é encontrado. É por isso que a fragmentação do Android, a variedade de versões e dispositivos do Android que um aplicativo deve suportar, é um problema tão grande.
Não podemos controlar a fragmentação, mas podemos evitar exacerbá-la. Quando introduzimos escolha excessiva, aumentamos o número de ambientes possíveis em que algo pode quebrar e o número de condições que temos que testar. Esse aumento não é aditivo, é multiplicativo: o número de condições a jusante de uma escolha é multiplicado pelo número de opções que ela oferece.
Por si só, isso não é uma desculpa para eliminar escolhas. Mas é o custo técnico que essas escolhas incorrem – algo que ignoramos por conta e risco de nosso produto. É também por isso que escolhas aparentemente inofensivas não são tão inofensivas; por que “vamos apenas marcar uma caixa de seleção nas preferências avançadas ” não é uma resposta.
Precisamos de tempo para testar e depurar. E quando o fazemos, algo mais tem que dar. O problema da escolha não se limita ao Android.
O Android é apenas um exemplo atual, proeminente e grave. Produtos simples, elegantes, utilizáveis e opinativos são poucos e distantes entre si porque as equipes de produto dispostas a fazer escolhas difíceis são raras. Então, o que você deixou de fora do seu produto ultimamente?
Epílogo: Lidando com o feedback do usuário
Com o Emu na versão beta, recebemos muitos comentários. Adoramos feedback, é maravilhoso que as pessoas se importem o suficiente com nosso produto para nos enviar um e-mail. Mas nós não implementamos todas as solicitações, dessa forma, fica exatamente o tipo de inchaço que discuti aqui.
Para começar, os usuários mais barulhentos não são necessariamente os mais típicos; alguém pode solicitar um recurso que realmente melhore sua experiência, às custas da maioria dos outros usuários. Mais importante, o feedback do usuário requer investigação. Os usuários muitas vezes não sabem, ou não conseguem articular, o que eles realmente querem.
Então, olhamos para cada pedido e perguntamos: O que essa pessoa está realmente tentando realizar? Como podemos servir melhor a esse objetivo? Às vezes, o resultado será mais eficaz, e mais adequado à necessidade subjacente, do que o que o usuário solicitou em primeiro lugar. E esse tipo de inovação é incrivelmente satisfatório.