Posts Tagged ‘Engenharia de software’

Pessoas não são recursos!

Sunday, July 12th, 2009

Esses dias vi uma mensagem no Twitter que me fez lembrar de algo que eu já queria ter falado aqui há algum tempo:

Referring to people as “resources” leads to thinking that individuals are interchangeable code producing units.

Toda vez que alguém chama uma pessoa de “recurso” dói meu ouvido. Chega até a ser chato, mas quando alguém faz um comentário sobre “recursos” do meu lado dificilmente consigo resistir a corrigir para “pessoas”. Como a Esther Derby disse na sua mensagem, tratar pessoas como “recursos” dá a impressão que as pessoas são “commodities“, que são meros “parafusos”, sem importância individual e substituíveis por qualquer outro.

Como que alguém pode se sentir bem sabendo que é totalmente descartável e que pode ser a qualquer momento trocado por qualquer outra pessoa? Como alguém pode estar comprometido com um projeto sabendo que é totalmente substituível e que não faz diferença se quem estiver ali for ela ou qualquer outra pessoa? Como alguém pode se sentir motivado assim?

E por fim a pergunta que eu queria chegar: Que tipo de código e que tipo de produto as pessoas vão conseguir produzir nessas condições?

Desenvolvedores de software são trabalhadores do conhecimento. Ao contrário de trabalhadores “Fordistas”, que são extremamente especializados numa linha de produção e desempenham atividades repetitivas e “robóticas”, os trabalhadores do conhecimento trabalham intensivamente com o seu cérebro, analisando e interpretando informações, descobrindo novas e melhores soluções para resolver problemas e tomando decisões o tempo todo.

Por esse motivo, é essencial que essas pessoas estejam motivadas, pois isso as deixa num estado mental que estimula sua produtividade, aumentando a quantidade de trabalho que podem realizar e potencializando o uso da sua criatividade para resolver problemas.

Um projeto de software bem sucedido é construido por pessoas motivadas, que tem visão do que estão fazendo e que acreditam nessa visão.

Para saber mais:

Java é ruim?

Sunday, October 19th, 2008

Em tempos de Ruby on Rails parece que está na moda falar mal de Java. Na Rails Summit então meus ouvidos chegaram a doer de tanto ouvir falar que Java é ruim, Java é burocrático, bla bla bla e que Ruby on Rails é fantástico, produtivo e sexy. Calma, essa não é mais uma daquelas comparações ridículas de Java versus Ruby on Rails.

Mas ainda ficou a pergunta que não quer calar: Java é ruim mesmo? A resposta, como sempre, é que depende do caso…

Em um projeto de desenvolvimento de software, mesmo antes de começar o desenvolvimento você já tem algumas restrições para escolher tecnologias. A finalidade do software por si só pode já restrigir muito a tecnologia que terá que ser usada.

Por exemplo, se você estiver fazendo um website, provavelmente você não escapará de fazer uma interface em HTML, Flash ou qualquer outra coisa específica para desenvolver uma camada de apresentação web. Provavelmente você não vai querer usar Assembly para fazer a parte server-side, já que não seria muito produtivo (apesar de não ser impossível). Eventualmente esse site pode ser um portal como a Globo.com que têm milhões de acessos por dia e você terá que escolher uma plataforma/linguagem/arquitetura que priorizem performance e favoreçam escalabilidade. Ou então pode ser um site com pouquíssimos acessos e você nem precisará se preocupar com isso…

Ou então você pode precisar fazer um pequeno script para fazer backup automatizado de um banco de dados MySQL. Seria totalmente incoerente usar Delphi, Fortran ou Piet. Provavelmente você vai querer usar algo como Shell script e resolver o problema em meia dúzia de linhas. Alguns bancos como o SQL Server têm mecanismos de agendamento de backup automático que são super fáceis de configurar e usar, portanto nesse caso usar Shell script seria trabalho desnecessário.

Meu ponto aqui é que não dá para dizer que Java (ou qualquer outra coisa) é ruim por sí só. Java pode ser ruim ou bom dentro de um contexto. Por exemplo, em 2005 eu trabalhei num projeto de Call Center à distância via Internet onde precisei desenvolver um softphone e a melhor opção foi usar Java Applets. Além de existirem bibliotecas Java para trabalhar com IAX (que é um protocolo como o SIP, só que proprietário do Asterisk), o usuário não precisava instalar nenhum programa para falar com o Call Center, bastava acessar o site. Eu odeio Applets com todas as minhas forças, mas foi ótimo para esse projeto (eu diria até que foi relativamente fácil). Seria correto então dizer que Ruby on Rails é ruim só porque seria impossível de fazer esse projeto com tanta facilidade? É óbvio que não!!!

Jamais existirá uma única linguagem ou plataforma para resolver todos os problemas. O desenvolvedor de software precisa conhecer vários tipos de ferramenta e saber escolher a melhor delas para resolver cada problema. Que fique claro que eu não sou defensor de Java, Ruby ou de qualquer outra coisa. O caso é que é incoerente dizer que X ou Y é bom ou ruim por sí só; é preciso analisar as opções dentro de um contexto.

Simplicidade

Saturday, August 30th, 2008

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: