"Anjo é isso, me ensina, esclarece, e me deixa livre pra fazer minhas opções"
Uma "chamada" da Rede Globo

Quem estrutura o que?

É o projeto que estrutura o processo ou, pelo contrário, é o processo que comanda tudo, organizando o projeto?

Costumo ler com satisfação os artigos que Roberto Damatta publica às quartas feiras no jornal O Globo. O do dia 4/4/2012, intitulado “Quem interpreta quem?” captou minha atenção de forma especial. Nele, três pequenas estórias dão o suporte a uma ideia básica.

Na primeira, ele relata a experiência em que assistiu, em Viena, à ópera “As Bodas de Fígaro”, de Mozart. Durante a apresentação ele pensava:

é a orquestra que interpreta Mozart ou, pelo contrário, é Mozart quem comanda tudo, interpretando a orquestra?

A segunda estória, com base no CD “Grande Cancioneiro Americano” gravado por Rod Steward

Franchising de Metodologia – Poderemos Ser Escravos de Algum?

Acompanhando blogs e listas de discussão sobre desenvolvimento de software, percebo que muitos profissionais parecem ter a expectativa de que os métodos e práticas propostos por alguma metodologia devam ser seguidos à risca. Parece até que, para eles, metodologia seja um produto fechado do qual são quase escravos. Neste post  procuro explicar porque não deveríamos ter esse tipo de expectativa.

Costumo comentar que a indústria de software, assim como as artes, tem a peculiaridade de lidar apenas com conceitos. Nossos produtos são sempre abstratos. O resultado de nosso produto pode ser “visualizado” ou “percebido” de uma forma mais concreta apenas durante sua utilização. Nem o mais experiente participante da equipe consegue ter essa percepção examinando o código, que seria nosso produto mais concreto. Nosso cliente então, nem pensar!

Diferente da maioria dos produtos disponíveis no mercado, o software não tem uma forma ou qualquer outra característica física que possa diferencia-lo de outro software.

Blink! – Num Piscar de Olhos

Já lhe aconteceu de ficar surpreso com o resultado de algo em que você estava envolvido ou era o responsável? Tão surpreso que, quando de repente “caiu a ficha” esclarecedora sobre sua participação, você nem mesmo acreditou que pudesse ter feito aquilo? O que poderia ter ocorrido para provocar sua ação?

No livro “Blink“, Malcolm Gladwel relata algumas situações assim. Na realidade seu livro relata casos de decisões tomadas instintivamente, sem pensar da forma tradicional como costumamos assumir que as decisões são tomadas: analisando alternativas, quantificando as vantagens e desvantagens de cada possibilidade. Nesse livro, ele trata de decisões tomadas instantaneamente em situações reais, durante um piscar de olhos, e a grande maioria, de forma surpreendente para mim, foram decisões acertadas.

Na introdução do livro ele relata a aquisição, pelo museu J. Paul Getty, de um kouros – estilo específico de escultura grega – após os procedimentos necessários para comprovar a autenticidade da mesma. Alguns especialistas em arte familiarizados com escultura grega, ao verem a estátua pela primeira vez, tiveram uma reação instantânea de “rejeição” à mesma.

Requisitos, esses inconstantes!

Eu ia escrever algo sobre requisitos, sobre como costumam ser inconstantes. Esse assunto estava na minha lista. Gostaria que fosse uma estória interessante para captar a atenção dos leitores, que fosse contextualizada em outro ambiente, mas que o paralelo com nosso ambiente de software fosse evidente. Por fim, gostaria de mostrar como um ciclo curto de desenvolvimento com entregas sucessivas de produto são uma boa alternativa para desenvolvimento de software, exatamente porque requisitos inconstantes são o nosso dia a dia.

Hoje li o post de Ron Jeffries, Kate Oneal and the Mythical Italian Restaurant, e não tenho mais o que escrever sobre o assunto. Recomendo a leitura.

O Jardineiro de Idéias

Em um desses dias normais, no horário de expediente, ele estava em um  condomínio comercial aguardando o elevador. Era um profissional da área de informática com muitos anos de participação em equipes de desenvolvimento de software, como desenvolvedor ou coordenador.

Como um dos dois elevadores estava em manutenção, a fila andava devagar e ele olhava vagamente um desses onipresentes monitores de tv dedicados a notícias e comerciais prestando alguma atenção na vinheta inferior, que naquele momento mostrava o acompanhamento de indicadores da Bolsa de Valores. Foi quando  sua atenção foi sequestrada

Um Novo Olhar Sobre o Software

Texto de setembro de 2002, para uma turma de pósgraduação em TI

Muitas vezes me lembro de como o nosso trabalho como desenvolvedores de software tem sido efetuado ao longo do tempo.

No início, nas empresas em que trabalhei nas décadas de 60 e 70, formávamos pequenas equipes, todos em uma única sala. Comecei em 65 e já existia a distinção entre analistas e programadores, mas não era muito marcante. Na prática, conversávamos muito sobre o que estivesse em andamento e nos, programadores, éramos envolvidos muito cedo no ciclo de vida do projeto, com participação ativa em muitas das decisões de “design” do software a ser construído.

A Torre de Babel e a Qualidade de Software

Este artigo foi publicado na Developers Magazine – Abril/2002

No princípio era o programador; e o Programador captava, interpretava, analisava e compreendia o que deveria ser feito; e programava os computadores; e os programas eram bons e os usuários estavam satisfeitos (mesmo porque a tecnologia não permitia muitas variações).

O tempo passou. O mundo evoluiu e a tecnologia, então, evoluiu muito mais rapidamente. Desenvolver e manter em operação os sistemas de informação que atualmente são demandados pelas organizações de médio e grande porte tornou-se uma tarefa extremamente complexa. Os sistemas dos anos 60 cobriam umas poucas … Artigo em pdf.