Programador ou Desenvolvedor?

A diferença entre um programador e um desenvolvedor de software é muito grande, mas quase sempre ignorada.

Presa à um paradigma completamente equivocado, a “indústria” do software busca imitar a indústria “convencional”, baseada no trabalho manual, seguindo muitas das idéias de Taylor e Adam Smith.

Essas idéias e princípios funcionam muito bem no chamado trabalho manual, que, em geral, atinge sua máxima eficiência quando organizado na forma de linha de montagem, com alta especialização e divisão de tarefas. Mais uma vez: desenvolvimento de software não funciona como linha de montagem.

O software possui fatores inerentes que não são encontrados em produtos manufaturáveis. Como exemplo, podemos citar a complexidade: o software é formado por uma grande quantidade de elementos distintos, enquanto produtos manufaturáveis possuem muitos elementos repetidos ou semelhantes em sua composição.

É um fato: desenvolvimento de software é trabalho sobre conhecimento, não trabalho manual. A expressão “fábrica de software” chega a me dar arrepios, é uma afronta a quem trabalha com desenvolvimento.

O que muitos gerentes e diretores tentam fazer com o processo de desenvolvimento de software é torná-lo uma linha de montagem, como a de carros ou produtos eletrônicos. Aqui chegamos ao assunto principal deste artigo: o trabalhador.

As empresas tratam o trabalhador da indústria do software como uma máquina: sua função é receber uma especificação “mastigada” e apenas traduzí-la para uma linguagem de programação. Resumindo, um operário. Isto é um grande erro. Se há algum trabalho manual (de “chão de fábrica”) no desenvolvimento de software, este é o trabalho realizado por IDEs, editores, compiladores e ferramentas automatizadoras em geral.

O trabalhador acima descrito é o típico programador (ou, ainda pior, codificador). Ele não precisa pensar, apenas traduzir. E, pior do que o tratamento das empresas, é o que os próprios profissionais fazem consigo mesmos: a maioria aceita isso e acaba agindo como uma máquina codificadora por toda a carreira.

O desenvolvedor de software é um profissional muito mais completo: ele pensa. É um profissional altamente qualificado, com conhecimento multi-disciplinar, isto é, não apenas em informática, mas também em comunicação, gerência, negócios. Ele não precisa ser um mestre nessas outras áreas, mas deve conhecer, no mínimo, os princípios básicos de cada uma. Além disso, não fica esperando que alguém pague um treinamento: está sempre buscando melhorar. Não pelo aumento de salário ou pelo cargo com nome mais bonito, mas sim pela satisfação de realizar um trabalho melhor.

Quase todo o trabalho do desenvolvedor de software é trabalho de design. Trata-se de uma atividade criativa (a maioria das pessoas acredita que criativo é apenas o trabalho com resultado visual). Numa analogia à fabricação de carros, o desenvolvedor é o profissional que faz o projeto do carro, não o operário (ou robô) que apenas faz a montagem (o “compilador” do projeto de carro).

Aí nos deparamos com outro problema: a falta de estímulo. É muito comum que pessoas com talento e gosto por desenvolvimento de software mudem de área, geralmente devido aos baixos salários. Quando um desenvolvedor começa a ficar bom no que faz, torna-se gerente, vendedor, coordenador, enfim, qualquer outra coisa que pague melhor.

Acredito que as empresas devem investir em posições de alta responsabilidade também no desenvolvimento. Estou falando de profissionais com funções de liderança e gerência (incluindo salários e benefícios equivalentes a gerentes ou coordenadores) mas que ainda “botem a mão na massa”.

Em qualquer equipe é extremamente produtivo ter um profissional assim como referência, pois isso dá muito mais segurança aos profissionais que trabalham com ele. O que mais vemos por aí são equipes de desenvolvimento “órfãs”: quando algum desenvolvedor começa a se destacar, é retirado da equipe e muda de carreira. Os prejuízos são grandes mas, como são “invisíveis”, os empregadores simplesmente ignoram.

