segunda-feira, 30 de julho de 2007

Revolução das TIC

Fui hoje a um hospital do estado. Lá vi uma fila enorme de pessoas à espera. Algumas pessoas meramente esperavam que lhes fosse colocado um autocolante numa receita. Outras queriam marcar uma consulta.

As trabalhadoras, todas mulheres, estavam a dar o seu máximo. Vi-lhes determinação estampada no rosto. Vi a velocidade a que estavam a atender as pessoas. Elas estavam a lutar com um misto de sistemas de informação, da geração passada, e montanhas de papel. O stress estava ao máximo tanto nas trabalhadoras como nos pacientes à espera. Fiquei triste com esta situação. Pois como profissional de informática sei que podemos fazer melhor. Todas estas tarefas podem ser feitas pela web por pacientes e profissionais da saúde em tempo real. Sem esperas nem stresses.

Quando ouço alguém, dizer que receia que se percam empregos destes no Estado, apetece-me gritar:
Para o inferno com estes empregos! As pessoas não devem ser tratadas como peças numa máquina.

Depois lembrei-me. Estava a ver a versão moderna de uma central manual de telefones.

Encontrei comforto nalgumas coisas: o sorriso de uma menina bonita, a tranquilidade de uma mulher de esperanças, a praia gloriosa e um sol radiante.

Então lembrei-me de outra coisa: num hospital em que tinha ido, os resultados das análises ao sangue eram dados por uma aplicação de Intranet escrita em PHP. A aplicação estava inacabada e era provavelmente um hack rápido, mas mesmo assim já era serviço a profissionais de saúde em tempo real. Outro hospital, um programa em Java dava à médica o poder de marcar consultas. Já noutro hospital, as receitas eram fornecidas directamente pelo sistema de informação e dadas pelo médico ao paciente.

Como os nossos antepassados, os Romanos, esse povo de engenheiros diriam:

Adde parvum parvo magnus acervus erit
- Adiciona pouco a pouco e um grande monte farás.

sexta-feira, 27 de julho de 2007

Practices of an Agile Developer : Working in the Real World


O Verão finalmente chegou, e a PT Comunicações conseguiu, pela segunda vez em semanas, cortar o telefone à vizinhança toda sem pré-aviso. Fiquei sem acesso à Internet e sem poder trabalhar. Foi uma boa motivação para pegar nos livros que tinha aqui para ler. Venho-vos falar de um livro, que achei muito interessante.

Practices of an Agile Developer : Working in the Real World
por Venkat Subramaniam and Andy Hunt

Este livro reúne um conjunto de regras, ou boas práticas, para um programador sénior ou líder de projecto que queira trabalhar seguindo uma metodologia ágil. Os autores são experientes na matéria. O Andy Hunt já tinha sido co-autor do livro The Pragmatic Programmer: From Journeyman to Master. O livro está cheio de bom senso, ressoa bem com a minha experiência, dá exemplos e conselhos práticos como resolver problemas de desenvolvimento. Não só a nível de bater código, mas também de design, bem como comunicação entre a equipa ou com o cliente. Penso que tem boas ideias para todos nós que estão interessados no desenvolvimento de software.

Cito-vos algumas destas regras:

Quick Fixes Become Quicksand
A former client of Andy’s had this very problem. None of the developers or architects understood the underlying data model of their domain, and over the course of several years the code base became littered with thousands of +1 and -1 corrections. Trying to add features or fix bugs in that mess was a hair-pulling nightmare (and indeed, many of the developers had gone bald by then). But like most catastrophes, it didn’t get like that all at once. Instead, it happened one quick fix at a time. Each quick fix—which ignored the pervasive, underlying problem—added up to a swamp-like morass of quicksand that eventually sucked the life out of the project.

Criticize Ideas, Not People
You’ve probably seen design discussions that get out of hand and become emotionally charged—decisions get made based on whose idea it was, not on the merits of the ideas themselves. We’ve been in meetings like that, and they aren’t pleasant. But it’s only natural. When Lee presents a new design, it’s easiest to say, “That’s stupid” (with the clear implication that Lee is stupid as well). It takes a little more effort to elaborate, “That’s stupid; you forgot to make it thread-safe.” And it actually takes real effort and thought to say the far more appropriate, “Thanks, Lee. But I’m curious, what will happen when two users log on at the same time?”

Damn the Torpedoes, Go Ahead
Courage doesn’t feel very comfortable, certainly not ahead of time. But it’s often the only way to remove obstacles that will just grow worse over time, and you’ll feel relief instead of increasing dread.

Keep Up with Change
“There is nothing permanent except change,” said Heraclitus. That has been true throughout history, but it’s especially true now. You’re in an exciting and ever-changing field. If you graduated with a degree in computer science or some related professional field and thought you were all done with learning, you were dead wrong.
...
Keep up with changing technology. You don’t have to become an expert at everything, but stay aware of where the industry is headed, and plan your career and projects accordingly.

