negocios « Fragmental

Archive for the ‘negocios’ Category

Trilha de Livros: Desenvolvedor

Tuesday, May 20th, 2008

Esta então é a prometida lista de livros para desenvolvedores. Claro que não é nenhuma lista exclusiva ou “o guia definitivo”, apenas minha recomendação de leitura, partindo do principio que você já sabe programar em uma linguagem como Ruby, C# ou Java.

Este guia é bem genérico, sem tentar se especializar em nada e sem tentar abranger mais que o mínimo necessário. Espere modificações nesta lista.

Operating Systems: Design and Implementation: Este ode não ser o melhor livro sobre Sistemas operacionais –ou pelo menos não o mais didático- mas eu gosto bastante. A maioria dos conceitos básicos de um Sistema Operacional está presente mesmo nas máquinas virtuais e seja como for, antes de abstrair você precisa entender como seu computador funciona. Claro que se você cursou SO na faculdade e, principalmente, se lembra de como memória virtual, filesystems e demais funcionam pode passar por este item –eu acho que uns 5% dos desenvolvedores que conheço se enquadram nisso, entretanto.
Fundamentals of Object-Oriented Design in UML: Este livro ensina métricas e princípios básicos para desenvolvimento de sistemas Orientados a Objetos. Se você passou por projeto estruturado provavelmente conhece o autor e algumas de suas métricas.
Head First Design Patterns: Uma introdução suave aos Design Patterns. A vantagem em começar com este ao invés do clássico (que é o próximo na lista de qualquer modo) é que você não tem que lidar logo de cara com Smalltalk e C++. Aprender um conceito não-tão-simples quanto Design Patterns enquanto tenta entender uma sintaxe fora do dia-a-dia é criar complexidade acidental.
Design Patterns: Elements of Reusable Object-Oriented Software: Apesar de não ser indicado ao iniciante eu não acredito que voc6e consiga ir muito longe sem ler este livro. Pelo menos as narrativas são fundamentais para entender as motivações e a evolução do conceito de patterns. A falta desta leitura faz com que pessoas cometam erros grotescos.
Agile Software Development, Principles, Patterns, and Practices: (em versão Java ou .Net) este livro traz uma visão bem pratica sobre alguns aspectos mais teóricos da Orientação a Objetos. Como u organizo pacotes? Qual o problema em ter dependências e como me livro delas? Devo sempre retornar null? O que significa herança na pratica?
Refactoring: Improving the Design of Existing Code: Conforme você for entendendo mais sobre design de software vai sentir uma vontade enlouquecedora de apagar todo o seu sistema e começar de novo. Antes de sair por aí cometendo carreiracídio leia este livro, ele vai te ensinar a fazer pequenas mudanças que melhoram a qualidade do sistema e identificar código que fede.
Patterns of Enterprise Application Architecture: A maioria dos patterns que você teve contato até aqui tratam de design em um nível micro. Como classes interagem, como elas colaboram e como gerenciar seus problemas. Este livro, entretanto, fala sobre padrões em um contexto mais amplo, sobre arquitetura de software.
Domain Driven Design: Os livros até então falam de sotware pelo software. Como criar uma classe, como gerenciar dependências entre classes… mas ninguém te mostrou o que deve ser uma classe e o que não deve. Eric Evans supre esta demanda mostrando uma abordagem simples e eficiente para criar domínios que se aproximam do mundo real.
POJOs in Action e/ou Applying Domain-Driven Design and Patterns: With Examples in C# and .NET: É normal que exista uma certa dificuldade em levar estes conceitos para o dia-a-dia. Estes livros não são indispensáveis mas eles ajudam bastante a entender como aplicar conceitos, ainda que algumas vezes de maneira “não canônica” mas ainda assim eficaz.
The Pragmatic Programmer: From Journeyman to Master: Infelizmente muitas vezes, especialmente em consultorias de três letrinhas e faculdades McDonald’s, não temos um ambiente sadio para nos ensinar como programadores profissionais se comportam. Este genial livro traz uma boa parcela deste conhecimento condensado. Eu adicionaria o The Art of UNIX Programming, especialmente para aqueles que vêm de uma cultura drag’n'drop para o mundo real
Ship it! A Practical Guide to Successful Software Projects Este livro é bem interessante para entender como um desenvolvedor utiliza ferramentas simples como controle de versão e issue tracker. Ótimo par aquém está profissionalizando uma empresa.
Agile and Iterative Development: A Manager’s Guide Antes de você se dedicar a estudar mais uma metodologia de desenvolvimento em específico uma boa idéia é ler este livro, que traz um apanhado de diversas metodologias e as compara.

Posted in Uncategorized, gerencia, metodologias, negocios, palestras, rest, ws-*/soap | 27 Comments »

Propostas de Trilha

Thursday, April 3rd, 2008

Recebi este e-mail esses dias (nome oculto por falta de permissão do autor):

[...]

Eu trabalho com Java a pouco tempo (desde maio de 2006), mas sempre procurei aprender bastante. Na época eu não conhecia nada, [...] não sabia Java a fundo[...] comecei num projeto que já tinha essa arquitetura de usar TO, BO, etc. e tal, e a partir dele comecei a aprender e abstrair, com isso acabei criando umas coisas que depois viraram o “framework das arquiteturas” da empresa, framework que segue aquela porcaria de lógica de negócio separado de dados. Não trabalho mais nessa empresa, e meu antigo analista me fala com orgulho que aquele framework que fiz já é base para 5 projetos, me deixa feliz e ao mesmo tempo preocupado. Hoje estou em outra, e faltamente com a responsabilidade de novo de definir a arquitetura dos projetos (não acho que tenha experiência suficiente
para isso, mas eu tento estudar ao Maximo e fazer o melhor), e dessa vez, o negócio é grande, pois a empresa é infinitamente maior.

Lendo as várias discussões que vocês têm no GUJ, bem como seu blog, eu tenho certeza que aquele framework era errado. Quando criei, ainda era dependente de tecnologias, muita coisa mudou, e no fim não era mais dependente de nenhum framework especifico, ele continha uns utilitários, as interfaces e algumas abstrações para serem implementadas e especializadas em cada projeto, mesmo assim não
consegui juntar os dados com a lógica.

Bem, juntar eu até consigo, mas ai não consigo mais imaginar um framework, perfeito, vocês falam que esse framework é, teoricamente, uma coisa ruim. Porem morrendo esse cara, todos meus programadores terão de programar o modelo sempre do zero, bem como saber programar
da forma certa (o que acredite em mim, acho que 80% das pessoas não fazem noção nem do que é a forma certa, quem dirá fazer, eu posso ser uma delas, mas pelo menos tenho noção de que da forma que esta feito, é errado), ai que volto a pensar em ter um framework para eles
estenderem e não precisarem se preocupar com tanta coisa.

