Posts Marcados Desenvolvimento

White Fox: O Conceito

Nestes mais de 15 anos de carreira, meu sonho sempre foi ter meu próprio negócio, uma empresa de desenvolvimento de software que fosse algo diferente e reconhecida pela qualidade do seu pessoal e de seus produtos. Nestes anos, eu tive algumas empresas, todas buscando atingir esta meta, porém, por várias razões, nenhuma delas chegou a atingir este ideal.

Sonhos não morrem, eles permanecem no inconsciente e em momentos propícios, voltam com toda a força. E mais uma vez, está chegando a hora de tentar de novo e atingir o meu ideal. Estou na fase de concepção de uma nova empresa, a White Fox Consultoria e Desenvolvimento de Software. Neste post quero falar um pouco sobre o que estou buscando, quais as motivações e que valores eu estou trazendo para esta nova empresa.

Desta vez acho que tenho grandes chances de atingir meu sonho. Em todos estes anos, eu tive a oportunidade de ver o que funciona e o que não funciona na gestão de uma empresa de desenvolvimento, tanto em aspectos de relação interpessoal quanto na parte de resultados e controle. Acredito que esta experiência, acumulada com muitos erros e acertos (quero crer que tenham sido mais acertos do que erros), é essencial para que a White Fox possa ter sucesso.

Uma das lições mais importantes que eu aprendi é que para que uma pequena empresa tenha sucesso, os seus sócios devem fazer mais do que gerir. Não tenho dúvida que administrar bem em todos os aspectos (especialmente o financeiro) é fundamental para o sucesso. Porém isto não é nem de longe o suficiente. Pois por melhor que seja, um bom gerente administrativo não é capaz de trazer aquilo que cada vez mais eu acho que seja o mais importante: a paixão pelo que se faz, a inspiração para si e para seu time de fazer o melhor e buscar o melhor sempre, o orgulho e o prazer de se estar fazendo algo excepcional. E tudo isto só é possível quando o líder consegue ser a representação disto para todo o time; desta forma ele tem que ser (ou pelo menos ter sido) antes de tudo, um excelente técnico.

Assim, a White Fox está sendo concebida com o melhor de todos estes mundos. A paixão por desenvolvimento e tecnologia é o que move cada integrante da nova empresa. A gestão transparente e minimalista garante que todo o esforço seja voltado para o negócio da empresa, que é fazer bom software para seus clientes. E um time ultra-selecionado, com os melhores profissionais da área produz a mistura que irá permitir que ela tenha muito sucesso.

A White Fox traz alguns conceitos pouco usuais na nossa área. Um deles é que o time seja realmente formado por somente arquitetos/seniores, do tipo que é capaz de fazer um sistema do zero em pouco tempo e que é capaz de atuar em todos os aspectos de um sistema, do banco de dados à interface, passando pela gestão de atividades e pela interação com o cliente. A excelência técnica e o pragmatismo são as características mais relevantes dos membros do time da White Fox. Outro conceito é que cada integrante é um sócio na empresa, sendo responsável pelas decisões da sua alçada e recebendo uma parcela do resultado geral do negócio. Finalmente, iremos buscar um ambiente de trabalho extremamente agradável, sem nenhum tipo de burocracia desnecessária. A idéia é fazer da White Fox o local ideal de trabalho para um desenvolvedor.

O formato de desenvolvimento é o agile. Fortemente baseado no Scrum, mas sem ser Scrum, a empresa irá ter como missão produzir com software com ROI extremamente vantajoso para os seus clientes. O formato implica também uma certa maturidade do cliente. Contratar no formato agile significar que o cliente é também parte do desenvolvimento e o sucesso de qualquer projeto é diretamente proporcional à qualidade e envolvimento do pessoal do cliente. Claro que este formato não é para todos, mas para os que se encaixarem neste perfil, a recompensa será software sendo desenvolvido de maneira rápida e com um ROI excepcional.

Outro diferencial é emprego de um framework de desenvolvimento em todos os produtos construídos. Este framework tem sido evoluído ao longo de vários anos e agora está maduro o suficiente para permitir o desenvolvimento incrivelmente rápido de sistemas sem nenhum sacrifício de usabilidade ou manutenabilidade. O uso e padronização do framework no desenvolvimento da White Fox facilita também o treinamento de pessoal e a manutenção de todos os sistemas produzidos. E, pela qualidade das pessoas do time, o framework vai sendo evoluído a todo tempo para permitir ainda mais velocidade e qualidade final.