É bom lembrar que a questão “programador versus desenvolvedor” não é apenas culpa dos empregadores. Como mencionei anteriormente, os profissionais também possuem grande parcela dessa culpa. Após 7 anos trabalhando com desenvolvimento de software, creio que, para cada cinquenta programadores, existe um desenvolvedor de software (isto é totalmente baseado em observações pessoais).

E você, é um programador ou um desenvolvedor se software?

Como Definir sua Política de Senhas

Existe já uma extensa literatura na Internet orientando os usuários a escolherem suas senhas (conflitantes por sinal - afinal é uma boa coisa o usuário anotar a senha em um papel?) por isso não vamos repisar este tema aqui. Vamos falar aqui do outro lado - como definir a política de senhas apropriada para a sua aplicação ou rede.

Primeiro é bom lembrar que a política de senhas é um controle de segurança, e antes de defini-la você deve entender exatamente quais são os riscos que você quer mitigar com a senha - que dependem diretamente do valor do que está sendo protegido com a senha, e dos demais controles de acesso que existem adicionalmente além da própria senha. Por exemplo, a política de senhas para um sistema restrito a consultas não precisa ser tão rígida quanto a de um sistema que comanda transações, e os meu PIN number usado junto com o smartcard não tem que ser tão rígido quanto a minha senha de logon.

Também é necessário entender contra o quê estamos nos protegendo ao estabelecer uma política de senhas. Ao contrário do que normalmente se pensa, não queremos só evitar ataques por força bruta ou por dicionário. Queremos evitar também que o usuário esqueça a senha e tenha que resetá-la - segundo o Gartner 30% dos chamados de Help Desk são resets de senha, cada um levando em média 20 minutos para resolver. Em resumo, precisamos de senhas que sejam difíceis de adivinhar mas fáceis de lembrar.

Dito isso, vamos ao que eu considero ser as melhores práticas a serem utilizadas na hora de definir sua política:

Tamanho mínimo da senha e Complexidade da senha: A exigência de um tamanho mínimo e a de complexidade (i.e. a presença de letras, números, símbolos e maiúsculas/minúsculas) são a principal defesa contra ataques de força bruta ou dicionário. As duas juntas garantem um nível de variação - ou entropia - mínimo para tornar um ataque de força bruta demasiado caro ou mesmo inviável.

A configuração de complexidade default do Active Directory exige que a senha tenha pelo menos três símbolos de quatro categorias (maiúsculas, minúsculas, algarismos e caracteres não-alfanuméricos) e não contenha nem o primeiro nem o último nome do usuário. Isso deve ser suficiente para a maioria das organizações - pode ser implementado no entanto um critério particular através de passwords filters.