Ai surgem minhas duvidas, para mim, seguir os conceitos de DSL, DDD, Fluent Interfaces etc. é algo que exige do programador um bom conhecimento, e eu não tenho muita experiência com bons programadores, a maioria se quer sabe a importância de uma interface, programa em
Java como se estivesse programando em C, como cobrar desses caras uns conceitos que nem eu entendo a fundo, ai volto a pensar naquele framework, que ao menos obriga eles seguirem algo dividido em camadas, fazendo eles separar a lógica de negocio do acesso aos dados, a lógica de negocio de cliente da lógica de negocio de fornecedor, enfim, consigo que pelo menos saia algo não tão feio, e que em eventuais manutenções consigo fazer de forma rápida.

Mas para mim isso é péssimo, porque não consigo evoluir, não consigo aplicar nos projetos as coisas que gostaria de aprender. Mas acho que a culpa é minha, porque em todo lugar tem programadores que devem não conhecer, e isso não pode ser um impeditivo.

Por isso, gostaria muito que você me indicasse livros, mas que seguisse uma ordem certa de aprendizado, o que eu preciso saber primeiro, depois e depois, eu não sei se eu devo começar lendo sobre a modelagem em si, ou conceitos DDD, DSL, sei la, queria apenas que você me guia-se recomendando links e principalmente livros.

Por exemplo, nesse tópico você deu exemplo de vários livros http://guj.com.br/posts/list/60/71466.java (na pagina 5 do tópico), qual seria o mais recomendado para iniciar, e depois, depois etc. [...]

Antes de mais nada eu diria que você está na trilha certa. A primeira coisa que um bom arquiteto deve fazer é se questionar o tempo todo, e justificar suas escolhas para si mesmo antes mesmo de alguém falar qualquer coisa.

Uma coisa que você precisa ter em mente é que o framework perfeito não existe. Quando discutimos design muitas vezes focamos no ideal, mas nem sempre o ideal deve ser implementado. Dificuldades tecnológicas são um grande fator, mas como você mesmo notou um fator muito importante é que arquitetura é sobre pessoas. Não adianta você ter a arquitetura tecnologicamente, perfeita, o design que melhor modela seu domínio e a maior performance possível se seus desenvolvedores não entendem ou não entenderão este zoológico.

Eu fui freelancer por um bom tempo, e nesse período não só eu era completamente verde sobre tecnologias bem como na época o acesso à informação era restrito (Internet só depois da meia-noite, lembra do pulso único?). Ainda assim eu tive que definir arquiteturas para alguns sistemas que duram até hoje, e aprendi bastante com isso.

Uma das coisas que aprendi é um clichê: Keep it Simple. Uma boa arquitetura, sofisticada ou não, é composta de primitivas arquiteturais bem definidas. Para entender essa afirmação pense na linguagem Java. A linguagem possui primitivas que giram em torno de objetos, definidos por classes que trocam mensagens através de métodos. Você não precisa de exceções à estas primitivas, consegue implementar tudo no seu sistema com elas. Assim deve ser sua arquitetura.

Se você ainda não tem conhecimento para utilizar conceitos mais rebuscados se mantenha simples e elegante -e elegante para mim significa ter boas primitivas e pouquíssimas exceções. Claro que sua arquitetura não vai servir para todas as coisas mas lembre-se que arquiteturas devem ser pensadas de acordo com o projeto, não existe arquitetura de referência.

Mas se eu não tenho uma arquitetura de referencia como confio nos meus desenvolvedores? Primeiro você deve contratar desenvolvedores bons, ou experientes ou com um bom potencial. Como falei diversas vezes neste blog entre 2005 e 2007 uns bons 40% do meu tempo foi dedicado contratando gente. O que eu aprendi nessa fase é que os bons desenvolvedores dificilmente vão caber no seu orçamento. Eles já são superstars em outras empresas. O que você precisa fazer é criar um time de pessoas eficientes, compromissadas e competentes. Este tipo de pessoa pode não ter a bagagem técnica necessária mas possui um potencial tão grande que você cria seus próprios superstars.

Mas se você não está contratando ninguém, como fica? Então você precisa é de gerencia de conhecimento. Muitas vezes eu já entrei num projeto onde as pessoas repetiam um mantra qualquer como “Não podemos fazer isso porque vai dar conflito com a rebimboca” o tempo todo e quando você pergunta ninguém consegue te explicar direito o que é a tal rebimboca ou porque ela cisma de conflitar com seu software.

Pense no seguinte: se as pessoas fossem ler por si só livros e bibliografias complicadas elas já teriam feito isso por elas mesmas. Se elas não procuraram para ter sucesso profissional elas não vão procurar apenas para entender seu software.

Criou uma arquitetura nova? Crie uma página no wiki da empresa (ou na Intranet, ou sei lá) contendo a descrição do que vocês fizeram. Não pense numa especificação de arquitetura, pense que você está escrevendo um artigo para um grande site sobre a arquitetura. O objetivo é criar algo útil e informativo. Organize sessões onde as pessoas troquem conhecimentos, talvez através de palestras ou de lighting talks ao menos duas vezes por mês.

E quanto aos livros? Recomendar livros depende muito do que você quer aprender. Eu não vou recomendar os livros neste post, vou tentar fazer algo mais abrangente e criar uma serie de posts chamados Proposta de Trilha. Eles vão conter uma bibliografia que eu ache interessante e na ordem que eu gostaria ter seguido. Imagino posts específicos para: Desenvolvedor, Arquiteto, Testador e Gerente de Projeto. Talvez mais, talvez menos.

Posted in Uncategorized, arquitetura, cbd, gerencia, metodologias, negocios, rest, ws-*/soap | 7 Comments »

Labirinto

Thursday, March 27th, 2008

A quantidade de dados disponível na Internet é algo interessante e quando temos a ferramenta certa algumas realidades são tão claras que chegam a ser constrangedoras. Para mim a rede social mais relevante hoje é o Linkedin. Apesar de haverem centenas de desesperados para arrumar um emprego e ganhar recomendações sem merecer é m sistema bem feitinho e de uma empresa que parece ter o pé no chão: nada de criar o novo Facebook, foco foco foco!

Bem, dia desses eu vi que eles lançaram páginas das empresas. Além de uma interação redondinha com a BusinessWeek o perfil da empresa possui diversos dados extraídos dos perfis dos seus funcionários e, como a experiência de trabalhar com alto volume de dados e acessos me mostrou, isso não é nada fácil.

Mas aí vem a parte engraçada. Pegue a página de uma empresa de três letrinhas qualquer. Veja o box “Related Companies” e perceba a quantidade de empresas de três letrinhas dos dois lados (antes de entrar na empresa, depois de sair). Agora clique em uma empresa de três letrinhas da lista. Tente achar uma delas que não tenha uma empresa de três letrinhas como “after”.