Invest in Your Team
Find areas where you, or someone in your team who is knowledgeable, can help the rest of the team come up to speed (this has the added advantage that you can discuss how topics apply specifically to your applications or projects).

Know When to Unlearn
As technology marches on, things that used to be of paramount importance fall by the wayside. Not only aren’t they useful anymore, they can actually harm your effectiveness. When Andy was first programming, memory overlays were a big deal. You often couldn’t fit the whole program in main memory (48KB or so) at a time, so you had to split your program into chunks. When one chunk was swapped in, some chunk had to be swapped out, and you couldn’t call functions on one chunk from the other.
...
We’ve seen ten man-year J2EE projects go down in flames, only to be replaced with a month-long hack in PHP that delivers most of the features. Growing interest in languages such as PHP and web frameworks like Ruby on Rails show that developers are catching on that the old ways might not be cutting it anymore.
...
Old habits are hard to break and even harder to notice. The first step to unlearning is to realize that you’re using an outdated approach. That’s the hardest part. The other hardest part is actually letting go. Mental models and patterns of thought are built and refined at great cost over many years. One doesn’t discard them lightly. And it’s not that you really want to discard them completely, either. The previous memory overlay example is just a special case of manually maintaining a working set of items from a larger cache. The technique hasn’t gone away, although that implementation of it has. You don’t want to drill into the brain and snip all those dendrites off. Instead, you want to use older knowledge in context. Reinvent it and reuse it where applicable, but make sure you don’t drag along old habits just out of, well, habit.

Não me tinha ocorrido antes de ler o livro, mas mesmo com 29 anos, não escapo ao problema de ter de saber desaprender. Dei-me ao trabalho de aprender linguagens novas como Java, C#, Python e PHP, que não me foram ensinadas no curso, mas continuava a editar código com o vim. Desde que mudei para IDEs com suporte para refactoring, algo que não também não existia quando acabei o curso, reparei que a minha produtividade aumentou imenso.

quinta-feira, 26 de julho de 2007

Nearshoring na Europa: uma oportunidade para o Brasil

As empresas portuguesas de TI estão, crescentemente, a posicionar-se no mercado europeu oferecendo serviços de outsourcing near-shore. O conceito é simples: as grandes empresas contratam a nível global, fazendo o que se costuma chamar off-shoring: sub-contratar em países onde os custos são mais baixos. Near-shoring é um off-shoring de proximidade.

A Índia é provavelmente o melhor exemplo de um destino dos contratos de TI que foram alvo de off-shoring. A China está rapidamente a ganhar importância e a Rússia quer ganhar terreno.

A distância física coloca alguns problemas, geralmente compensados pelo menor custo. Mas as maiores barreiras ao off-shoring bem sucedido são, provavelmente, as diferenças culturais. Quando se encomenda o desenvolvimento de software a alguém que vive numa realidade completamente diferente, mesmo que se fale a mesma língua, os mal-entendidos são frequentes e saem caro.

Daí que o near-shoring ganhe cada vez mais adeptos. Trata-se de um compromisso entre economia e qualidade dos resultados. Em vez de se contratar simplesmente pelo preço, procura-se encontrar quem entenda o problema e, mesmo assim, faça o trabalho de forma mais económica.

Nesta perspectiva, pela facilidade com que dominam línguas e se entendem com todos os povos, e também pelos preços competitivos que apresentam, os portugueses e as suas empresas estão muito bem posicionados para prestar serviços de near-shoring para toda a Europa.

Acontece que, pela reduzida dimensão do país e por alguns erros estratégicos no sistema educativo, os recursos humanos disponíveis para esta estratégia são escassos. Daí existir actualmente uma oportunidade para os profissionais brasileiros de TI que procuram oportunidades de emprego na Europa ou para as empresas brasileiras de outsourcing que procuram expandir o seu negócio. Para estas últimas, não será difícil encontrar parceiros portugueses que queiram actuar como "revendedores de valor acrescentado", potenciando a sua prestação de serviços por toda a Europa e pelos restantes países de língua portuguesa.

O que será necessário para aproveitar esta oportunidade? Vontade e ambição, para começar. Capacidade técnica, claro. E uma boa escolha dos empregadores/parceiros em Portugal.

Esta é uma oportunidade a não perder, em que Portugal e Brasil se podem unir para ganhar. A Europa espera-nos! :-)

quarta-feira, 25 de julho de 2007

Conselhos de Administração não levam a sério os técnicos de TI

Tim Ferguson, da Silicon.com / IT Director escreveu um artigo em que defende a ideia de que os Conselhos de Administração não levam a sério os seus técnicos de TI. Para afirmar isto baseia-se num estudo encomendado pela Microsoft. Vejamos o que ele diz...

"Muitas grandes empresas não conseguem reconhecer o valor e a importância das TI no seu negócio e estão a perder por isso."
Com "gurus" a afirmar "IT doesn't matter", não é para admirar! Mas a culpa não é só dos "gurus"...