Mas como balancear a complexidade da senha com a necessidade dela ser facilmente lembrada pelos usuários? Orientando o uso de frases secretas ao invés de senhas curtas mais ininteligíveis. Por exemplo, a senha Eu compro pão na 111N tem mais entropia do que dce*(1%& e é muito mais fácil de ser lembrada. Não aceite a velha desculpa de que os usuários não vão conseguir lembrar as senhas e por isso não dá para forçar senhas complexas - a experiência no mundo real prova o contrário.

Troca periódica da senha: Gene Spafford argumenta que forçar a troca da senha periodicamente acrescenta muito pouco em termos de segurança. A origem da troca periódica de senha está no tempo em que o poder computacional para fazer o ataque de força bruta contra uma senha era limitado, e fazia sentido trocar a senha em um prazo menor do que o tempo que em tese seria gasto fazendo o ataque. Nos dias de hoje com o poder computacional existente em um cluster (ou em uma botnet) esse cálculo não faz mais muito sentido, e forçar uma troca periódica muito freqüente cria mais chamadas no Help Desk do que proteção adicional.

Trocas periódicas de senha têm no entanto um outro benefício - elas são ótimas para você encontrar contas de usuário que não são mais utilizadas (stale accounts) e deveria ter sido desabilitadas ou removidas. Eu recomendaria colocar a troca periódica na política de senhas, mas em um prazo maior, talvez a cada três ou quatro meses.

Não repetição das últimas senhas: Usado para impedir que o usuário "troque" a senha e continue com a mesma. Não vejo contra indicações em definir um limite alto para esta - o default no Windows são as últimas 24 e parece adequado.

Prazo mínimo de troca de senhas: Serve em tese para impedir que o usuário troque a senha seguidas vezes, ultrapassando o limite estabelecido para não repetir as últimas senhas, e voltando para a senha anterior. Tem no entanto um efeito colateral: se o usuário trocou a senha e ele não se sentiu confortável (ou mesmo foi vista por uma outra pessoa), ele terá que esperar o prazo mínimo ou chamar o Help Desk para poder fazer uma nova troca. Por mim não vale a pena definir este prazo - se alguém teve a pachorra de trocar a senha 24 vezes seguidas para continuar com a anterior, então merece ficar com ela!

Bloqueio de contas: Bloquear o acesso do usuário após um determinado número de tentativas de autenticação incorretas é uma das melhores formas de se proteger contra ataques de dicionário ou força bruta. No entanto como todo remédio muito potente ele tem efeitos colaterais sérios.

O pior de todos é expor o seu serviço a um ataque de negação de serviço trivial - basta uma pessoa fazer propositalmente algumas tentativas inválidas de logon para bloquear o acesso daquele usuário, e com um pequeno script se bloqueia a organização inteira. Se o serviço estiver disponível pela Internet, então basta uma pessoa qualquer na Internet para cortar o logon de toda a empresa.

Aqui na Microsoft não usamos bloqueio de contas. A análise de risco mostrou que um atacante poderia facilmente de qualquer ponto da Internet usar o o nosso Outlook Web Access para bloquear todas as contas de usuário do Active Directory, um risco inaceitável para a empresa. Se este risco também é inaceitável para a sua organização, não habilite o bloqueio de contas e use o tamanho mínimo e a complexidade como mecanismos de proteção. E é claro monitore qualquer tentativa de repetida de autenticação inválida.

Se no entanto a sua análise de riscos aponta para o uso de bloqueio de contas, existe o problema do bloqueio indesejado - aquele onde o próprio usuário bloqueia a sua conta. Boa parte das vezes isso acontece após a troca, por alguns programas gravarem a senha anterior (o Windows 2003 evita esse problema não contando para fins de bloqueio uma tentativa de logon inválida usando a senha anterior), ou pelo próprio usuário digitar a nova senha incorretamente.

Para minimizar o bloqueio indesejado, que causa perda de produtividade e custo de help desk, defina um limite alto para bloqueio - 10 ou mesmo 50 tentativas como no nosso guia de segurança. Isto continua sendo efetivo como proteção contra ataques de força bruta, e elimina drasticamente o número de bloqueios indesejados.

Para terminar, eu queria somente enfatizar a necessidade de se ter uma política de senhas, qualquer que seja ela. Junto com a aplicação dos patches de segurança, trata-se na minha opinião das duas medidas de segurança mais importantes que uma organização pode tomar. Na minha experiência vendo incidentes de segurança, a enorme maioria deles teria sido evitada se os patches estivessem aplicados e senhas fortes estivessem sendo utilizadas. Se você estiver começando agora a definir a estratégia de segurança da sua organização, comece por estes fundamentos.

© por Fernando Cima
© http://blogs.technet.com

Falta de visão das faculdades é o que afeta o brasileiro

Já faz alguns anos que penso isso, mas o post entitulado “Por que o Brasil não desenvolve Twitters e Facebooks?” do Blog do Hummel me deu uma motivação a mais para escrever. Durante meus anos de estudante universitário venho percebendo a insistência que vários professores tem no tal “Mercado de Trabalho“. Com o tempo isso acaba passando para grande parte dos alunos. O problema é que esse termo acaba servindo como uma venda para os alunos e acaba afetando o país antes mesmo deles se tornarem profissionais. Qual o maior problema no tal mercado? É que justamente por martelarem tanto nos jovens o termo “Mercado de Trabalho”, esses jovens acabam vestindo uma viseira, assim como os cavalos e burros de carga que com essa viseira só conseguem enxergar uma única direção.

Pior ainda aqueles que enchem a boca ao usar o termo, como se o “Mercado de Trabalho” fosse uma verdade universal incontestável. Quando é que será que essas pessoas irão perceber que nada pode ser imutável? Esse tal “Mercado” deve ser feito pelos alunos. O problema é que acontece o contrário. Eles passam tanto tempo apenas tentando se adequar ao tal “Mercado” e acreditando que esta é a única coisa importante do mundo que acabam alienados, se esquecendo todo o resto. Um exemplo disso é o número de alunos que existem em faculdades, com excelentes notas, mas que provavelmente não sabem quase nada do que acontece atualmente no mundo. Já vi muitos estudantes de tecnologia que não sabem ainda o que é Twitter, ODF, OOXML, Ruby, Python ou que a Sun quer fechar alguns pedaços do MySQL… Muitos nem mesmo conhecem o Slashdot ou o Digg. Existem até mesmo aqueles que detestam Linux e dizem que o mercado é só Microsoft e, ainda assim, não sabem quem é Ray Ozzie, Sam Ramji, Porta 25 e que, muitas vezes, ainda falam aquela aquela velha besteira: “Olha que o código do Linux vai ser fechado e o Linux vai ser pago…”

Essa obsessão pelo “Mercado de Trabalho” faz com que vários alunos passem anos aprendendo uma tecnologia que muitos dizem ser “o que o mercado quer” para depois perceber que nem acabaram de se formar e já estão obsoletos. Essa mesma obsessão pelo “mercado” tira o idealismo que todo universitário deveria ter. É triste saber que muitos estudantes de tecnologia só ficam sabendo algo diferente do que é passado nas aulas se lêem em alguma revista como a Info.

O brasileiro, infelizmente, é muito inflexível. Costuma ter medo de inovações e se apega facilmente a instituições e modelos ultrapassados. O brasileiro também é muito burocrático. Adora papéis. Um simples pedaço de papel é supervalorizado em nosso país. Não importa o talento de um profissional. A maioria das pessoas sempre dá mais crédito àqueles que tem um diploma (mesmo que esse seja apenas um idiota que poderia achar uma utilidade melhor para seu diploma como papel higiênico). O brasileiro também adora encher linguiça e acredita que com isso esteja passando uma imagem de culto e estudado. Infelizmente eles muitas vezes não se dão conta disso e acreditam que estejam fazendo as coisas da forma certa. As vezes fico pensando em quantos profissionais tem por aí que passam mais tempo fazendo os diagramas de um banco de dados do que o próprio banco? Recomendo que leiam o post “A faculdade nos prepara para estarmos despreparados para o mercado de trabalho” do Leonardo Bighi, com atenção especial para o parágrafo em que ele conta sobre uma entrevista de emprego que ele fez recentemente:

“Até reparei isso recentemente ao fazer uma entrevista de emprego. Sorte minha que foi com algo simples. Ao ter que escrever uma query em SQL, eu precisava unir duas tabelas. Eu poderia ter colocado uma simples vírgula entre os nomes da tabela, e eu tinha noção disso, mas viciado pelas avaliações de faculdade eu tive todo o trabalho extra de escrever por extenso “INNER JOIN” para uní-las. Pior ainda que o entrevistador citou este fato, me lembrando que teria sido melhor ter apenas colocado a vírgula.”

Antes de contar essa passagem, Bighi explicou:

“Nas universidades, por algum motivo completamente desconhecido, parece que todos os professores decidiram em uníssono seguir o caminho completamente oposto. Uma solução direta para um problema é punida com uma nota apenas parcial. Você não consegue a nota máxima sem enrolar e resolver o problema de um jeito extenso e demorado“

Outra coisa totalmente ultrapassada é a tal obsessão que muitas faculdades parecem ter nos tais “softwares de cadastro de clientes, fornecedores etc”. Não seria melhor que nas aulas os professores incentivassem os alunos a desenvolverem os softwares que eles quisessem ao invés de forçá-los a fazer sempre a mesma coisa que sempre foi feita extensivamente durante anos? Voltando ao post do Hummel sobre o Brasil não desenvolver Twitters e Facebooks, será que a resposta para sua pergunta não está neste parágrafo? Os professores insistem nos programas de “cadastro de clientes” como se fossem a única coisa que o mercado quer, enquanto muitos alunos, acreditando cegamente em seus professores, acabam perdendo o interesse de criar coisas interessantes como redes sociais, novos modelos de negócios, jogos ou qualquer outro tipo de software ou site que não tenha a ver com o cadastro de alguma coisa para alguma empresa.

©Terramel

Níveis de Abstração

É difícil escrever sobre níveis de abstração. É um conceito fundamental em ciência da computação porque está diretamente ligado com o conceito de modelagem. No entanto, é difícil de explicar, e difícil de exemplificar. Para o engenheiro de software, saber lidar com diferentes níveis de abstração é ao mesmo tempo um requisito da profissão, e, ao mesmo tempo, um desafio sempre presente.

Qual o nível correto de abstração que devo usar nesse caso? Essa é uma pergunta recorrente para o profissional consciente de que lidar com níveis de abstração é importante.

Afinal o que é abstração? Pura e simplesmente é a subtração de detalhes, ou seja, é a capacidade de expressar algo de maneira concisa, abstrata, sem que os detalhes fiquem a mostra. Em qualquer disciplina que lida com complexidade, abstrair detalhes é de fundamental importância. Por isso em engenharia de software o conceito e seu uso são importantes.

Em uma aula usei o exemplo da palavra árvore no sentido natural. Meu argumento é que quando pensamos em uma árvore, abstraímos vários detalhes e pensamos em uma idéia geral, mesmo sabendo que existem diferentes tipos de árvores. Sem ser por coincidência, a estrutura de dados árvore é fundamental na engenharia de software, mas aí é um outro tipo de árvore, cuja raiz é única e as folhas crescem para o chão (estranho, mas é isso mesmo). Pedi um exemplo da turma, e um voluntário falou “controle remoto”. Sua justificativa é que pensamos sobre e usamos o controle remoto como uma abstração, sem preocupação como ele funciona. Eu sei não é o melhor exemplo, mas ajudou, creio eu, a passar a mensagem.

Vejamos o que garimpei na rede em busca de uma melhor explicação sobre abstração. Alguns desses sítios estão em Inglês.

O primeiro é de dicas para escrever textos técnicos em Inglês. A autora é a Dra. Jan Strever do “Spokane Community College” no estado de Washington nos Estados Unidos. O interessante nessa indicação é a categorização que a professora usa para exemplificar o que é abstração. Gostei. Vejam aqui.

Para uma outra visão, que creio ajuda a melhor entendermos abstração, vale a pena ler o primeiro parágrafo do verbete abstracionismo da enciclopédia Itaú Cultural. Depois disso, visite um museu virtual com obras de Kandinsky e outro com obras de Klee. Vale a pena. Creio que os dois artistas bem expressam o conceito abstrato, isso claro sem falar em Picasso e o cubismo.

Voltando ao mundo da Engenharia de Software. Veja o que diz o popular Joel Spolsky: “But JavaSchools also fail to train the brains of kids to be adept, agile, and flexible enough to do good software design (and I don’t mean OO “design”, where you spend countless hours rewriting your code to rejiggle your object hierarchy, or you fret about faux “problems” like has-a vs. is-a). You need training to think of things at multiple levels of abstraction simultaneously, and that kind of thinking is exactly what you need to design great software” [ref]. O “blog” do Joel é também apresentado em Português.

Para os que gostam da Wikepedia, aqui vai o ponteiro (em Inglês). Em Português o foco da definição do Wikepedia é da área de filosofia, mas vale a pena olhar.

© Julio Cesar Sampaio do Prado Leite