É óbvio que isso não é nenhum dado científico mas mostra a realidade que quem trabalha nessas empresas vive -falo isso de conhecimento próprio. A coisa mais comum para o desenvolvedor de sistemas no Brasil é viver entre consultorias, você fica um pouco em uma, recebe uma proposta melhor, vai para outra, tira um certificado, volta pra anterior, quer ganhar mais, muda de novo. Sair deste ciclo não é fácil, exige sorte e/ou muita vontade. Não é fácil arrumar um bom lugar para se trabalhar e ainda ganhar a mesma coisa, mas existe. Na verdade eu percebo que tirando poucas exceções a maioria das pessoas com nível técnico bom que eu conheço ou não estão mais neste ciclo ou estão saindo dele.

Existe uma onda de pessoas que estão indo trabalhar com produtos, fazer consultoria por conta própria ou abrir sua própria startup. Isso é ótimo, quebra o paradigma infeliz de que para um técnico ter uma carreira de sucesso e;e deve sair da área.

Aqui em Melbourne -e imagino que na Australia toda- existe um saudável mercado de pequenas consultorias. São empresas pequenas, de umas dez pessoas, que conseguem competir nesse mercado tão cheio de absurdos. Infelizmente no Brasil isso é meio impossível -e dá para entender o Viícius-, as consultorias ganham contratos na base do… bom, vocês são brasileiros e sabem do que eu estou falando. Aqui existem as grandes também, Melbourne é um centro mundial, mas ainda que as pequenas estejam longe das contas megalomaníacas elas conseguem se virar com empresas que precisam de resultado de verdade, e não apenas encher uma sala de gente que finge que desenvolve.

Afinal, quantas permutações você consegue fazer com três letrinhas?

Posted in australia, comunidade, gerencia, metodologias, negocios, thoughtworks, web | 3 Comments »

Ainda bem que estou aqui

Friday, March 21st, 2008

Morar num pais distante é uma experiência diferente para cada um. Uma das coisas que estão bem claras para mim é que eu não estou fugindo do Brasil, estou apenas experimentando algo novo para ver como me sinto. No final deste experimento eu posso decidir ficar, voltar ou ir para outro lugar.

Esses dias eu pela primeira vez falei “ainda bem que não estou no Brasil”. A causa? A classe política brasileira que teima em se meter no que não entende.

A ACM é uma das mais respeitáveis organizações do mundo da tecnologia, uma referencia para toda a indústria. Há anos a organização estuda a possibilidade de aplicar licenciamento e regulamentação na área. A conclusão está neste documento, que diz:

From 1993 through June 2000 ACM worked with the IEEE Computer Society on projects to examine and guide the evolution of software engineering as a profession. This work was originally carried out under the Joint IEEE-CS and ACM Steering Committee for the Establishment of Software Engineering as a Profession. In 1998 the joint committee was superceded by the Software Engineering Coordinating Committee (SWECC) established by IEEE-CS and ACM to act as a “permanent entity to foster the evolution of software engineering as a professional computing discipline.” Under these efforts projects were launched to identify a software engineering body of knowledge (SWEBOK); develop curriculum recommendations for software engineering; and define a code of professional ethics and standards of professional conduct.

At the time SWECC was being established, the ACM and IEEE-CS received a request from the Texas Professional Engineers Licensing Board for help in defining performance criteria for software engineering licensing exams to be administered in Texas. As a result of this request, the question of licensing software engineers became more of an issue both for SWECC and for ACM. In March 1999 an ACM Advisory Panel on Professional Licensing in Software Engineering was established to make recommendations to ACM Council on the issue. After reviewing and discussing the advisory panel’s report (www.acm.org/serving/se_policy/report.html), ACM Council passed the following motion in May 1999:

“ACM is opposed to the licensing of software engineers at this time because ACM believes it is premature and would not be effective at addressing the problems of software quality and reliability.

“ACM is, however, committed to solving the software quality problem by promoting research and development, by developing a core body of knowledge for software engineering, and by identifying standards of practice.”

Over the next 12 months work continued on the SWEBOK project and other SWECC activities. In addition, ACM Council established two additional task forces: one to evaluate the SWEBOK effort; and the other to determine ways in which ACM and the profession might improve the robustness and quality of safety-critical software and evaluate licensing activities in this context.

After reviewing the reports of these two task forces, there was growing concern by ACM Council that supporting the request of the Texas Professional Engineers Licensing Board was becoming more the primary focus of SWECC’s efforts. As a result, ACM Council passed the following motion in June 2000:

“Society is becoming increasingly dependent on computers and software, which creates tremendous challenges and responsibilities for computing professionals. ACM Council believes that confronting these challenges will require creative and collaborative efforts by industry, universities, professional societies, and government. ACM Council strongly supports the idea of the ACM and the IEEE Computing Society working together on these challenges, including joint initiatives to promote the emergence of information technology professions.

“However, ACM Council believes that the current efforts of the Software Engineering Coordinating Committee (SWECC) toward licensing is misguided as they assume that software engineering is a profession appropriate for licensing under the rubric of the Professional Engineers Licensing structure and requirements. Moreover, ACM Council feels that further efforts in this direction will detract from our ability to take other more practical and productive initiatives needed to meet our common goals.

“Accordingly, Council directs that ACM withdraw from SWECC.”

Understanding the ACM Position

Why did ACM withdraw from SWECC? ACM Council felt the activities of SWECC had become too closely associated with promoting the licensing of software engineers as Professional Engineers (PEs).

Is ACM against licensing software engineers? Yes. For legal reasons, the only way to be a licensed software engineer is to become a PE. As described in the Safety-Critical report (see www.acm.org/serving/ se_policy/safety_critical.pdf), several topics on which all prospective PEs are tested, such as fluid mechanics and thermodynamics, are beyond the scope of software engineering. Mastering these topics could detract from the study of more relevant areas.

In addition, a software engineering license would be interpreted as an authoritative statement that the licensed engineer is capable of producing software systems of consistent reliability, dependability, and usability. The ACM Council concluded that our state of knowledge and practice is too immature to give such assurances.

Is ACM against software engineering being viewed as a profession? No. ACM believes it is important to foster the emergence of a true IT profession, not just software engineering. A field does not need licensing to be a profession.

Does ACM see a difference between licensing and certification? Yes. Certification is a statement by a recognized authority that a person is competent in an area. Licensing, by contrast, is regulated in the U.S. by legislation at the state level. With few exceptions, a PE in a profession for which licensing is required must be licensed in every state in which he or she practices.

Will ACM continue its efforts to improve the quality of software? Absolutely. ACM believes the problem of reliable and dependable software, especially in critical applications, is the most important problem facing the IT profession.