A empresa será lançada oficialmente no início do ano que vem. Extra oficialmente ela já está a todo vapor, o time inicial está definido e ela já tem faturamento suficiente para garantir o início das operações. O web site está sendo construído para representar todos estes valores e os clientes estão sendo apresentados à esta nova forma de trabalho (com muito sucesso até agora!). Antes que perguntem sobre o nome, Fox é uma palavra de relevância especial para mim, ligada à agilidade que quero representar. A cor branca transmite simplicidade, clareza e transparência. O logo final está abaixo:

 

logowhitefox

 

Se você se identificou com este sonho e quiser fazer parte deste empreendimento, me mande um email. O time inicial está pronto, mas a perspectiva é de crescimento rápido. Aguardem então para mais notícias sobre o andamento desta nova empresa!

, , , , ,

3 Comentários

Profissão Codificador

Acho que a carreira de muitos de nós, programadores, começa de maneira similar: usualmente em algum momento da adolescência temos contato com computadores, ficamos fascinados por eles (na minha época foi um Gradiente Hotbit MSX, com programação BASIC) e a partir daí começamos a programar. E se você está lendo este blog, é grande chance de que nunca mais você tenha parado!

Mas me pergunto como será o nosso futuro nesta carreira. Tirando os que mudam de área (viram gestores, analistas de “negócio”, instrutores ou simplesmente vão fazer outra coisa) ou os que passaram em concurso público (este é um assunto que eu nem vou entrar!), eu fico imaginando como seria o futuro dos que continuam a programar. Alguns se tornam consultores independentes famosos, o que irá garantir uma aposentadoria tranquila escrevendo livros, artigos e ministrando palestras. Mas acho que  atualmente a maioria dos bons codificadores trabalha no esquema de pessoa jurídica, para um ou mais clientes e vive da capacidade de horas que consegue fazer. E até quando? Em algum momento isto vai ficar cansativo, ou ele vai se desatualizar e vai sair do mercado (interessante que, salvo raras exceções esta ainda é uma área quase 100% masculina… mas isto é assunto pra outro post!). E qual será o destino destes codificadores?

Apesar de se trabalhar no esquema de pessoa jurídica implicar que se tenha um negócio, infelizmente esta é uma profissão com muito pouca “escala”, já que o limite são as horas que cada um consegue fazer no mês. Mesmo para os que têm uma veia empresarial e que contratam um ou mais auxiliares, esbarra-se no limite de gestão de equipe (que pra mim varia de 4 a 7 pessoas). A partir daí, a qualidade cai ou se começa a ter dificuldade de garantir entregas ou prazo. E as tentativas de crescimento com equipes maiores são extremamente complicadas – falo por experiência! E não é fácil ter um negócio dependente da venda de projetos ao invés de horas; da maneira que eles como são vendidos hoje, em regime de preço fechado, eles tem um risco altíssimo, que quase sempre é negligenciado para se garantir o melhor custo, resultando em mais prejuízos do que sucessos.

Assim me pego muitas vezes pensando neste assunto. Nossa profissão é jovem, ou seja, não tem muita gente no final de carreira ainda. Mas estamos prestes a chegar lá. E acho que se não começarmos a pensar e atuar nisto, pode ser que para a maior parte de nós, este fim de carreira não seja uma experiência muito tranqüila.

Outro ponto interessante é que os que permanecem codificando são justamente os melhores desenvolvedores. E lembrando da regra de 10:1 de produtividade (como o Steve McConnell sumariza bem aqui), isto significa que as pessoas que tem mais probabilidade de ter problemas no final da carreira são justamente as que são as grandes responsáveis por construir o que está sendo feito hoje, como líderes de times, arquitetos ou simplesmente “virando” noites para fazer aquele projeto atrasado e over budget ser entregue. De uma certa maneira, este grupo é a espinha dorsal dos que hoje fazem acontecer e que são usados pelos que não são tanto (para quem gosta de reflexões mais aprofundadas, recomendo o livro “Atlas Shrugged” da Ayn Rand. Escrito na década de 50, fala de uma sociedade onde poucas pessoas com excelência técnica e artística sustentam todos os demais até que elas se cansam e entram em “greve”… Muito interessante).

