negocios « Fragmental

Archive for the ‘negocios’ Category

A Completa Irrelevância do Certified Scrum Master

Tuesday, May 27th, 2008

Semana passada o Richard Durnall me chamou para assistir a uma aula que ele deu na University of Melbourne. O Rich é o guru local de Lean e é uma figura.

A aula foi interessante. O curso é o mestrado em alguma das 343.435 ramificações de Tecnologia da Informação, basicamente uma escolinha para CIO-wannabe. Para se ter uma idéia todas as perguntas da sessão foram sobre implantação de ERPs, você via claramente que nenhum dos estudantes tinha a mínima vivencia na indústria e acreditavam piamente nas suas Info Corporate da vida.

A matéria era sobre comparação de metodologias e o Rich não foi o único. Antes dele apresentou um senhor, que é professor da instituição e arquiteto do maior banco da Austrália, onde inclusive tenho conta (brr…). A palestra do senhor arquiteto foi sobre como ele participou da salvação de um projeto de data mining usando o bom e velho waterfall. O único ponto diferente de uma lição clássica sobre como não fazer software foi sobre o uso de técnicas de Six Sigma para avaliação e priorização dos requisitos.

Quando chegou a vez do Rich apresentar Agile/Lean foi um contraste enorme. Na sessão de perguntas:

- Você falou sobre estes métodos ágeis e sobre como eles…er.. não ligam para requisitos. O [cara defendendo waterfall] apresentou um caso real de um grande banco. Você realmente acha que as técnicas de algo como agile podem competir com Six Sigma? [nota: uh?]
- Então, na minha apresentação eu fui bem ralo e essa é uma palestra introdutória, então foi bom você perguntar isso. Eu trabalhei na [top 5 montadora de automóveis], na [maior empresa aérea do mundo] e em alguns bancos. Nas duas primeiras empresas eu fiz parte da implantação de Six Sigma, inclusive eu sou Black Belt. O que eu vi deste processo foi [...] e por isso que agile/lean é uma boa escolha.

Agora pense que em vez de “Six Sigma Black Belt” ele tivesse dito algo como “inclusive eu sou Agile Software Specialist e os problemas de Six Sigma são [...]“. Teria o mesmo efeito?

Outro caso recente e interessante foi no Australian Architecture Fórum em Sydney. O Halvard estava apresentando uma palestra extremamente interessante sobre governança de projetos SOA onde a única ferramenta é um wiki. Em algum momento alguém levanta:

- Ok, ok, isso aí é muito Web 2.0, muito legal mas não é aplicável no meu cenário.
- E qual seu cenário?
- Eu trabalho em um banco, faço parte do grupo de controle de serviços de segurança. Isso de REST, wiki é muito legal mas vocês não entrariam num banco de modo algum!
- Uhm.. interessante você falar disso porque segurança em serviços é uma das minhas áreas de estudo… eu concluí meu Ph. D. em SOA na Universidade de Sydney e meu foco é exatamente segurança. Na verdade, na ThoughtWorks a maioria dos clientes são bancos e, inclusive, tivemos hoje de manhã o arquiteto principal do banco [top 5 banco australiano] falando exatamente sobre como usaram este tipo de técnica para governança num projeto que participei.

Imagine que ele tivesse falado “Eu sou um Wiki Certified Contributor e um RESTafarian Official Gold Partner”. Teria o mesmo efeito?

Por que das historinhas? Para argumentar numa discussão que eu tive com o grande Juan Bernabó sobre a total e completa ausência d sentido em algo como Certified Scrum Master. O Juan argumentou que certificações são valorizadas -e requeridas- pelas empresas. Meus pontos são:

Eu não conheço nenhuma pessoa que acredite que um curso de dois dias, sem sequer uma avaliação final –pagou, passou na pratica- deva ser valorizada. Se nós sabemos que a certificação não tem valor por que a venderíamos de outra forma? Agile não é sobre trazer valor e melhorar praticas?
O mercado também quer porque quer e acha que precisa de cronogramas detalhados, requisitos esmiuçados e projetos que terminam em uma grande fase de testes. Nós sabemos que isso não traz valor não fazemos apologia a este tipo de coisa, por que com certificação seria diferente? Por que ao invés de combater a ineficiência e a busca por respostas fáceis nós criamos e glorificamos nossos próprios selos?
Uma certificação emitida por si mesmo não vale nada. A menos que alguém já acredite que Scrum traz algum valor essa certificação é como acreditar que o Inri Cristo é Jesus porque ele afirma o ser.

Em resumo, eu acho o curso que é dado com o CSM ótimo. Ele abre mentes e é uma fantástica introdução. E só. O certificado emitido por este curso não tem qualquer valor real e propagandear o contrario, ajudando empresas a continuar glorificando certificações sem sentido, vai contra a primeira linha do Manifesto Ágil:

We are uncovering better ways of developing
software by doing it and helping others do it.

O debate completo está aqui.

Posted in australia, comunidade, eventos, gerencia, metodologias, negocios, thoughtworks | 20 Comments »

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 | 28 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 | 19 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 | 29 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 »

Fragmental