A Sociedade Brasileira de Computação (SBC) é outro organismo importante na indústria. Ela também já flertou com a regulamentação mas possui a seguinte opinião:

A comunidade científica da computação brasileira vem discutindo a questão da regulamentação da profissão de Informática desde antes da criação da SBC em 1978.

Fruto dos debates ocorridos ao longo dos anos, nos diversos encontros de sua comunidade científica, em relação às vantagens e desvantagens de uma regulamentação da profissão de informática, a SBC consolidou sua posição institucional em relação a esta questão pela formulação dos seguintes princípios, que deveriam ser observados em uma eventual regulamentação da profissão:

1. Exercício da profissão de Informática deve ser livre e independer de diploma ou comprovação de educação formal.
2. Nenhum conselho de profissão pode criar qualquer impedimento ou restrição ao princípio acima.
3. A área deve ser Auto-Regulada.

Os argumentos levantado junto à comunidade da SBC e que nortearam a formulação dos princípios acima estão detalhados na Justificação que acompanha o PL 1561/2003, o qual é integralmente apoiado pela Sociedade de Computação.

O livro Software Craftmanship, de Pete McBreen, possui um capítulo chamado “Licensing is an Illusion”, de onde eu cito:

Licensing Is an Attempt to Solve the Wrong Problem

Licensing works for engineering because one licensed engineer can certify that something using accepted best practices has been built. The same is not possible with software. Certification can be applied to buildings and other mechanical structures because they involve standard materials and designs with well-known properties. They are also a lot less complex than software. Most engineering designs have very few parts. For example, cars typically have fewer than 15,000 parts and fewer than 5,000 unique part numbers. By comparison, this book contains about 50,000 words, and the space shuttle software contains approximately 420,000 lines of code.

Cars are interesting because they are so complex that it is not cost-effective to have licensed engineers certify that they are built correctly. As the J.D. Power and Associates 2000 Vehicle Dependability Study reported, even the best cars average more than two defects per vehicle. Some cars have serious design defects that require a complete safety recall, attesting to the fact that even the design is incorrect. Tellingly for the engineering profession, auto manufacturers rarely acknowledge a problem until they have a fix available.

In software, the problems are even harder. Even with multiple reviews and copyediting, most books contain a few typos or mistakes. Now imagine the problem that a licensed software engineer would face when asked to sign off on the space shuttle software. An individual could not sign it off as correct. Even if a person spent an entire career at that one task, she could never sign it off as correct because the software is too large and complex for any one individual to be able to guarantee that there are no mistakes. The concept of a single, responsible engineer signing off the complete work is not feasible for software.

The key problem is that licensing assumes that it is possible to inspect quality into a product. This approach is the wrong way to improve quality, and even the manufacturing world has shifted away from this concept.[41] As quality pioneer W. Edwards Deming stated, one of the key responsibilities of management is to cease dependence on mass inspection and testing: much better to improve the process in the first place so you don’t produce so many defective items, or none at all.

Eu pergunto se o senador Eduardo Azeredo tem respostas para estes questionamentos. Pergunto se ele e os envolvidos e apoiadores deste grande erro sequer sabem que existe um mundo todo aqui fora e que o Brasil não é o primeiro a passar por este questionamento. Pergunto se eles sabem que nenhum pais minimamente relevante na área de Tecnologia da Informação, desde os desenvolvidos até nossos colegas de BRIC impõe uma lei absurda dessas.

Mas nós sabemos como o Brasil funciona (funciona?) e que essa lei não vai causar nada alem de transtornos leves. Não posso mais chamar a pessoa de Analista de Sistemas (que aliás é algo que nem existe mais hoje em dia) mas podemos continuar tudo como sempre foi.

A diferença, é claro, é que mais e mais pessoas vão entrar em instituições de ensino de péssima qualidade apenas para ter o diploma que dá direito ao exercício de uma profissão que não existe. E eu pergunto: a quem esta lei beneficia mesmo? Os profissionais ou os donos de faculdades McDonald’s?

Posted in comunidade, engenharia, gerencia, negocios, programando | 18 Comments »

Programação RADioativa

Sunday, January 20th, 2008

Há alguns anos, quando era consultor independente, eu fui chamado por uma empresa bem grandinha do ramo de telefonia. Eles tinham produtos em C++ e queriam migrar para o Java. Na verdade já haviam migrado, mas estavam com problemas.

A primeira tentativa deles foi transferir toda a parte gerencial do sistema -que era vendido por alguns milhões de Euros- para Java. Para fazer esta etapa eles haviam contratado há um ano uma consultoria especializada canadense. Os canadenses sugeriram a compra de uma ferramenta RAD -por um acaso de outra empresa canadense- que permitiria que os desenvolvedores C++ criassem a aplicação em pouco tempo. Em três meses, tempo recorde, a aplicação já estava rodando no cliente, em produção. Durante os testes eles verificaram que a coisa era muito lenta mas como o mercado de telefonia tem muito dinheiro eles simplesmente aumentaram o número de máquinas.

A coisa foi passando até que alguém foi fazer a primeira manutenção. O sistema era um grande catálogo de assinantes, dependentes e registros de ligação, as regras pesadas mesmo ficavam no sistema em C++. As primeiras manutenções foram correção de bugs. A ferramenta funcionava dentro do Eclipse, você definia um modelo de entidades parecido com o modelo relacional, depois dizia quais operações precisava (criar, ler, listar, etc.), isso gerava o código. Se você precisasse de uma regrinha de negócio diferente, digamos que cada vez que um novo cliente fosse adicionado alguém recebesse um email, ia ter que alterar o código gerado. Como a aplicação -como todas- tinha suas peculiaridades muito código era escrito a mão. Mesmo assim o ato de criar toda a infra-estrutura (o scaffolding) poupava muito tempo.

Qual não foi a surpresa quando alguém reparou que a ferramenta só gerava código, ela não o lia de volta? Se você alterar o código e fizer alguma alteração o fornecedor deu duas escolhas:

Alterar o código usando a ferramenta gráfica, regerar o código e depois adicionar novamente nossas alterações
Abandonar a ferramenta e fazer tudo no código

Neste ponto que eu fui chamado. O fornecedor sugeria fortemente a segunda opção, por incrível que pareça. Eu concordei com eles, recomendei ao cliente que assumisse o prejuízo de ter escolhido uma ferramenta ruim e refatorasse o sistema enquanto inseria novas funcionalidades.

O mundo adora ferramentas RAD. Elas provocam a ilusão de que você não precisa de conhecimento ou de um profissional para criar programas. Não é assim que a banda toca.

Essas ferramentas surgem todos os anos. Todos se dizem revolucionários, quase nenhum diz que é um gerador de código, e todos dizem que servem para 87% dos casos. Puro marketing.