De certa maneira, a disseminação cada vez maior de metodologias ágeis melhora um pouco o cenário das pequenas empresas. A troca do modelo de venda em preço fechado por uma baseada em venda de equipes para iterações curtas beneficia todos, permitindo que os riscos sejam melhor gerenciados e expondo-os muito mais cedo no processo. Exemplos como a ThoughtWorks, que se especializou neste tipo de venda com sucesso mundial acabam incentivando a mudança de cultura que está em curso atualmente. Claro que vai demorar pra isto subir até que licitações públicas sejam feitas de forma diferente, por exemplo, mas acho que isto vai acabar acontecendo.

Mas isto não é a resposta para a grande maioria, que não tem vocação (ou interesse) em se transformar em empresários. E apesar de pensar bastante nisto, não vejo saída fácil e fico preocupado com o futuro destes desenvolvedores. Mas não deixo de conjeturar como seria se todos estes melhores codificadores se juntassem em algum tipo de empresa comum, onde a excelência técnica fosse aplicada na construção de produtos que resultassem em ganhos diretos. Interessante, não? Se alguém tiver pensamentos a respeito deste assunto, entre em contato!

, ,

5 Comentários

Desenvolvimento Ágil e Processos

Esta semana tive a oportunidade de conversar com vários clientes sobre o desenvolvimento ágil e a quantidade de controles e processos que devemos utilizar para suportá-lo. No meu caso, a virada de 180 graus de um desenvolvimento waterfall clássico (com especificação, aprovação e execução) para um desenvolvimento ágil teve como conseqüência inicial a abolição completa de controles e processos – até porque os controles e processos waterfall não se aplicam a um desenvolvimento ágil.

Porém, esta abolição completa está começando a gerar efeito colateral negativo, em dois aspectos: rastreabilidade de decisões e controle de faturamento. A deficiência nestes dois aspectos me foi apontada por clientes e vem sido também sentida internamente pela equipe de desenvolvimento.

A questão da rastreabilidade significa entender, às vezes muito tempo depois da implantação, porque uma determinada funcionalidade foi implementada de uma certa maneira ou porque determinada decisão de negócio (ou de arquitetura) foi feita em detrimento de outras. E, em um desenvolvimento ágil, isto comumente se perde já que os itens de backlog vão sendo implantados e código produzido, ainda que bem comentado, não é suficiente para se manter a visão destas características. Embora as práticas ágeis não sejam contra a documentação (muito ao contrário), fica a questão do quanto e como se documentar. Uma documentação que não seja realmente útil significa gastar horas que poderiam estar melhorando o ROI gerando novas funcionalidades.

A questão do faturamento do trabalho produzido por uma equipe ágil também é um ponto problemático.Mesmo assumindo que o cliente já tenha comprado a idéia de usar uma metodologia ágil, ainda assim ele vai querer uma contabilização do que foi gasto e aonde. E embora o product manager e o cliente específico da funcionalidade tenham uma comunicação extensiva, muitas  vezes existem outras pessoas para as quais é importante prestar conta das atividades realizadas. Ainda que a produtividade seja alta, algumas vezes é difícil se ter uma visão do trabalho gerado em cada interação, especialmente em longos períodos de tempo.

Desta forma, nestes dois aspectos, é necessário se definir artefatos e processos mínimos que sejam capazes de gerar e armazenar estas informações. No nosso caso, o que temos feito é tentar automatizar estes processos através de sistema interno específico, para minimizar o tempo despendido na geração destes artefatos e para padronizar as informações produzidas. Assim, para a gestão do backlog, controle das atividades realizadas em cada iteração e armazenamento de notas referentes às tarefas realizadas, estamos desenvolvendo um produto web específico que denominamos Iterator. Nele, teremos a gestão do backlog, a definição das iterações com as específicas tarefas, um amplo suporte a notas, descrições e arquivos anexados a cada tarefa e uma visibilidade por perfil. Ele possui também um módulo windows que é utilizado pelos desenvolvedores para apontar, de maneira simples, rápida e minimamente intrusiva, as atividades em que atuou, permitindo a visibilidade pelos membros da equipe e stakeholders do projeto.

