Há mais ou menos um mês terminei de ler o livro Presentation Zen do Garr Reynolds. O livro é muito legal e tem excelentes dicas sobre como fazer apresentações baseadas nos princípios Zen. O Garr trabalhou durante muito tempo na Apple fazendo design de apresentações e é fato que a Apple arrebenta nesse quesito. Depois de assistir apresentações que foram verdadeiros shows na Apple WWDC decidí ler o livro e tentar aprender alguma coisa sobre o que eles fazem.
Quando eu estava lendo o livro, um trecho de um capítulo que fala sobre os princípios de design acendeu uma lâmpada na minha cabeça e me fez atentar para uma coisa que acontece diariamente no desenvolvimento de software:
“Design can make things easier for the viewer or the user. Design is not decoration. If anything, design is more about subtraction than addition. Visually, we do not want to include too much, nor do we want to exclude too much. Generally, people err on the side of including too much visual information, which often results in clutter and confusion.“
É verdade. Existe uma tendência grande das pessoas acharem que mais funcionalidades e complexidade é sempre melhor. As pessoas pensam exatamente como descreve o livro Getting Real da 37 Signals:
“Conventional wisdom says that to beat your competitors you need to one-up them. If they have four features, you need five (or 15, or 25). If they’re spending x, you need to spend xx. If they have 20, you need 30.
This sort of one-upping Cold War mentality is a dead-end. It’s an expensive, defensive, and paranoid way of building products. Defensive, paranoid companies can’t think ahead, they can only think behind. They don’t lead, they follow.“
Transportando para o mundo do desenvolvimento de software, eu vejo que muitos desenvolvedores adoram entulhar seus códigos com todos os design patterns que já ouviram falar, adoram usar EJBs em qualquer coisa, adoram inventar seus frameworks malucos… Enfim, adoram fazer tudo que é complexo e trabalhoso. Assim como no design, entulhar o código com essas coisas só fazem ele ficar muito mais difícil de ser mantido e entendido!
Talvez um dos motivos disso acontecer seja que nem sempre o desenvolvedor tem senso de urgência e visão do negócio. Nem sempre ele entende que não dá para perder 3 dias fazendo um menu JavaScript que abre e fecha, ou passar 80% do tempo tentando encaixar design patterns no código, ou criar uma arquitetura com 36 camadas para diminuir o acoplamento. Essas coisas podem ser extremamente prejudiciais para o projeto, porque o cliente está esperando triplicar o faturamento e o número de visitantes do seu site e essas coisas não vão ajudar em absolutamente nada. A oportunidade de usar design patterns, criar camadas no software ou qualquer outra coisa surgirá naturalmente no decorrer do projeto. Se isso não acontecer, então simplesmente não os use.
Uma dica para descobrir se você ou alguém está fazendo uma coisa útil ou não é tentar responder a seguinte pergunta: “Qual problema será resolvido com isso?”. Ultimamente tenho feito essa pergunta para todo mundo e percebí que muito mais da metade das coisas não são justificáveis. É incrível como as pessoas criam coisas sem nenhum motivo, que só deixam o software mais complexo sem necessidade, tanto internamente (código) quanto externamente (interface).
Por isso eu gosto e recomendo trabalhar sempre com uma das regras básicas do XP. Independente de usar XP ou não, a simplicidade é uma ótima regra:
“A simple design always takes less time to finish than a complex one. So always do the simplest thing that could possibly work. If you find something that is complex replace it with something simple. It’s always faster and cheaper to replace complex code now, before you waste a lot more time on it. Keep things as simple as possible as long as possible by never adding functionality before it is scheduled. Beware though, keeping a design simple is hard work.”
Se você é desenvolvedor e adora complicar tudo, pare de brincar de professor pardal e pense simples, ou é isso que vai acontecer com a sua empresa:
28 replies on “Simplicidade”
GC,
Concordo 100% com tudo que vc disse! Aliás, tenho um post engatilhado que fala mais ou menos sobre o mesmo assunto. Vamos ver se agora sai 🙂
Dois comentários:
Meu discurso sempre é de fazer a coisa mais simples que possa funcionar, ser pragmático, seguir o príncipio KISS. Mas confesso que até hoje erro de vez em quando ao introduzir complexidade desnecessária. O ponto é que muito difícil manter a simplicidade constantemente. É preciso se policiar a toda hora para manter tudo o mais simples possível.
Outro ponto importante é não confundir simplicidade e a importância de ter visão de negócio (que realmente são fundamentais) com abrir mão de testes ou de oportunidades de fazer refactorings no código. É um equilíbrio difícil de conseguir também.
Excelente post!
É claro, nem sempre é fácil fazer as coisas mais simples. O próprio parágrafo que eu coloquei lá diz um pouco sobre isso: “Beware though, keeping a design simple is hard work.”. Várias vezes eu também me pego viajando em soluções alienígenas e, quando eu paro e penso no problema que quero resolver, percebo que estou indo pelo caminho errado.
E também é importante o que vc falou sobre testes e refactoring. É preciso ser simples, e não simplório. Não dá para usar a simplicidade como desculpa para não fazer coisas que são nossa obrigação 🙂
Finalizando, concordo com vc que é um trabalho constante de “policiamento”. Por isso é legal quando todos em um time tem esses princípios, porque quando alguém desliza sempre tem um outro para ajudá-lo a voltar para o caminho 🙂
[ ]s, gc
Excelente Post GC,
Uma vez vi uma apresentação do Jesse James Garrett da Adaptive Path, que mostrava uma tela do Microsoft Office com todas as funcionalidades e barras habilitadas, a parte da tela para escrever se limitava a algumas poucas palavras, e 98% das pessoas usam apenas 2% das funcionalidades do Office. Não é a toa que o Office leva 5 anos para ser desenvolvido e o Google Docs, foi feito em pouco 2 anos.
Focar nas necessidades dos usuários e entregar estas funcionalidades em produção nunca devem sair de vista do time de desenvolvimento. Como eu sempre digo “o ótimo é inimigo do bom” e não maioria das vezes o que o usuário quer é o “bom”.
Mas como o Cirne falou, é muito fácil perder o foco no simples e over develop e over architect.
Acho que a pergunta “Qual problema será resolvido com isso?” é muito boa. Coincidentemente eu sempre a uso, como por exemplo quando as pessoas querem enfiar frameworks no projeto sem necessidade.
@GC esse lance do “policiamento” é um bom argumento para pair-programming… 🙂
@Guilherme Cirne
Isso ae 🙂
Tá, agora me diz como é que eu faço uma tela de cadastro com um único campo texto 🙂
Excelente post Guilherme,
muito interessante mesmo, além de estar intimamente ligada ao design/desenvolvimento de software, principalmente na plataforma Java, em que vários desenvolvedores e arquitetos “megalomanicos” inventam, criam e viajam em funcionalidades super complexas, genericas e desnecessárias para solucionar problemas simples.
Assim como vocês dois (Guilhermes) também concordo que vez ou outra viajamos e começamos a imaginar soluções mirabolantes e genericas para problemas que eram mais simples do que pensavámos, neste ponto o policiamento é importante.
Parabéns pelo post.
Abraços.
Touche. Simplicidade e objetividade é tudo que precisamos. 🙂
@Anonymous Coward
Eu normalmente não libero mensagens anônimas, mas dessa vez vou abrir uma excessão para você se sentir um estúpido.
Faça uma tela de cadastro com um único campo assim: http://en.gravatar.com/site/signup/
A questão aqui não é se uma tela de cadastro precisa ter só um campo ou “n” para ser boa. O ponto é que você não deve fazer nada além do necessário:
“Generally, people err on the side of including too much visual information, which often results in clutter and confusion.”
E por último, deixa de ser COVARDE – vire homem e assine suas mensagens!
Guilherme,
Não se irrite com esses covardes anônimos hehe. É perfeitamente possível fazer uma tela de cadastro com um único campo texto.
Se o seu site usa a api do Open Id, no cadastro do seu sistema você só precisa pedir a URL do OpenId referente àquela pessoa. Portanto, aí está uma tela de cadastro com um único campo texto.
Quanta gente sem criatividade…
Abraços,
Bruno Carvalho
Sem dúvida nenhuma, quando puder simplificar, simplifique! O curioso é que as pessoas que você se referiu “muitos desenvolvedores adoram entulhar seus códigos com todos os design patterns que já ouviram falar” complicam as coisas desde primeiros passos. Primeiro criam métodos com 1000 linhas depois usam 1000 camadas. O pior de tudo é que este perfil de profissional não tem hábito de documentar, criar testes unitários.
Parabéns pelo tópico! E vale a dica, policie-se sempre, porque simplificar não é uma tarefa fácil!
belo post…
Existem diversos pratos! Todos podem ser degustados da melhor forma possível.
Mas nada tira do mercado o simples e famoso feijão com arroz que mata fome (funciona) de todos com a mesma eficacia e de forma simples. Nem mais e nem menos.
Escrevi um post com o mesmo intuito. Soluções atendem necessidades, não padrões.
Muito disso vem da vontade de aprender as diversas tecnologias que vira e meche nos são apresentadas. Sem dúvida a pergunta chave remove a pretensão de usá-las apenas como aprendizado. É como a regra dos cinco porquês.
@Anonymous Coward e @Guilherme Chapiewski
Gosto de pensar como neste post, concordo e é uma boa forma de manter tudo funcionando, com baixo custo de manutenção, com confiabilidade e etc, etc, etc.
Mas não acho tão estúpido quando o “Anonymous Coward” se refere à imagem no final do post. Acho que comparar um iPod Suffle, o site de busca do Google com uma aplicação de cadastro, por exemplo, bem desproporcional.
Até concordando com a colocação de que é necessário foco no negócio e deixar o cliente realizar logo seus lucros e blah, blah, blah. Como comparar uma funcionalidade Play/Stop ou até simplesmente “busque: java” com um sistema que precisa de uma tonelada de informações, seja para liberação de crédito, seja para cumprir requisitos mínimos de alguma agência reguladora? Simples, quem fez a imagem não está nem aí para o negócio de cada um dos produtos.
Não acho cabível pensar que o programa de IRPF seja complexo, com milhares de campos, por culpa e preciosismo dos desenvolvedores, com certeza não é por brincadeira.
Em se aplicando a imagem referenciada no final do POST, não acho tanta estupidez assim no comentário que gerou isso tudo. Acho que ela é como o POST diz, às vezes queremos impressionar e acabamos por atrapalhar um pouco as coisas.
[…] of an overdesigner I just read an interesting blog post from Guilherme Chapiewski on keeping software design simple (for those of you who don’t speak Portuguese, this might be […]
Prefiro continuar anônimo, já que assim eu posso expressar minhas opiniões de verdade, já que hoje em dia, qualquer pessoa com uma opinião que não seja a da moda (moda: ‘RUP não tá com nada, se não for Scrum full não presta’, ‘se vc não faz 100% de cobertura de testes, você não é profissional’ ou ‘Rails é o futuro’) é bombardeada por ondas de insultos pessoais (leia-se ‘estúpido’. ‘covarde’ é parte do meu nome fictício, então não conta).
Bem, quanto ao meu comentário, eu só quis dizer que:
1. Por ‘tela de cadastro’ eu não quis dizer cadastro de usuário de mais um orkut da vida, mas sim as telas de cadastro que todo mundo aqui tem que fazer nos sistemas do mundo real (cadastro de clientes, cadastro de produtos, etc.). O desenho é engraçadinho, mas compara laranjas com jacas e macaxeiras.
2. A maioria dos softwares feitos atualmente é de uso interno. Não precisa ser lindo e facílimo de se usar até pela minha tia-avó. Precisa ser usável (nada de ‘user eXperience’, só ‘dá pra entender’ é suficiente), de fácil manutenção e com produtividade.
3. Na verdade, pra se fazer uma interface simples, você tem sim que bancar o Professor Pardal (digo, pensar muuuito). ‘Simple is hard. Easy is harder. Invisible is hardest.’
Obs.1: As invenções do Professor Pardal sempre pareciam bem simples, apesar de exóticas 🙂
Obs.2: Hum… a sua política de bloqueio de comentários é contra anonimato ou opiniões contrárias? 😛
1) A política de comentários do meu blog é a mesma política de qualquer WordPress: se você já comentou no blog antes seu comentário é liberado automaticamente. Se nunca comentou, ele fica para moderação (tanto que dessa vez seu comentário infelizmente foi liberado automaticamente).
2) Tirando o WordPress de lado, minha política pessoal de comentários é de que você não tem o direito de comentar se você não for homem suficiente para dizer quem você é.
3) Sobre opiniões contrárias, elas são bem vindas se você for razoável e não for covarde 🙂
Ah, e sobre os insultos (“estúpido”), se você não tem capacidade para entender coisas no sentido figurado e leva tudo ao pé da letra achando que seus formulários de cadastros vão passar a ter só um campo depois de ler isso, vc precisa mudar de profissão.
@Flavio Crispim
O programa do IRPF não é um exemplo muito bom… Ele poderia ser muito mais simples, mesmo com aquela quantidade de campos.
Como eu já falei nos comentários acima, você está tentando entender o meu artigo no sentido literal. É ÓBVIO que há casos em que é impossível não ter vários campos. Mas a mensagem aqui é muito maior que isso, o meu post não é sobre campos de formulário! A questão aqui é sobre simplicidade e sobre fazer o necessário e nada além disso, evitar overdesign e overengineering.
@Guilherme
hahahaha é, eu sou estúpido mesmo… e meio babaca! Mas foi mal, não quis bagunçar com o seu blog não.
Eu concordo com você, as coisas têm que ser o mais simples possível mesmo. E eu acredito nas metodologias ágeis e testes unitários (mas não acho que 100% seja necessário). E sou fã da Apple e do Google. Não sou muito fã do Rails e do seu ‘Criador’, mas isso não vem ao caso 🙂
E gosto do seu blog, senão não estaria lendo-o 🙂
E desculpe de novo, não achei que o comentário ia gerar tanto ódio (e eu devia ter me identificado mesmo, malz) 😉
@Flavio Crispim: parece que você também vai ter que procurar outra profissão! hehehe 🙂
Anonymous Coward
@Guilherme
Acho até que o form da imagem pode ser muito bom para muitos e muitos sistemas da área financeira e de seguros, cá entre nós, quase todo programador já bebeu dessa fonte.
Concordo com você desde o início, não se trata de quantos campos ou se existem campos, mas a sua conclusão sugere isso, admita, ou pelo menos discuta, foi o seu post que comparou uma tela de cadatro com um iPod dizendo: “Se você é desenvolvedor e adora complicar tudo, pare de brincar de professor pardal e pense simples, ou é isso que vai acontecer com a sua empresa:” e na hora de analisar o IRPF…
Agora, se discutir idéias servir de desqualificar ou duvidar do seu interlocutor, ficarei aguardando com muito anseio um post futuro seu subre gerência de profissionais ou até como você fomentaria as discussões da equipe sob seu comando… belo exercício…
Sensacional post!!!
Eu sou totalmente a favor de código bem simples e limpo.
Creio que 80% ou mais das coisas que fazemos no dia a dia são
resolvidas com códigos bem simples… os 20% restantes
é que talvez necessitaremos de um “pattern aqui” e um “EJB lá”.
Então pessoal… vamos codificar de forma simples e clara!!! 🙂
[…] li recentemente um post do Guilherme Chapiewski que fala sobre a simplicidade, vale a pena ler pois este post é intensamente ligado à idéia de Simplicidade relatada no post […]
[…] o post do Guilherme Chapiewski veio bem a calhar, pois fala exatamente sobre […]
[…] o post do Guilherme Chapiewski veio bem a calhar, pois fala exatamente sobre […]
muito bom Guilherme, valeu…
até mais..
Já foi dito que uma pessoa demonstra que realmente APRENDEU algo, quando consegue explicar esse ALGO complexo a uma CRIANÇA.