Geradores deste tipo existem há décadas. É até engraçado que o mais novo representante desta leva se gabe de ‘revolucionar’ usando o conceito de programação visual por fluxograma. Ahm? Isso existe praticamente desde que surgiram IDEs gráficas. Qualquer coisa que gere código via UML vai ter um fluxograma. A diferença é que não vai ter só fluxogramas, exatamente porque essas coisas foram abandonadas.

Na UML utilizamos o diagrama de atividades para um fim muito específico: representar transição entre estados dos objetos. É um dos diagramas mais raramente utilizados em um projeto OO simplesmente porque ele é procedural demais. Um sistema OO foca na interação entre objetos, não em algoritmos em si -que estão encapsulados dentro dos objetos.

Ao utilizar um fluxograma como unidade principal do seu sistema você está abandonando a OO. Isso pode ser uma coisa boa, depende do caso. para sistemas genéricos décadas de pesquisa da indústria apontam que Orientação a Objetos traz os melhores resultados na modelagem de negócios. Para um caso específico (BPM por exemplo), fluxogramas podem ser melhor. Estas ferramentas vendem trinta anos de retrocesso em modelagem.

Ainda assim, elas oferecem um bom scaffolding, não? Você não precisa saber nada sobre arquitetura, basta gerar o código na ferramenta! Bem, não exatamente. A maioria destas ferramentas vai seguir o exemplo acima: possuem poucos pontos de extensão e quando possuem não conseguem se integrar a eles. A primeira pergunta a fazer para um fornecedor desses é se a ferramenta suporta round-tripping. Round-tripping é o ato de gerar o código na ferramenta, editar o código e a ferramenta ser capaz de lidar com o código alterado. Quase nenhum RAD possui esta característica.

Outro problema é a arquitetura. Eu tenho certeza que uma arquitetura web simples pode ser utilizada por 87% dos casos mas tenho mais certeza ainda que cada um destes casos vai evoluir de uma maneira diferente. A arquitetura tem que ser flexível o suficiente para permitir todas estas formas de evolução. Obviamente que nenhuma destas ferramentas oferece nada parecido. Nós já vimos antes sobre o problema de se estabelecer uma arquitetura única para tudo, o problema com estas ferramentas é muito pior. Quando se define uma única arquitetura para todos os sistemas de uma empresa é ruim mas o que estas empresas estão vendendo é uma arquitetura única que funcionaria em diversos tipos de aplicações de diversos domínios sem sequer saber as necessidades delas antes.

Infelizmente em busca do cálice sagrado as empresas e -pior ainda- governos vão continuar gastando dinheiro nestes engodos. Eles prometem inovação mas fazem retrocesso de três décadas no tempo. Como conseguem montar um CRUD em 30 minutos são vendidos como a última bolacha do pacote, e lá vão os gerentes desinformados comprar estas coisas.

Se você está procurando este tipo de ferramenta esqueça qualquer um desses produtos ‘revolucionários’. Para começar entenda que a Ciência da Computação ainda não tem uma resposta definitiva para você. Sinto muito, estamos trabalhando nisso (é uma das partes da minha pesquisa). O campo mais avançado nesta área chama-se MDA. Eu não acredito em MDA mas isso não me faria negar que ela é a proposta mais plausível para este tipo de ferramenta atualmente. MDA possui implementações livres e proprietárias, é um padrão do OMG, utiliza UML, é baseado em um conceito de transformação de modelos e não de geração de código, é extremamente extensível e pode ter as características de produtividade dessas ferramentinhas de garagem. Só não baseie sua estratégia nele.

Os problemas de MDA: (1)ele eleva o nível de abstração mas não gera programação intencional e (2)ele usa uma ferramenta que não foi criada para isso, UML. São problemas muito menores do que os que você vai enfrentar com estes softwares ‘revolucionáros’ de ‘programação por fluxograma’.

Não caia no conto do vigário.

Posted in arquitetura, cbd, engenharia, gerencia, negocios, plataformas, programando, web | 28 Comments »

Not Bad, What About Yourself?

Friday, December 28th, 2007

Removendo algumas teias de aranha do blog. Está sendo um tempo bem difícil com todos estes feriados e tudo mais por aqui mas consegui uma brecha razoável neste natal para colocar algumas coisas em dia.

Como vimos nos últimos capítulos estou em um grande cliente num projeto em Ruby. Na verdade o projeto é uma grande plataforma tecnológica onde Java é usado no produto em si e Ruby no grande conjunto de ferramentas que os desenvolvedores criaram. A parte que eu estou trabalhando neste momento (ou para onde irei voltar dia 2 de janeiro) é um sistema que atesta a veracidade de informações.

Não dá para falar muito sobre o projeto em si mas é algo bem interessante. A empresa cliente é membro de um grande conglomerado de empresas tradicionalíssimas que lidam com tecnologia e engenharia em diversas frentes. Essa empresa em específico tem um problema interessante: ela possui uma mina de ouro em dados exclusivos mas seu sistema é completamente ultrapassado. Mesmo com esse problema em forma de legado seu banco de dados é a fonte mais confiável sobre estes dados que se têm na Oceania e estes dados são necessários para praticamente todas as empresas do país, então ela se mantém como player no mercado.

Como sempre acontece nestes novos (30 anos?) tempos boa parte dos seus clientes não está satisfeita com os serviços e está usando meios alternativos para conseguir as informações que precisa sem passar pelo sistema burocrático e antiquado. Mesmo estes meios sendo mais caros e trabalhosos que o sistema legado ainda assim preferem fugir do sistema atual de alguma forma, qualquer que seja.

Há alguns anos a ThoughtWorks entrou nesta empresa para tocar um projeto que está entregando a fase final em algumas semanas. O trabalho foi tão bem aceito que a empresa adotou o estilo agile & lean de administrar as coisas para si, ao andar pelos dois prédios de 7 andares que a empresa ocupa você vai ver dezenas de cartões pregados na parede formando diversos posteres kanban, do pessoal de marketing até o da produção. Para lidar com o domínio de negócio, algo bem específico e pesado, eles formaram várias pequenas equipes, geralmente com cinco pares de desenvolvedores (100% pair programming), um ou dois analistas de negócios, um representante do cliente (client on-site) e alguns analistas de testes.

Como falei a coisa funcionou bem e o projeto onde eu estou é o segundo com participação da ThoughtWorks. Além dos nossos consultores existem diversos funcionários e alguns consultores empregados por outras empresas: É muito engraçado ver gente que trabalha oficialmente para uma empresa de três letrinhas, CMMi nível 23 e meio praticando agile feliz da vida e comentando como este é o primeiro projeto que vê funcionar na vida.