Alguns podem achar que desenvolver um sistema internamente para isto é um overkill, já que existem alguns produtos voltados à gestão e controle do desenvolvimento ágil. Porém, os melhores que analisamos ou são caros (outro conceito relativo, mas caros no nosso cenário) ou são voltados exclusivamente para a gestão de backlog (sem o lado de faturamento) ou simplesmente são muito complexos para se adotar, gerando custo excessivo de treinamento e adaptação. Desta forma, acredito que o custo de desenvolvimento do Iterator (que com o framework, não é tão alto assim), acaba sendo compensado por estes fatores. Finalmente, existe o objetivo de transformá-lo em um produto, o que traz outras compensações.

Se alguém possuir necessidades similares ou que use um produto que não atenda completamente e quiser influenciar no desenvolvimento, basta entrar em contato. Conforme formos evoluindo e quando tivermos algo disponível publicamente, eu notifico a todos por aqui. Até a próxima.

, , , , , , , ,

Deixe um comentário

Produtividade – Conclusão

Oi pessoal, este é um último post da série sobre produtividade. Nos anteriores, eu descrevi a infra-estrutura de desenvolvimento que é usada pela minha equipe atualmente. Toda esta infra-estrutura nada mais é do que uma ferramenta utilizada por nós para se realizar a construção de sofware. Nossos clientes, na grande maioria dos casos, não se preocupam se o software é feito em C# ou em Clipper, ele quer saber se o que ele precisa é barato pra fazer e manter e se é simples e fácil de usar.

Assim, eu vejo esta infra-estrutura toda muito com esta visão pragmáticas, de ser algo que deve permite entregar ou modificar rapidamente uma funcionalidade de negócio, sendo produtivo na hora de atender uma necessidade. Isto faz a diferença para mantermos o nosso cliente satisfeito, com retorno que ele julgue satisfatório para o que ele gasta para se construir software.

Neste sentido, estou bastante satisfeito com a nossa infra-estrutura. Ela é rápida para se iniciar algo do zero, muito rápida para se fazer coisas triviais (como CRUDs) e tão ou menos complexa que outras alternativas para se fazer coisas complicadas. Acho que isto o máximo que podemos esperar de qualquer framework. O meu pragmatismo é aplicado todo o tempo e qualquer alteração no framework (que é sempre caro pra fazer) se justifica somente se ela vai trazer mais produtividade em algum aspecto. Usando o framework atual, estamos conseguindo colocar no ar uma aplicação nova, com controle de acesso (vou detalhar mais isto em posts futuros), estrutura básica e layouts iniciais em poucas horas. Fazer um CRUD de uma entidade leva menos de 15 minutos, considerando do tempo de criação da tabela ao final da tela!

Claro que a produtividade final não depende somente da infra-estrutura. Na minha experiência, 90% do tempo de construção (ou manutenção) de qualquer aplicativo grande fica restrito a umas poucas telas de maior complexidade. Assim, é importante saber trabalhar com o cliente no sentido de minimizar a existência deste tipo de interface. Neste sentido, acho que fazer software não é só entender a necessidade de negócio, é também saber o que é simples ou não de fazer e propor soluções funcionais que sejam mais fáceis de desenvolver. Desta forma, a maneira como se desenvolve acaba também influenciando a necessidade, em uma via de duas mãos. Daí a importância de quem está entendendo a necessidade conhecer muito bem como aquilo vai ser feito, sob pena de se orçar muito mal ou se gastar muito para fazer, com prejuízos para o cliente ou para a própria empresa que desenvolve. Este é um conceito que parece que muitas “analistas” não compreendem, e a causa da falha ou prejuízo de muitos projetos.

Ainda tenho muitas melhorias a serem feitas neste framework. Ainda existem tipos de telas que podem ser melhor suportados, novas funcionalidades que podem ser integradas e alguns serviços que estão sendo refatorados a todo tempo. Porém acho que ele já está maduro o suficiente pra ser empregado em qualquer sistema. Existem áreas para as quais eu ainda não tenho uma solução boa. A geração de relatórios é uma delas. Gerar relatórios na web em geral é algo complexo, pois é difícil montar os layouts e nós sempre encontramos com uma série de limitações de desempenho e banda causadas pelo volume transitado. Não gosto de nenhuma das alternativas existentes atualmente e ainda estou buscando uma que me permita fazer gerar uma DSL e que tenha um comportamento preditível. Informo aqui quando encontrar!

