Ano passado eu li o livro Getting Real, da 37signals (www.37signals.com), que quase todo mundo que trabalha com tecnologia também leu (ou deveria ler). Tive um tempo para relê-lo e para digerir algumas idéias, até que surgiu uma oportunidade de colocá-las em prática. Aqui vão algumas conclusões que cheguei lendo o Getting Real e outras fontes, além de algumas idéias minhas mesmo.
Você já reparou que, quando chove muito, é difícil ver um fusquinha parado com defeito? Já notou que aqueles telefones “pé-duros” da Nokia, aqueles reservados à classe C e D, não travam nem têm bugs? Por que? Porque são simples e robustos.
Se não estiver satisfeito, analise os equipamentos disponíveis em uma moto Harley Davidson. Sabe o que o painel tem? Apenas o velocímetro e o hodômetro! É, e é uma Harley Davidson. A marca que conseguiu, sem pedir a ninguém, que os clientes tatuassem em si mesmos seu símbolo. É simples e robusta; e com estilo.
Pois é, estamos vivendo numa fase de retorno à simplicidade. As pessoas não têm tempo a perder para aprender muita coisa complicada. O que deve ser aprendido tem que ser útil e aprendido rapidamente. Com toda a tecnologia disponível, muita gente tem optado pelo simples, porém seguro.
Duvida? Então vejamos alguns exemplos em tecnologia:
a) Você não acha o design da web 2.0 bem menos rebuscado do que o que víamos até então? Hoje é tudo mais direto do que antes.
b) Você já ouviu falar de micro-blog? Quer troço mais resumido do que isso?
c) E que tal um torpedo? É a simplicidade em pessoa!
d) E-mail, então, nem se fala.
e) Por que a linguagem dos instant messengers tem influenciado tanto nosso cotidiano?
Por esses exemplos aí, você já nota que simplicidade não é sinônimo de falta de tecnologia. Pelo contrário. A simplicidade está nas escolhas que você faz durante o desenvolvimento do projeto.
E as vantagens do que é simples são óbvias. O que é mais simples é aprendido em menos tempo por ser mais fácil de entender. Por ser mais simples dá menos problema e é mais controlável e previsível.
Sim, previsível. Ser previsível, em tecnologia, é um ponto a favor. Quem usa quer ver um resultado. A pessoa tem uma expectativa que precisa ser atendida. Isso é previsibilidade. O cliente até paga por isso, sabia?
Se você leu esse artigo até aqui, deve estar pensando a quê eu quero me referir. A resposta é: a APLICATIVOS. Sim, aplicativos.
Sabe aquele conceito do “menos é mais”? Nessa área faz o maior sentido. E pode aumentar o tempo de vida de seus aplicativos.
Se você duvida ou discorda, vamos analisar isso de forma mais profunda, então.
Seja Enxuto
Ser enxuto quer dizer que “se não muda seu comportamento, então não é essencial.” (Getting Real).
Ser enxuto e pequeno é o grande diferencial.
Qualquer coisa (informação, funcionalidade, decoração) que não for essencial para atingir os objetivos do projeto não deve fazer parte dele. Duro, não?!
Aplicando o Princípio de Pareto, podemos dizer que 80% dos benefícios de um aplicativo são conseguidos com 20% das funcionalidades. Portanto, podemos perseguir o objetivo de eliminar aquelas funcionalidades que raramente são utilizadas. Aqueles 80% de “florzinha”, como dizemos no jargão de desenvolvedores. Tá certo, pode até ser exagerado, mas tente medir isso no próximo aplicativo que você for desenvolver. Você vai ficar assustado. Eu fiquei.
Ser enxuto significa encontrar o equilíbrio entre o que é legal (interessante, bom, bonito, última moda) e o que é necessário (fundamental, primordial, voltado para o negócio).
Esse objetivo de reduzir funcionalidades retira complexidade potencial. Como conseqüência, retira também erros potenciais.
Quanto às funcionalidades, podemos dizer que “+1 será sempre +1”. Essa idéia diz que mais uma funcionalidade será sempre mais uma possibilidade de erro. Ela sempre estará lá, por menos utilizada que seja. Você já viu algum cliente autorizar a retirada de uma funcionalidade do aplicativo? Eu, nunca! Uma funcionalidade presente em um software, dificilmente sai dele.
Um bom exemplo disso são aqueles relatórios que ninguém usa. Eu sei que você já teve que fazer um desses algum dia.
Mantenha-o Estupidamente Simples
Esse é o princípio KISS (Keep It Stupidly Simple) ou, em português, Mantenha-o Estupidamente Simples.
Seu aplicativo tem que ir direto ao ponto, sem rodeios. O ideal é que seu aplicativo não precise de um manual para ser utilizado. Ele deveria funcionar como um utensílio ou ferramenta. Quando você pega uma máquina de pressão para lavar a varanda, fica preocupado com a máquina? Não. Você vê sua varanda sendo limpa. Do mesmo modo, quando vai dirigir seu carro, você fica prestando atenção no carro, ou no trajeto? No trajeto, é claro.
Note que os exemplos acima não são de coisas estúpidas, mas sim de coisas simples de usar. Ser simples de utilizar para trazer simplicidade a quem utiliza.
Dói dizer isso, mas seus usuários têm que prestar atenção nas atividades que eles querem realizar, e não no seu aplicativo. Este, precisa passar despercebido para que o usuário preocupe-se apenas em resolver o problema dele.
Duvida? Então tente explicar por outro motivo, o desejo dos usuários por versões antigas (e mais simples) de aplicativos como o Winamp, Nero, Windows Media Player, MSN Messenger, etc.
Só que ser simples não significa ser medíocre. O aplicativo precisa resolver aquilo a que ele se propõe. Igualzinho a um canivete suíço: faz um monte de coisas, mas de forma simples.
Pensar de forma simples não significa que você deva pensar pequeno. De forma alguma. Um canivete suíço é simples, mas resolve um monte de problemas. E faz sucesso desde 1891! Por falar em canivete suíço, leia a filosofia por trás dos canivetes da Victorinox no site deles em inglês (www.victorinox.com/index.cfm?site=victorinox.ch&page=76〈=E).
Qualquer complexidade maior deve ser respondida com um NÃO. Se ela for realmente necessária, vai falar mais alto do que o seu “não”.
Menos código
“Se os programadores fossem pagos para retirar códigos ao invés de criá-los, os softwares seriam bem melhores.” (Nicholas Negroponte)
Eu sou desenvolvedor e fiquei chocado quando li essa afirmação. Mas, pensando bem, até faz sentido. Sabe por quê? Porque menos código geralmente é:
a) mais veloz;
b) mais simples;
c) mais fácil de mudar (sim, as mudanças virão!);
d) mais seguro.
Menos código normalmente traz:
a) menos bugs;
b) menos risco de efeitos colaterais nas mudanças;
c) menos itens para integrar.
Não fique inventando coisas mirabolantes. Use somente o necessário e as facilidades da linguagem que você está usando. Isso vale para qualquer código: html, css, php, java, cobol, etc.
Faça as escolhas técnicas que privilegiem menos código escrito. Uma das máximas que aprendi com a linguagem Python é que deveria existir apenas uma maneira de resolver um problema. E essa tem que ser a mais simples das soluções. Soluções mais simples normalmente são conseguidas com menos código.
Conclusão
Lembra do fusquinha que é difícil dar defeito na chuva, enquanto um monte de carrão fica parado no acostamento? Pois é. Do mesmo modo, seu aplicativo simples e eficiente vai rodar que é uma beleza. Sem enrolação, sem embromação, sem xurumelas. Como diria o Chico Anísio: “não deforma, não tem cheiro e não solta as tiras”.
Que tal tentar e nos contar o resultado postando um comentário?
Nas Seções: Carreira , Desenvolvimento , Design , Tecnologia , Web etc
Cartão Vermelho: |
Sobre o Autor: Vinicius Assef é desenvolvedor há 21 anos, tradutor técnico, palestrante, voluntário em uns projetos, gosta muito de padrões web, tenta praticar agile, tem uma família linda e acredita em Deus. Motivado por sua esposa, resolveu escrever artigos para compartilhar opiniões e aprender com os comentários feitos pelos leitores.