"Quase metade dos directores de TI acham que o seu departamento é visto apenas como um centro de custos pela Administração. [...] 83% dizem que os problemas de desempenho das aplicações tem impacto directo no negócio e 76% dizem também que os atrasos nas novas aplicações trazem dificuldades."

Portanto, as aplicações têm que funcionar, mas são apenas vistas como mais um custo. Esta "falta de respeito" talvez possa ser explicada, pelo menos em parte, pelo que se segue...

"Apenas 35% dos que responderam ao inquérito estão satisfeitos com o tempo que leva a desenvolver e pôr em exploração as novas aplicações. E embora 37% digam que é prioritário que exista um melhor alinhamento entre das TI com o negócio, a percepção geral é que as companhias não estão a actuar com vista a este objectivo e estão a comprometer o impacto da tecnologia"
Não sei bem o que os inquiridos pensam, mas eu suspeito que há por aí muito informático que pensa que alinhar o negócio com as TI é mudar o negócio, em vez de melhorar as aplicações! O que se confirma com o que vem a seguir...

"apenas 16% dos departamentos de TI acreditam que a qualidade do interface e a ergonomia (user experience) é um componente crítico do desenvolvimento aplicacional e só 36% têm planos para melhorar estes aspectos em projectos futuros"
É pena que o inquérito só tenha ouvido uma das partes. Tenho a certeza que os membros dos Conselhos de Administração têm também muitas queixas a fazer em relação às TI e provavelmente eram capazes de explicar porque é que as encaram como um custo! Como são eles que têm o dinheiro, talvez valesse a pena começarmos por ouvi-los! ;-)

O pessoal das TI não pode continuar virado para o seu umbigo, preocupado com os seus problemas tecnológicos e ignorando as justas queixas dos utilizadores. De que se queixam eles? Que as aplicações nunca estão prontas quando são precisas. Que têm bugs. Que não funcionam como eles gostariam porque quem as fez não percebe para que é que deviam servir!

Queixamo-nos de falta de respeito? O respeito conquista-se!


segunda-feira, 23 de julho de 2007

Dada como perdida toda informação online após crash da Internet

[humor] Por esta altura já devem ter tido conhecimento da principal notícia de hoje: todos os dados online foram perdidos após um crash total da Internet.

Milhões de computadores do mundo inteiro receberam uma mensagem fatal dizendo "Fatal Error / Restart World Wide Web / Online data may have been lost" e bloquearam, obrigado os seus utilizadores a realizar um reboot. Até aí, nada de anormal. O pior foi que depois descobriram que toda a informação que habitualmente encontravam na net foi perdida, por nunca ter sido feito um backup integral da World Wide Web.

Numa atitude absolutamente inédita, o Governo dos Estados Unidos já pediu desculpa aos cibernautas do mundo inteiro, afirmando que o backup estava previsto já há vários anos mas que nunca houve tempo para o realizar.

Mais informação pode ser encontrada no site da ONN, uma rede noticiosa de televisão 24h/dia, principal referência global de noticias desde que foi fundada em Dezembro de 1892. Esta rede tem canais em 171 línguas e pode ser vista em 4,2 mil milhões de lares em 811 países do mundo inteiro.



Breaking News: All Online Data Lost After Internet Crash

quinta-feira, 19 de julho de 2007

Web Rage - Um artigo a ler


Quantos de nós, que trabalham em TI(s), não sofreram na pele a troca de e-mails desagradáveis que chegam muitas vezes a atingir os limites da má educação.

Mesmo assim teimamos em tentar discutir e muitas vezes decidir apenas com base em trocas de mensagens escritas.

Gosto de usar mensagens escritas numa série de meios : blog(s), mensagens instantâneas e sms(s).
Em muitos casos estes meios ajudam-me pois podem permitir uma leitura mais objectiva do conteúdo estrito e menos de emoções que normalmente são acessórias ao problema.

Tenho no entanto de reconhecer que quando começa a correr mal, corre mesmo muito mal. As emoções de quem está do outro lado começam a impedi-lo de pensar.
Daniel Goleman e Clay Shirky publicaram um artigo onde tecem algumas considerações sobre os problemas destas formas de comunicação e explicam os mecanismos que os provocam.

Concordo no geral com o artigo, no entanto os autores partem de uma premissa que muitas vezes não se encontra na realidade : de que a comunicação é entre indivíduos que pessoalmente têm boa empatia e conseguem colaborar.

Na minha experiência pessoal já consegui melhor comunicação on-line do que pessoalmente. Tentando fazer uma análise das pessoas em causa consigo concluir de que se trata de pessoas cuja reacção emocional imediata é sempre de defesa. Neste caso a comunicação por e-mail oferece ao indivíduo um tempo de reflexão que lhe permitirá responder de uma forma mais racional e ponderada.

Mas, volto a frisar, concordo com os autores de que o processo de decisão por e-mail não será em geral uma forma mais eficaz do que reuniões frente a frente.