Espero ter contribuído para quem teve a paciência de ler até aqui. Como citei no início, esta infra-estrutura é um exemplo que é difícil de ser replicado para outras equipes ou de suportar uma escalabilidade maior, já que ele exige um treinamento e conhecimentos muito específicos. Mas acredito que os princípios sejam gerais, e possam ser aplicados a outros cenários. Nos próximos meses eu vou adicionar adendos a esta série toda vez que houver uma evolução ou fato novo referente ao framework ou relativo à produtividade em si. Até a próxima.

, , , , , ,

Deixe um comentário

Produtividade – Camada de Domínio

Continuando a série sobre produtividade, vou falar neste post sobre a camada de domínio. A camada de domínio é a que contem todas as entidades e regras de negócio, sendo utilizada pela camada de interface e fazendo uso do banco de dados para armazenamento de informações.

Inicialmente existe a questão da impedância objeto-relacional. Para o desenvolvimento o usual é trabalhar com objetos em código para representar objetos do mundo real, com seus vários atributos e relacionamentos. Uma tabela de banco é uma representação mais pobre e difícil de manipular, por isto trabalhar com objetos é mais simples. No entanto, o banco de dados relacional é necessário (bancos de dados orientados a objeto ainda são praticamente inviáveis, por uma série de razões), logo, deve haver uma maneira de converter classes em tabelas e instâncias em registros. Assim, o uso de um ORM é fundamental, pois esta tarefa tem que ser simples, não faz sentido gastarmos tempo de desenvolvimento escrevendo e debugando comandos SQL básicos.

Nosso ORM de escolha é o nHibernate (NH). No entanto, escrever arquivos de configuração paro nHibernate é trabalhoso (e não queremos trocar o trabalho de escrever SQL para o de escrever configurações), assim utilizamos também o Castle ActiveRecord (AR). O AR permite definir objetos com simples atributos de decoração e ele já traz também uma série de implementações pra facilitar o uso do NH. Apesar de ser mais simples, decorar classes e atributos ainda é trabalhoso (e erros nesta etapa podem causar graves conseqüências para aplicação), então para simplificar ainda mais, utilizamos o ActiveWriter (AW), que é uma DSL gráfica que permite descrever as entidades e ele gera todas as classes e propriedades já decoradas. O AW tem outras vantagens, descritas a seguir.

Até aqui super simples, mas existem duas guerras religiosas envolvidas que acho importante citar. As duas têm relação com o chamado “modelo anêmico”, definido pelo Fowler. A primeira é sobre se todos os objetos de domínio devem ou não ter representação direta em banco. Em um modelo OO puro isto não seria desta forma. Porém a minha opinião é de que é muito mais simples, pra efeito de desenvolvimento, manutenção, extração e até conversa com os usuários avançados, que haja o mapeamento 1:1. Ou seja, cada classe é uma tabela, cada registro uma instância. Os puristas afirmam que isto não é OO, pois o modelo de entidades de negócio acaba sendo só uma representação do banco. Na minha visão sim, pode ser… Porém como o banco na verdade é criado para suportar as classes, há um caminho de duas vias aí. E os benefícios que tenho colhido nos últimos 10 anos trabalhando desta maneira são muito grandes pra tentar mudar simplesmente pelo purismo. Assim, no nosso caso, há o mapeamento 1:1 sempre.

A segunda guerra religiosa tem a ver como onde as regras de negócio são implementadas. No Domain-Driven Design (DDD), existe o conceito de serviços, porém muitos acham que regras específicas de objetos devem estar na classe. Eu não. Eu acho que TODAS as regras de negócio devem estar definidas em Serviços (com exceção de regras de consultas, que estão nos repositórios e de regras de construção que estão nas fábricas). Com isto o nosso modelo é por definição, completamente anêmico. Nossos objetos são somente POCO e todas as regras estão sempre localizadas nos serviços. Apesar de alguns acharem isto extremo, no meu caso eu tenho tido muito sucesso trabalhando desta forma. Quando se tenta colocar regras em objetos, muitas vezes há a dúvida de se uma regra pertence a uma ou outra classe. Com o tempo, ninguém sabe onde está o que. Além disto, fica muito mais difícil trabalhar com AOP desta forma, pois em caso de um objeto chamar outro, fica difícil definir de quem é a responsabilidade e controlar transações, segurança, erros etc. Da maneira como eu faço, que é tudo na camada de serviços, ninguém nunca tem duvida de onde procurar uma regra, todos os aspectos estão lá e a manutenção do sistema é super tranqüila. Tenho sistemas de mais de 10 anos (com objetos ainda em C++!) onde continua sendo fácil mesmo pra quem não conhece, de identificar e alterar regras de negócio.

