Como vai o open source?

Quem me conhece sabe que tenho um carinho especial por Linux e o universo open source. No entanto confesso que estou um bocado desiludido pelo facto de ter sido prometida muita coisa à volta deste sistema, e os passos têm sido dados a um ritmo demasiado lento. Mas os progressos vão sendo feitos, principalmente com o aparecimento de algumas empresas a seguirem uma filosofia POSS (Professional Open Source Software). Tomando por exemplo MySQL, JBOSS, etc.
Também já fui mais radical, mas talvez se tenha devido ao facto de desconhecer as soluções proprietárias. Há áreas onde a Microsoft está a fazer um excelente trabalho, e os progressos impulsionados por esta empresa são de louvar (i.e. Business Intelligence).

Gostaria de salientar que os países onde a tecnologia tem tido mais sucesso encontram-se no hemisfério sul, os denominados países em vias de desenvolvimento. Portugal tem ainda muito que evoluir nesta matéria, e penso que o facto de ser prática comum a aquisição de software proprietário a custo zero através de práticas ilegais (P2P) prejudica a adopção de plataformas alternativas. Quem é que está disposto a fazer a migração de uma suite de Office numa PME, se é possível obter a custo zero a solução da Microsoft com riscos praticamente nulos? E qual a probabilidade de captar recursos para desenvolver em Unix/Linux se a maior parte dos técnicos sempre teve em casa versões proprietárias pelas quais não pagou? Ou se pagou este preço já vinha incluído no seu desktop, uma vez que os grandes fabricantes não têm por política a distribuição de raiz de software gratuito que iria baixar o preço do produto final.

Depois podemos também levantar a questão do tempo que leva a desenvolver aplicações para cada uma destas plataformas. Acredito que o Time to Market de uma solução .Net seja inferior a outra baseada em Java, que pode ser desenvolvida por inteiro recorrendo a tecnologias gratuitas (e que corre em qualquer sistema). No entanto o que interessa ponderar na maioria dos projectos é o retorno do investimento (ROI). Será que pelo facto de eu introduzir no mercado algumas semanas antes um produto cujo investimento foi muito superior terá um maior retorno? Nalgumas situações sim, noutras não. Além disso posso sempre cortar os valores das licenças e meter mais um programador no projecto. Desta forma o investimento fica retido no nosso país, o que é mais saudável para a economia nacional. Mas mais uma vez, na maioria dos casos temos a PME a comprar uma licença e a disponibilizar o software para N programadores. Desta forma não há ROI que aguente!

E temos ainda o problema do suporte. Mas este começa a ser cada vez mais um mal menor. A maioria das alternativas no mercado tem geralmente esta opção (paga). Agora será que compensa? Ora vejamos, se tiver uma licença de SIEBEL para um ambiente de desenvolvimento, outra para o de testes e mais uma para produção, e ao fim disso tudo desembolsar um determinado valor para obter suporte do fornecedor chego (claramente) a um valor exorbitante. Por outro lado posso sempre fazer o download (gratuito) do SugarCRM, fazer a instalação nos três ambientes e pagar (apenas) pelo suporte. Infelizmente não é fácil arranjar técnicos no mercado para SugerCRM, mas para SIEBEL também não! Além disso se subirmos a fasquia para bom/muito bom ficamos reduzidos a meia dúzia.


Para finalizar, e foi isto que me despertou o interesse por colocar aqui este pensamento, aconselho a leitura deste artigo de opinião. Aqui são apresentadas 5 razões para não se utilizar Linux. Não deixa de ter alguma piada.



Um abraço,
  Gama Franco

Comparação entre Web Services e .Net Remoting (ou Java RMI)

Neste artigo é apresentada uma breve comparação entre .Net Remoting e Web Services. O objectivo é simples, ajudar a determinar quando é que se deve optar por uma solução em detrimento da outra. O artigo é pequeno, pouco detalhado mas sempre dá algumas luzes aos menos esclarecidos nesta matéria.
Pela minha experiência sei que esta comparação também é valida quando feita entre Java RMI e Web Services.

Agile vs resto do mundo (Round I)

Felizmente, durante estes dois últimos anos, consegui absorver algum conhecimento em dois projectos que seguiram metodologias opostas. Para o primeiro (projecto A) foi utilizada uma metodologia baseada em Análise Orientada aos Objectos (OOA, recurso a UML). No segundo (projecto B) foi adoptada uma metodologia ágil (eXtreme Programming).
Na primeira parte deste artigo vou apresentar uma breve descrição das metodologias adoptadas em cada projecto. Na segunda irei fazer uma pequena comparação entre estas duas metodologias, enumerando as vantagens e desvantagens de cada uma delas. É claro que será apenas uma comparação baseada na minha experiência pessoal, ausente de qualquer justificação científica.

Na primeira fase do projecto A houve um levantamento de requisitos, seguido das fases de análise, desenho da arquitectura, implementação, testes e finalmente a entrada em produção. Este processo foi efectuado em espiral, ou seja, existiram sucessivas iterações entre a fase de análise e as que a sucedem.