É interessante ver mais um caso de empresa que muda não para seguir a nova regrinha do jogo mas sim porque precisa mudar. Sei que tem muita gente que discorda de mim mas acho que nos últimos anos as empresas ficaram muito mais maduras com relação ao que adquirem. Há um movimento interessante nas empresas brasileiras que fazem do software seu negócio para retirar terceirizados e colocar sua gente para desenvolver.

Se você perguntar a qualquer analista de mercado ou ler qualquer boa ou má publicação vai ver que isso seria a maior besteira. Ainda que uma empresa como Globo.com, UOL, ig, e etc. dependa do software ela não produz software para viver. Uma empresa deste tipo deveria, segundo a lógica do preto-no-branco, comprar os serviços para uma empresa de desenvolvimento de software. Isso faz sentido e diminui o custo de manter uma equipe de desenvolvimento. O problema é que, como sempre diz minha esposa: economia simplista tende à economia burra.

O modelo funciona no papel e deveria funcionar na vida real mas não funciona. Segundo o pensamento acima quando contratamos uma empresa de software estamos contratando serviços de alguém especializado nisso. Mentira. A grande, grande maioria das empresas que oferecem serviços de consultoria no desenvolvimento não tem a menor idéia do que é desenvolver um software. Seus profissionais são expostos (quando são!) a um treinamento pasteurizado e superficial, os poucos profissionais capacitados destas empresas são por mérito próprio.

Então temos uma equação interessante. Digamos que manter funcionários especializados no desenvolvimento na folha de pagamento custe X. Esse é, por exemplo, o mesmo valor que pagamos à empresa JCN (nome ilustrativo, nem sei se existe uma empresa com esse nome) para alocar seus funcionários na nossa empresa. Se fosse só por isso ia ser um negócio estranho, íamos ter um 0-a-0 no investimento. O problema é que manter um corpo técnico como funcionários da empresa não custa só isso, você precisa investir para que este corpo técnico seja capacitado. Este é o custo que seria evitado contratando os serviços da JCN.

O problema é que após algumas décadas os clientes passaram a perceber que a empresa JCN não investe nada nos seus profissionais. Eles começaram a perceber que a JCN não entende nada de desenvolvimento de software. Alguns clientes não acham que valha a pena fazer algo a este respeito. Continuam na mesma coisa, exigem um certificado CMMi novo e toda vez que fecham um contrato já se preparam para o processo que sem dúvida vai acontecer quando o projeto não for entregue nos termos deste.

Tem outras empresas, no entanto, que não podem ter este prejuízo porque se o software atrasar não vai ser seu gerenciador de estoque que sai do ar, é o seu negócio como um todo, sua fonte de renda. Pelo que já vi na prática essas empresas fazem uma de duas coisas: ou (re-)internalizam o desenvolvimento ou contratam uma empresa realmente capacitada.

A primeira parte é mais cara e trabalhosa, mas pode ser melhor. O cliente adquire uma equipe de desenvolvimento e se preocupa em treiná-los. É preciso que este time entenda como desenvolver software e é por isso que estamos vendo tantos cursos in-company de Scrum, XP e etc. Você já viu consultoria de três letrinhas pagar isso para seus funcionários? Quem está comprando estes treinamentos são os clientes, não os fornecedores. Algo para pensar, não?

No segundo caso o cliente acha uma empresa em que confie para uma parceria. Neste ponto que eu acho que as pequenas consultorias tendem a fazer bastante dinheiro. Um grupo pequeno de desenvolvedores talentosos e motivados pode fazer muito mais do que uma grande corporação de três letrinhas com duzentos funcionários alocados para seu projeto. Palavra de quem já esteve dois dois lados, de quem compra e de quem vende.

O meu cliente atual está indo para a primeira opção. Para chegar lá ele tem que enfrentar dois problemas: 1) é caro e 2) se os dois projetos não saírem até o meio do ano não precisa mais continuar a contratar gente porque a oportunidade vai ser perdida. Neste cenário o que eles fazem é contratar consultores que eles confiem para atuar junto aos seus funcionários e desenvolver o software. Os consultores, mesmo os das empresas de três letrinhas, são minuciosamente entrevistados num processo que lembra o próprio processo seletivo da ThoughtWorks.

Após este tempinho lá e medindo com minha experiência passada eu acredito que estejam no caminho certo. Eles possuem equipes com profissionais muito acima da média a um custo razoável. Estes profissionais estão entregando os projetos e ao mesmo tempo construindo a cara dos departamentos de desenvolvimento. Quando os projetos encerrarem acho que 1/3 do número de pessoas vai ser necessário para manutenção e demais desenvolvimento, como é o aproximado número de consultores não deve haver problema. Os times pequenos já são rearranjados diariamente mesmo.

Claro que o processo de achar consultores é difícil e requer investimento. Seguir este plano é bem mais difícil que fazer uma ligação do tipo: “Alô, é da JCN? Me manda 300 programadores Java, por favor? 30 minutos? Obrigado”. Eu não diria que é uma solução para todos, sequer para a maioria, já falamos um pouco sobre isso aqui.

O que eu digo a respeito da situação na maioria das empresas que está com problemas no desenvolvimento (e qual não está?) é: façam algo. Após tanto tempo comprando dos mesmos fornecedores e recebendo porcaria em troca porque você continua com eles? Após tanto tempo desenvolvendo software ruimd esta forma porqu você continua fazendo isso?

Seja lá o que fizer, faça algo. Só, por favor, não compre soluções de caixinha. Certificados, ferramentas, cursos, livros, vudu… nada disso vai adiantar, pelo menos não sozinho. Descubra a motivação das coisas e veja se aquele eu fornecedor (ou se o produto que ofereces) que diz que faz a práticas X e Y e por iso tem o certificado Z sabe, ao menos, porque ele deveria fazer aquilo.

Posted in australia, gerencia, metodologias, negocios, thoughtworks | 4 Comments »

Apresentação sobre Agile para Analistas de Negócio

Sunday, December 16th, 2007

Lendo os ThoughtBlogs hoje achei uma ótima apresentação feita por John Johnston. A idéia é introduzir os conceitos de agilidade no ponto de vista de um analista de negócios.

Posted in engenharia, gerencia, metodologias, negocios, orientacao.a.objetos, thoughtworks | 3 Comments »

Modelo de Negócios e Tecnologia

Sunday, December 2nd, 2007

Há alguns anos eu trabalhava para uma grande empresa que cria produtos em um nicho muito específico. Dá última vez que eu vi alguém fazer uma estatística 90% dos produtos eram em C, 5% em C++ (”muito lenta”) e o restante em PERL, Python e Java.

A coisa que eu mais gostava sobre essa empresa era como o modelo de negócios deles era movido por inovação. Quando alguém tinha uma boa idéia ele era convidado a montar um protótipo em laboratório que seria oferecido à clientes. Haviam muitos ganhos para os bem-sucedidos, meu chefe, diretor regional de tecnologia, subiu ao seu cargo após duas idéias convertidas em produto (além de ganhar uma boa grana).