Assim, na nossa implementação, temos um repositório e uma fábrica para cada entidade de negócio (que por sua vez representa uma tabela). E os serviços são criados conforme necessário, onde cada regra é stateless e completamente procedural. Puristas falam que isto não é DDD. Pode ser. Mas é muito produtivo!

Para gerar serviços e repositórios, utilizamos arquivos de template (.TT) do visual studio. Eles utilizam a definição gerada pelo AW e automaticamente já constroem todos os repositórios, fábricas, operadores e demais artefatos de auxílio. Ou seja, ao arrastar graficamente uma tabela para o nosso diagrama AW, todos os artefatos mínimos para uso da entidade já estão prontos! Claro que iremos expandir os repositórios e fábricas com novos métodos e isto é feito através de classes parciais. Todos os repositórios, fábricas e serviços são implementados através de um container IoC, o Castle Windsor. Com isto uma troca futura de qualquer destes componentes é super simples – p. ex., a única dependência para NH que temos são as implementações de repositórios. Tudo fica em um único assembly que chamamos de assembly de domínio.

Finalmente, temos algumas classes estáticas de apoio como, por exemplo, uma com todos os nomes de propriedades de todas as entidades, outra com um acesso rápido para repositórios e fábricas e uma com todos os serviços do projeto. Outra classe muito útil é a de geração de consultas. Em repositórios, as consultas podem ser feitas via HQL do NH ou via consulta direta. Como a maior parte das consultas é simples, elas são feitas por critérios diretos e pra isto utilizamos uma interface fluente para ajudar a escrever. Exemplo:

return Query.Where(Restrictions.Eq(PN.User, user)).And(Restrictions.IsNotNull(PN.ClosedOn)).Count();

A consulta é feita para uma entidade chamada “Incident” e retorna o total aberto para um usuário. Query é a classe de apoio de consulta e PN são os nomes de propriedades – usamos isto para evitar strings e com isto minimizar o número de erros de digitação.

Estou muito satisfeito com a qualidade e a produtividade gerada pela nossa camada atual de domínio. Fazer e dar manutenção em objetos é algo que para nós é super simples e podemos nos dedicar e escrever regras de negócio e interface. O próximo post vai ser sobre a camada de interface.

, , , , , , ,

2 Comentários

Produtividade – Princípios