O projecto B teve um processo de desenvolvimento bastante diferente. Existiu uma pequena fase de análise com os principais objectivos de se definir qual a tecnologia a utilizar, elaborar um calendário com diversas ‘milestones’ e acordar as linhas orientadoras do processo. Após esta breve fase começou-se o desenvolvimento, puro e duro.
Antes de se fazer uma linha de código criava-se um teste unitário (Unit Test). Se o teste falhasse (o mais comum) fazia-se o desenvolvimento da funcionalidade, e em seguida fazia-se o ‘refactoring’ do código. Depois corriam-se os testes unitários na totalidade para verificar se não se estragou nada do que estava feito até à data.
Os ‘milestones’ acordados na primeira fase foram Feature Complete (FC), Zero Bugs Bounce (ZBB), Beta 1, Beta 2 e finalmente Final Release. Em baixo faço a descrição de cada ‘milestone’.

FC: todas as ‘features’ foram terminadas até esta data, ou seja, a partir deste ‘milestone’ apenas se catalogaram e corrigiram ‘bugs’. Gostaria de realçar que neste projecto nem todos os ‘bugs’ foram resolvidos. Foi feita uma selecção de quais valeria a pena resolver ponderando a sua criticidade e os efeitos secundários da sua resolução. Além disso tentou-se sempre atrasar a resolução de um bug o mais possível, assim garantíu-se que as tarefas mais importantes eram sempre realizadas primeiro. Alias, esta filosofia aplicava-se também às ‘features’, mas este comportamento é comum a quase todas as metodologias que eu conheço.

ZBB: Quando este ‘milestone’ foi atingido os bugs a resolver tinham no máximo 24 horas. Ou seja, era obrigatório que todos os ‘bugs’ reportados num dia fossem resolvidos no dia seguinte, caso se optasse pela sua resolução.

Beta 1: Primeira versão a enviar para produção num grupo restrito de clientes. Aqui foram feitos testes de integração e de aceitação.

Beta 2: Versão para substituir a anterior no mesmo universo de clientes.

FR: “Abram uma garrafa de ‘Don Perignon’ e metam na conta do chefe”.

Para finalizar, gostaria de notar duas particularidades acerca desta metodologia.

• O cliente faz parte da equipa de desenvolvimento.


• As ‘features’ são acordadas através de ‘User Stories’

Isto quer dizer que o próprio processo de desenvolvimento é feito em ciclos muito curtos, e o projecto tem o comportamento de um protótipo evolutivo. Pode-se observar as fases de cada ciclo neste diagrama (autoria de J. Donovan Wells).

No próximo artigo irei fazer a prometida comparação entre estas duas metodologias, focando alguns pontos comuns em qualquer projecto. Será uma experiência realmente interessante, porque apesar do objectivo passar sempre por entregar um produto final no prazo acordado e deixar o cliente satisfeito, estas duas metodologias seguem filosofias opostas.

Gostaria apenas de salientar que irei fazer uma comparação tendo em conta o seguimento destas metodologias tal como foram descritas. Projectos com duração considerável sofrem sempre de alguns imprevistos, e quer num caso quer no outro não foram feitas análises de risco. Quando os imprevistos aconteceram... improvisou-se.

Também vou salientar que o um dos projectos ainda está a decorrer, e eu já não sou membro da equipa. O que quer dizer que na segunda parte do artigo irei especular acerca da sua conclusão, supondo sempre que esta será um sucesso (acredito que sim pois a equipa é liderada por pessoas com grandes capacidades nesta área).

Mais uma da autoria de Joel Spolsky

Joel Spolsky, o líder da empresa “Frog Creek Software” que utiliza uma estratégia revolucionária de recursos humanos, escreve neste artigo uma pequena comparação entre os métodos ágeis e os processos de desenvolvimento centrados na documentação. Este artigo é baseado na sua opinião pessoal, e não é alvo de uma comparação com resultados objectivos. No entanto considero uma leitura interessante para quem, tal como eu, tem dúvidas acerca de qual será a melhor abordagem para um determinado projecto. Infelizmente o artigo serve apenas para aumentar as dúvidas, mas de qualquer forma não deixa de ser uma leitura interessante.

No artigo está também uma ligação para a especificação de uma ferramenta de software desenvolvida por esta empresa. Trata-se de um documento com alguns detalhes técnicos interessantes.

PS: Aconselho vivamente a leitura regular deste blogue.

Um abraço,
Gama Franco

Maldita preguiça!

Já à algum tempo que me dá a preguiça para deixar aqui algumas ideias. Acho que posso justificar a minha falta de pró-actividade (palavra da moda nos dias que correm) com a época que estamos a passar. Este mês de Agosto não dá vontade fazer o que quer que seja. Parece que sou contagiado pelas férias dos outros, já que as minhas foram tão curtas que quase nem me lembro delas.

Para quebrar esta monotonia vou deixar aqui um breve ‘post’, de leitura fácil para recomeçar aos poucos a publicar alguma coisa. A leitura que vos proponho é uma entrevista ao autor de mais um livro de ‘Agile Project Management’, vulgo APM.

Aconselho a sua leitura numa pausa de cinco minutos antes do almoço, para abrir o apetite ;)

Um abraço,
   Gama Franco