No entanto, apesar da inovação presente nos novos produtos lançados simplesmente não havia inovação técnica. Não importa o software, tudo era feito em C. Eu fui contratado para um novo time que cuidava das alicações Java. Estas aplicações só foram criadas porque os clientes exigiam interfaces web e RMI para os produtos da empresa e porque contratar programadores C sempre foi um problema. Mesmo trabalhando basicamente com Java (e naquela época o sonho de todo mundo era arrumar um emprego “100% Java, nada de PHP ou VB”) boa parte do meu trabalho era escrever e testar interfaces em C que se comunicavam com o sistema “de verdade” (o feito em C).

Certa vez me mandaram por 10 dias, que viraram 20, numa viagem de trabalho. O lugar não era muito amigável com turistas então passei boa parte do tempo no quarto de hotel tentando entender a televisão. Como não tinha Internet liberada eu passava no dia baixando PDs e páginas completas para ler à noite e nos fins-de-semana. Com o tempo pensei: e se eu reconstruisse o sistema em Java? Obviamente que não consegui reproduzir o sistema todo dado o tempo mas se o sistema antigo tinha 5% em Java eu consegui que fosse unas bons 30%. Chegue no escritório doido para mostrar ao meu chefe.

Obviamente foi um banho de água fria. A pessoa ficou feliz por eu me interessar pelos projetos internos e disse que iria ver o sistema, um dia. Esse dia nunca chegou. Após alguns meses eu pedi demissão da empresa.

Dia desses estava falando com um amigo que ainda trabalha lá e soube que 50% dos clientes foram embora. Na época que eu trabalhava nessa empresa ela tinha quase que o monopólio de um dado tipo de sistema, com tempo concorrentes foram surgindo. O sistema da empresa era claramente superior aos outros mas era muito menos flexível. Ele era muito bom no que fazia mas quando precisávamos que ele fizesse a coisa um pouquinho diferente o projeto durava meses. Os concorrentes chegaram com linguagens como C++ e Java e apesar de não terem um produto com 10 anos de bons serviços prestados eles conseguiam mudar rapidamente.

Há dez anos a escolha por utilizar C e IPC de UNIX na mãozona era certa. Nenhuma plataforma da época oferecia o desempenho aceitável. Infelizmente as pessoas acabam construindo as piores coisas do mundo com desculpa de performance e o sistema era completamente monolítico e depende tanto do SO que mudar de uma versão minor para a outra leva um ano com um time de 3 pessoas completamente dedicados.

Se esta empresa acompanhasse os movimentos da indústria veria que existiam plataformas que já ofereceriam performance aceitável (eu já trabalhei em sistemas Java mais eficientes que aquele em ouros lugares) e que iriam oferecer a flexibilidade necessária. Infelizmente só repararam isso quando a concorrência invadiu o mercado.

A empresa continua com produtos ótimos em suas idéias mas ninguém consegue esperar 2 anos para colocar algo no ar. As coisas mudaram e escolher a tecnologia certa para cada caso é cada vez mais o qe define sucesso ou fracasso de um projeto. Ou de uma empresa.

Posted in Uncategorized, arquitetura, c, c++, engenharia, gerencia, java, negocios, plataformas, programando, rails, ruby | 2 Comments »

Lembra…

Tuesday, November 6th, 2007

..daquele projeto? Pois é, tá no ar. Mais que um site, é uma plataforma de vídeos completamente integrada com todos os outros sistemas do portal. O site é apenas um catálogo de vídeos, o projeto GloboVideos 4.2 não era sobre site, era sobre disponibilizar serviços.

Aconteceu de tudo neste projeto. O gerente responsável foi promovido e saiu do setor, o gerente de projetos foi pra outro projeto, não existia escopo definido, o analista responsável foi para o Japão treinar Aikido, tivemos que criar um framework porque nada no mercado faz o que precisamos, introduzimos uma plataforma de serviços, servidores novos, ambientes novos, enfrentamos um processo burocrático, frameworks e bibliotecas novos, migração de Oracle 8i para 10g, introdução da agilidade e até mesmo minha recente decisão em sair do Brasil.

Dadas as pessoas dedicadas e profissionais que temos eu tenho certeza que conseguiríamos entregar tudo. Já fizemos outras vezes. Mas só com um processo ágil conseguimos fazer com que o usuário saiba exatamente o que esperar deste projeto, eles já alteraram muita coisa no decorrer de todos os nossos 5 releases. E só com processos ágeis que uma janela de mudança de um site que costuma levar quase meio dia levou menos de uma hora.

Ainda temos muitos ajustes a fazer no sistema e no processo mas progredimos muito. Fico feliz de encerrar minha carreira global integrando um time de sucesso.

Parabéns a todos nós.

Posted in gerencia, metodologias, negocios | 7 Comments »

Aldo Dórea vs Fred Brooks

Tuesday, October 23rd, 2007

Eu não tenho nada contra a maioria dos gerentes de projetos mas se tem alguma coisa que me irrita é alguém que acha que gerenciar projeto de software e levantar um prédio é a mesma coisa. Veja bem: eu tenho uns bons dez anos de experiência com projetos e recomendo fortemente uma abordagem ágil, iterativa e incremental para eles, mas estou falando de projetos de software, não de projetos em geral. Eu não tenho a menor idéia se isso funcionaria para levantar um prédio, sei que funciona para software e por isso você não vai encontrar neste blog ou em alguma publicação minha qualquer dica para gerenciar a reforma do seu banheiro. Na verdade eu até evito comparações com outras engenharias porque elas sempre são danosas (o próprio conceito por trás do nome ‘engenharia de software’ é danoso).

Neste cenário temos o número atual da Mundo PM e um artigo de Aldo Dórea Mattos, M. Sc.. Aldo é um profissional com bastante experiência no mundo da construção civil. Segundo seu mini-curriculum na revista ele é engenheiro, advogado, mestre, já trabalhou em projetos em 4 países e é autor do livro “Como Preparar Orçamento de Obras”. Aldo escreveu um artigo com o título muito interessante de “Por que os cronogramas ‘furam’?”.

Em seu artigo Aldo foca em um relatório apresentado num grande congresso do PMI com este tema. O relatório foca… construção civil. Eu realmente achei que era uma leitura interessante até porque eu sempre tenho a dúvida se só nós sofremos com tantos problemas quando alguém cisma de usar técnicas de waterfall e controle total nos nossos projetos, mas o autor faz questão de citar este infeliz exemplo:

[...]O desenvolvimento de um cronograma é feito a partir de premissas de planejamento, que são pressupostos assumidos pelo GP e sua equipe. As premissas de planejamento estão na definição das produtividades que geram as durações das atividades - por exemplo produtividade do pedreiro no levantamento de uma parede de alvenaria (em m² /h), produtividade de um programador no desenvolvimento de linhas de programação (linhas/dia), produtividade de uma máquina na fabricação de componentes industriais (un/h)[...]

-Mundo PM #17, Pg 34

O que está errado na frase acima? Eu imagino que Aldo tenha muito conhecimento sobre construção civil, não imagino quanto de conhecimento ele tem sobre indústrias mas definitivamente não creio que ele saiba muito sobre programas de computador e quem os escreve.

Veja bem: ele compara o levantamento de uma parede -algo que é feito por um profissional com conhecimento meramente operacional- ou a produtividade de uma máquina à de um programador. Enquanto ainda não faz tal comparação infeliz o texto diz:

[...]A quantidade de recursos pode definir a duração da atividade ou, ao revés, ser determinada por ela. É só pensar numa tarefa alvenaria, cujo quantitativo seja de 600m² e cujo recurso prioritário seja pedreiro, com uma produtividade de 10m²/dia. Pode-se proceder de duas maneiras[...]fazer a parede em 15 dias, são requeridos 4 pedreiros; ou[...]com uma equipe de 5 pedreiros levanta-se a alvenaria em 12 dias[...]

-Mundo PM #17, Pg 33

Posso tirar pelo trecho seguinte, mostrado acima neste post, que o autor não faz distinção entre o tal pedreiro e sua parede do programador e seu código.

Como vocês estão carecas de saber eu já fui consultor, tanto autônomo quanto associado à uma empresa, incluindo empresas de três letras. Já entrei em muitos enormes clientes ansiosos por uma resposta aos seus problemas: por que eles não conseguem sequer prever o prejuízo num projeto de software? E sei que um artigo deste tipo cai como uma bala de prata.

Ops, bala de prata? Já que estamos neste tema vamos chamar ao diálogo Frederick Brooks, autor do paper seminal chamado “No Silver Bullet”. Fred também é uma pessoa importante no seu meio. Hoje dá aulas na Universidade da Carolina do Norte -onde fundou o departamento de Ciência da Computação- mas é mais conhecido como “o pai do Operating System/360″, um dos maiores projetos de software já realizados. Por este trabalho ele ganhou a medalha nacional de tecnologia dos EUA em 1985. Seu livro “Mythical Man-Month, The: Essays on Software Engineering” ganhou um dos prêmios mais importantes do mundo da computação, o Turing Award.

E lá vem Brooks discordar:

Finally, there is the delight of working in such a tractable medium. The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination. Few media of creation are so flexible, so easy to polish and rework, so readily capable of realizing grand conceptual structures. (As we shall see later, this very tractability has its own problems.)

Yet the program construct, unlike the poet’s words, is real in the sense that it moves and works, producing visible outputs separate from the construct itself. It prints results, draws pictures, produces sounds, moves arms. The magic of myth and legend has come true in our time. One types the correct incantation on a keyboard, and a display screen comes to life, showing things that never were nor could be.

–Mythical Man-Month, The: Essays on Software Engineering, Anniversary Edition, Capítulo 1

Não faz muito sentido comparar isso com um muro de tijolos, faz? E quem será que entende mais de software? E sobre recursos em um projeto?

The second fallacious thought mode is expressed in the very unit of effort used in estimating and scheduling: the man-month. Cost does indeed vary as the product of the number of men and the number of months. Progress does not. Hence the man-month as a unit for measuring the size of a job is a dangerous and deceptive myth. It implies that men and months are interchangeable.

Men and months are interchangeable commodities only when a task can be partitioned among many workers with no communication among them (Fig. 2.1). This is true of reaping wheat or picking cotton; it is not even approximately true of systems programming.
[...]
When a task cannot be partitioned because of sequential constraints, the application of more effort has no effect on the schedule [...]. The bearing of a child takes nine months, no matter how many women are assigned. Many software tasks have this characteristic because of the sequential nature of debugging.

–Mythical Man-Month, The: Essays on Software Engineering, Anniversary Edition, Capítulo 2

Não adianta você adicionar mais mulheres ao processo, a gestação dura quase sempre nove meses. Você não pode calcular progresso apenas pelo número de pessoas dividido pelo número de tarefas, isso é cálculo de padaria inútil no caso de software.

O problema não é nem a confusão feita pelo autor com relação à o que é um trabalhador relativamente operacional -pedreiro-, o que é uma máquina industrial e o que é um trabalhador de criatividade como um programador. O deslize de um é o de menos. O problema é que esse tipo de informação publicado numa revista que atinge a um mercado tão seleto quanto aos gerentes de projeto do Brasil (e que custa a bagatela de R$23,90) vai influenciar negativamente todo o mercado.

Eu tive que copiar trechos da SafariBookshelf (serviço que uso e recomendo) para fazer este post. Eu tenho o livro do Brooks, ou pelo menos tinha. Em algum momento de 2004 eu emprestei o livro para meu então Gerente de Projetos e ele nunca mais devolveu. Dia desses estive com ele e perguntei do livro, ele ficou de me devolver. Perguntei se ele leu e ele disse que não. O livro está na mesa dele há 3 anos e ele não leu, mas sei que ele assina a Mundo PM. A literatura ‘fácil’ ganha da literatura adequada, eu diria.

Eu continuo sem saber se construção civil e construção de software são parecidos o suficiente para utilizarem as mesmas técnicas de gerenciamento de projetos. O exemplo infeliz da revista me faz acreditar que não são, mas tem algo curioso nele: O artigo em si é sobre diversos problemas que resultam em atraso, problemas presentes em construção civil no caso mas que também acontecem em construção de software. As soluções que o autor propõe talvez funcionem em engenharia civil mas eu já as vi aplicadas à construção de software e… bem, não funcionam. Algo que tem funcionado com relativo sucesso para desenvolvimento de software, entretanto, é inverter os conceitos do artigo e tentar algo mais simples: metodologias ágeis. Se a construção civil sofre tanto de atrasos talvez, só talvez, seja a hora de uma das mais antigas engenharias aprender algo com uma das mais novas. Mas só talvez.

Se você quer saber como não fazer seus cronogramas ‘furarem’ em vez de gastar R$23,90 fiquem com uma frase de alguém que realmente entende de ciência da computação:

1. Estimates of the length of an activity, made and revised carefully every two weeks before the activity starts, do not significantly change as the start time draws near, no matter how wrong they ultimately turn out to be.

–Mythical Man-Month, The: Essays on Software Engineering, Anniversary Edition, Capítulo 14

E pensem em como sua metodologia apóia este tipo de revisão de estimativa, como seu cronograma pode se adaptar a isso. Se não achou nada no seu cenário atual, mude.

Posted in artigos, engenharia, gerencia, metodologias, negocios | 9 Comments »

Fragmental