Continuando a série sobre produtividade, e antes de entrar em detalhes da nossa plataforma atual, vou relacionar alguns princípios que utilizo quando o assunto é produtividade.

  1. Uso de tecnologia de ponta – como citado no post anterior, eu acredito que a incorporação de uma nova tecnologia ou framework só deve ser feita quando há um ganho claro mensurável. Nossa indústria muda muito rapidamente e muitas frentes às vezes aclamadas como excelentes práticas podem cair em desuso daqui a alguns meses. Isto posto, é fundamental estar atualizado, pois a todo tempo surgem soluções ou práticas que definitivamente podem gerar ganhos de produtividade. Eu me considero um dos últimos dos “early-adopters”, ou seja, nossa plataforma usualmente tem quase tudo que é de ponta, porém normalmente não sou um dos primeiros a adotar uma determinada novidade.
  2. Dogmatismos e guerras religiosas – Na nossa indústria é muito comum encontrar pessoas que defendem práticas ou teorias simplesmente por elas terem sido definidas, não importando que finalidade ou benefício possa advir do uso delas. Minha visão sobre isto não poderia ser mais pragmática, acredito que temos que conhecer muito bem a teoria e os conceitos envolvidos, porém o uso é condicionado ao ganho que possa ser obtido. Mesmo que isto signifique “deturpar” uma teoria ou usar somente uma parte dela. Nosso negócio não é o purismo e sim a produtividade, portanto, pra mim, não há espaço para dogmatismos. Tenho vários exemplos sobre este tema. Um muito comum é sobre “modelos anêmicos”, que tentam fazer um purismo OO quando, na minha experiência, isto causa mais problemas do que ajuda (mais sobre isto no post da camada de domínio). Não tenho nenhum problema em ter uma visão procedural de serviços, se desta forma estamos sendo mais produtivos. Outra é sobre uso de “patterns” conhecidos. Muitas pessoas ficam olhando um problema e tentando identificar e classificar aquilo em um pattern quando algumas poucas linhas de código já poderiam ter resolvido o problema há muito tempo. Quanto mais patterns conhecermos melhor, mas se usar não é intuitivo, algo provavelmente não está certo.
  3. Complexidade – Desenvolver sistemas significa fazer tarefas complexas. Mas para mim, a complexidade deve estar sempre que possível escondida das tarefas do dia a dia. Por exemplo, um framework de domínio vai ter áreas muito complicadas para se projetar e construir. No entanto, usar um framework de domínio deve ser algo simples. A todo o tempo eu avalio o esforço para se esconder as complexidades de tarefas comuns e quando há um potencial, isto é feito. Claro que a tarefa tem que ser comum o suficiente para compensar o esforço de encapsulamento; não faz sentido fazer um framework para uma tela que será desenvolvida uma única vez. CRUDs são usualmente candidatos a usar frameworks, pois todos os sistemas possuem várias telas deste tipo. Um corolário disto é que se for possível automatizar algo com o uso de DSLs, eu vou considerar esta opção de maneira muito favorável. DSLs tornam as tarefas do dia a dia mais simples, então pra mim isto significa produtividade direta. Infelizmente fazer uma DSL ainda é algo muito complexo, e utilizar uma pronta que não tenha nenhuma área de conflito é raro – se ela não se encaixar bem, não vai ser produtivo usar. Um exemplo muito bem sucedido na nossa equipe é o ActiveWriter, que é uma DSL para se gerar entidades de domínio. Atualmente nossa plataforma de domínio está tão boa que nossos desenvolvedores quase que esquecem que ela está lá, trabalhando com uma interface gráfica para desenhar entidades e gerando a maior parte do código com geradores automáticos. Outros exemplos nesta linha são o uso de interfaces fluentes, operadores customizados e assim por diante.
  4. Manutenabilidade – Este é um conceito sujeito a muitas guerras religiosas. Para muitos desenvolvedores, a busca da uma manutenabilidade máxima é o objetivo final, mesmo que isto não seja necessário. Na minha visão, a manutenabilidade de um sistema moderno está ligada a duas áreas: facilidade de alterar interfaces e facilidade de entender e identificar as regras de negócio. As demais áreas complexas (frameworks, camadas de domínio etc.) serão complexas, não importa quão bem feitas sejam. Então não adianta tentar deixá-las super simples de dar manutenção; se a equipe que as projetou não estiver disponível, vai ser difícil alterar. Claro que boas práticas de programação devem ser usadas nestas áreas, mas daí a tentar fazer algo universalmente simples pode ser um esforço inviável. No meu caso, eu me preocupo com telas e regras de negócio. Em termos de regras, temos tido bastante sucesso, hoje temos sistemas legados de quase 10 anos que ainda são simples de ter regras de negócio alteradas. Telas são um pouco mais complexas, pois a tecnologia mudou muito nos últimos anos, mas mesmo assim temos tido um razoável sucesso. Mais sobre isto no post referente a interfaces.
  5. Linguagens Declarativas – Outro tema polêmico, linguagens declarativas são linguagens que se propões a dizer o que deve ser feito ao invés de como deve ser feito. Exemplos são linguagens como SQL ou XSLT e qualquer outra DSL. Na minha visão, este é um dos maiores fatores de produtividade, pra mim linguagens declarativas SEMPRE são ordens de grandeza mais produtivas do que linguagens imperativas (C# etc.). Assim, no nosso caso, muitas extrações são feitas em SQL direto. Ultimamente HQL também tem sido uma excelente opção. (Obs.: não acho que regras de negócio devam estar em stored procedures, já que regras de negócio são procedurais e portanto, imperativas por natureza). E no nosso caso, o uso de XSLT é prevalente nas interfaces. Apesar de ter uma curva de aprendizado significativa, a minha opinião é que o esforço para aprender XSLT é sempre é retornado muitas vezes em produtividade – mais sobre isto no post sobre interfaces.
  6. Perfil da Equipe – Por último, um tópico que foi abordado no post anterior. Minha opinião é de que ter pessoas inexperientes vai afetar negativamente a produtividade, em qualquer cenário. Como visto nos itens acima, trabalhamos com todas as tecnologias de ponta, o que significa uma grande formação básica necessária. Na nossa equipe é muito raro um novo membro, por mais experiente que seja, não ter um tempo de adaptação de um ou dois meses. Para desenvolvedores inexperientes, este tempo seria muito maior, afetando de maneira drástica a produtividade geral da equipe. Este é um grande problema pois profissionais bons são raros, e uma troca de pessoal freqüente também afeta de maneira significativa a produtividade. Não vejo solução para isto, o que faço atualmente é ter pessoas chaves liderando as equipes que possam absorver eventuais necessidades por troca de pessoal, mas esta troca inevitavelmente vai diminuir a produtividade.

O próximo post é sobre a camada de dados de de domínio. Até breve.

, , , , , , , , ,

Deixe um comentário

Produtividade – Introdução

Durante toda minha carreira a busca da produtividade no desenvolvimento de software tem sido uma constante. Afinal, desenvolver software de qualidade em pouco tempo é o objetivo de todo desenvolvedor.

A busca pela produtividade começa lá na faculdade, quando aprendemos Orientação à Objeto. A promessa de reuso de classes cria a idéia de que a programação OO já é naturalmente mais produtiva. E conforme vamos evoluindo, passamos a conhecer frameworks, plataformas e até geradores de sistemas, todos com a promessa de ser o holly grail de produtividade. Some-se a isto a idéia de que processos podem ajudar no sentido de que tarefas simples possam ser executadas por pessoas inexperientes, todas contribuindo para fazer software bom e rápido, e temos o cenário atual da indústria de desenvolvimento de software.

Depois de alguns anos a gente começa a separar o joio do trigo e ver que esta questão é extremamente complexa, muito mais do que conseguimos perceber no início da nossa carreira. Tecnologia ajuda, mas de maneira nenhuma garante produtividade (muitas vezes, é o contrário). Processos idem, muitas vezes geram mais tempo perdido do que economizam. Esta série é sobre minha visão atual a respeito de produtividade, minha e da minha equipe. De maneira nenhuma acho que esta é uma receita universal que possa ser aplicada a qualquer time. Muito ao contrário, acho que cada time tem características e pontos fortes que serão mais expressivos com determinado conjunto de ferramentas e processos.

É importante notar que em todos os itens a minha visão é muito pragmática. Conhecer teoria é importante, mas ela evolui e conceitos de hoje podem não ser os de amanhã. Assim para eu usar algo, eu tenho que perceber um ganho imediato, nos desenvolvimentos sendo realizados. Usar tecnologias ou processos porque alguém diz que é legal ou pela promessa de um dia gerar algum ganho não é algo que eu faço. Mas, é claro que é muito importante estar atualizado. Por exemplo, esta semana estou adaptando a nossa infra-estrutura para usar um tipo de validação baseado em jQuery que me foi recomendada por um membro da equipe e que faz todo o sentido e vai gerar produtividade hoje.

Assim, em uma série de posts, vou descrever o que eu adoto como infra-estrutura para as aplicações desenvolvidas pela nossa equipe e minha opinião sobre a razão para usar e como estão sendo utilizadas. Ao final, um post sobre o nosso estágio atual e o que ainda estamos sentido falta.

Uma conclusão, no entanto, é clara para mim. O desenvolvimento de aplicações de médio ou grande porte é muito complexo – e não sei se um dia vai se tornar simples. Ser produtivo implica em utilizar uma série de tecnologias e conceitos que não são fáceis de aprender. Assim, não é possível ter gente inexperiente e ser produtivo ao mesmo tempo. Isto é assunto para um post específico também, mas adiantando, não acredito que haja, no desenvolvimento de sistemas, tarefas simples o suficiente para ocupar pessoas inexperientes por completo. No mínimo, uma grande supervisão é necessária, o que por si só já diminui a produtividade. Claro que treinar é necessário, mas hoje eu separo muito bem o trabalho de produção do de treinamento. Se há treinamento envolvido, a produtividade vai cair, sempre. Isto parece óbvio, mas foram muitos anos até que esta conclusão fosse assimilada.

O próximo post é sobre princípios gerais de produtividade que eu aplico.

, , , , ,

Deixe um comentário