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:
