O ciclo de morte dos sistemas

No começo tudo são flores, a equipe é montada, a arquitetura definida, os requisitos mal e porcamente levantados e todos trabalham com afinco até que o sistema entra em prodção, então alguns membros chave do grupo saem, outros perdem o interesse, o sistema começa a sofrer manutenções até que um dia alguém diz: "Não posso fazer a alteração que o sr está pedindo porque não sei se a alteração não vai quebrar outra funcionalidade"

Quem com alguns anos de experiência na área de desenvolvimento de sistemas nunca se deparou com um frase como essa? Ela demarca o princípio do fim, a partir daí o sistema começa a ficar engessado, estático, para de se desenvolver e entra na fase do "só arruma o que está dando problema", daí para o "joga fora e faz de novo" é um pulinho.

Mas como evitar que isto aconteça? Simples:

• Adote métodos de desenvolvimento que fomentem a comunicação e consequente compartilhamento do conhecimento (SCRUM por exemplo)
• Invista em testes de regressão automatizando o máximo possível
• Tenha a coragem de mudar quando necessário, mude as pessoas, a plataforma, a funcionalidade, etc
• Integre continuamente
• Invista nas pessoas, na formação e no bem estar delas

Mas (sempre existe o mas) é complicado justificar aos investidores do projeto o tempo (e dinheiro) gasto na implantação de práticas de engenharia , então talvez esta seja a justificativa: proteja seu investimento atual através do uso das boas práticas de engenharia, ou então dentro de algum tempo voce terá que dispor de tempo, pessoas e dinheiro para fazer tudo de novo.

por hoje é só
[]s
Dino

O ciclo virtuoso do ensinamento/aprendizado

Vou insistir no assunto conhecimento e aprendizado porque realmente acredito que vale a pena, já que cada vez mais isso se torna um diferencial no mercado de trabalho.
Quando eu estava na faculdade tinha um professor de matemática financeira que vivia usando a frase "voces deveriam experimentar a estranha sensação do raciocínio" quando se referia à nossa preguiça mental. Hoje em dia entendi (eu acho) o que ele queria dizer e a aprecio tanto que acrescentaria "experiemente, dá barato!".
E o que isso tem a ver com arquitetura de software ou com tecnologia? Tudo! Escrevi no post anterior que uma das características que considero essenciais para um bom arquiteto - ou um bom profissional da área de TI em geral - é saber aprender, neste vou além: um bom arquiteto deve usar sua experiência e conhecimento para ensinar a aprender.

O arquiteto até pode ser líder mas nunca chefe
A diferença entre o líder e o chefe é que basicamente o primeiro é um cara que fica no plano de fundo, sem aparecer muito e cujo principal objetivo é levar os liderados ao sucesso, no contexto aqui proposto o sucesso seria o aprendizado, a aquisição do conhecimento. O chefe todo mundo tem e sabe como é.
Dentre as várias estratégias possíveis que poderiam ser usadas para atingir tal objetivo, uma que gosto muito de aplicar consiste em fazer com que o aprendiz chegue a uma conclusão (aprenda) através de perguntas e mais perguntas, sempre dando direcionamento, gerando conflito, mas nunca relelando a resposta em si, até que num dado momento o próprio aprendiz tem o "estalo" que resolve a questão. Neste instante o cérebro faz sua parte liberando substâncias químicas que dão um certo tipo de prazer (mais ou menos como a adrenalina) e a tal sensação do raciocínio se faz presente, como disse antes, dá barato!
Logicamente existem outros métodos, desde ensinar através de exemplos até as tais "comunities of practice" onde se aprende estudando e observando os mestres (ou membros do core), ou então incentivando a leitura (e porque não escrita) de artigos técnicos e/ou científicos, etc.
O importante é que o aprendiz consiga criar em sua mente a inferência que leva à solução, e não a solução em si, pois a primeira pode ser combinada com outras para solucionar outros tipos de problemas criando assim a base de um cérebro criativo.

Mas porque não dizer logo o que e como fazer ?
"Afinal é só dar a ordem, depois cobrar o resultado e pronto. Além do mais, fazer isso (ensinar a aprender) leva tempo, às vezes dá muito trabalho e nem sempre é bem recebido pela equipe".
Entre tantos motivos que consigo pensar, aquele que me parece o mais importante é: porque essa é uma via é de mão dupla, ensinar é a forma mais eficiente de aprendizado.
Pergunte aos seus professores, todos são unânimes em dizer que aprendem coisas novas diariamente com seus alunos, sendo assim o barato do aprendiz também é o barato do mestre: a aquisição de conhecimento.
Aí está a mágica, o conhecimento gera bem estar, que gera a predisposição a aprender, que realimenta a fonte inicial do ciclo, o mestre, que por sua vez se ve mais disposto ainda a ensinar. É este ciclo virtuoso que devíamos almejar ao escolher o difícil e trabalhoso caminho do ensinamento em detrimento da aparente agilidade de uma ordem.

bons estudos, bons ensinamentos
t+

Arquiteto??? Você constrói casas, prédios?

Outro dia tive que tentar explicar pela milionésima vez porque fui contratado como arquiteto de soluções. A pergunta mais normal é:

- mas você não era programador?

Sim, eu sou e me orgulho muito disso.

Então:

• Qual é a diferença?
• O que faz de alguém um arquiteto?
• Quais os papéis que ele desempenha?

Bom, vamos por partes, de traz para frente.

Quais os papéis que um arquiteto de software/soluções exerce?

O The Architecture Journal dedica sua edição de #15 inteiramente a este assunto, nem vou tentar resumir aqui, recomendo fortemente a leitura. Ou se preferir tem este ótimo post que resume bem o assunto.

O que faz de alguém um arquiteto?

Existem algumas abordagens para definir um arquiteto, algumas analisam o lado técnico, outras a capacidade de síntese, outras ainda defendem que é um cara que consegue entender as necessidades de negócio e ao mesmo tempo tem o conhecimento técnico necessário para desenhar a melhor solução possível. Este último para mim chamou-se um dia Analista de Sistemas e já faz um tempo que não ouço falar dele.
Eu prefiro uma abordagem, digamos, mais humanista. Para mim o que faz um programador se diferenciar dos outros (sair dos 80%???) e se tornar arquiteto é o espírito inquieto, a persistencia, o equilíbrio e principalmente o estudo.

O espírito inquieto
Sabe aquele moleque que desmonta as coisas pra depois passar dias tentando entender onde deveriam estar as peças que sobraram? Conhece aquela criança que de cada 10 palavras ditas 11 são "por que"? Sabe aquele nerd do colégio que não para de encher a paciência dos professores enquanto não entende a matéria? Sabe aquele curioso que mexe em tudo, que tenta saber um pouco de tudo?
Então, esses são alguns fatores (entre milhares de outros) que indicam uma pessoa com a predisposição a ir além, a sair da caixa e ver o quadro geral, a distrinchar um problema até chegar à sua causa raiz e só então propor uma solução. Este tipo de pessoa tem mais chances de se diferenciar como programador e se tornar arquiteto, não que alguém sem essas características não o possa, é só que para alguém assim o caminho é mais suave.

A Persistência
Muito já se falou sobre isso mas é sempre bom lembrar, não basta ser genial nas idéias é preciso persistir até conseguir provar com algo material que suas idéias são viáveis. Um ex-colega de trabalho (e bom amigo) costuma usar um termo para este assunto, ele diz que iniciativa é bom, mas é imprescindível ter "acabativa", ou seja, de nada adianta começar n coisas e terminar nenhuma delas.

O Equilíbrio
Se alguém é extremamente radical, esta pessoa pode ter problemas em se tornar arquiteto de software pelo simples motivo de que a radicalidade acaba tirando da pessoa a capacidade de ver o quadro geral, tira a imparcialidade necessária para enxergar corretamente o problema e limita o número de ferramentas disponíveis para solucioná-lo.
Um exemplo disso é a pessoa que é radicalmente a favor de uma linguagem de programação a ponto de não enxergar pontos positivos em qualquer outra. Isto ocorre com sistemas operacionais , IDEs, navegadores, plataformas de desenvolvimento, times de futebol, religião, poítica, marca de cerveja, música, etc.
O ponto aqui não é exatamente o equilíbrio em relação a questões tecnológicas, mas, num sentido mais amplo, avaliar a pessoa pelo modo como ela se posiciona em relação a questões polêmicas, se sua posição é geralmente ponderada, o caminho para esta também tende a ser suave.

O Estudo
Os arquitetos que conheço são absolutamente malucos por informação, os caras estudam o tempo todo, sobre várias coisas, ao mesmo tempo. Neste ponto tenho que concordar, a pessoa tem que ter uma capacidade de síntese muito boa para conseguir rapidamente ler (ou ver, ouvir, etc), entender, filtrar e classificar a informação.
Neste ponto as características citadas anteriormente agem juntas fazendo com que a pessoa estude a fundo um assunto (persistente) mas não a ponto de se viciar nele (equilibrado), faz com que ela mude o foco constantemente (inquieto, curioso) mas ao mesmo tempo mantenha o foco tempo o bastante para digerir e compreender o assunto (de novo persistente).
Mais que ser estudioso, a capacidade de aprender a aprender talvez seja a mais marcante caracteríscta do arquiteto. Numa área onde tudo muda a todo momento, não basta saber, tem que saber aprender e se munir disso para o bem de si próprio e da empresa. Aquele que consegue aprender a aprender também caminha mais tranquilamente no sentido de se diferenciar.

Então qual é a diferença?

De verdade? A diferença está nas escolhas que a pessoa faz ao longo da carreira, talvez antes mesmo de ingressar no mercado de trabalho.
Os que escolheram tentar, fuçar, mexer, quebrar, arrumar, perisistir, aprender coisas novas, ouvir músícas diferentes, conhecer pessoas, estudar filosofia, etc. criaram ao longo da vida uma " "poupança" que lhes permite ser diferente, ao invés de se tornar diferente. Aos que ainda não são, sempre é tempo, basta começar.

Finalizando, se eu sou um programador? De novo, sou sim. Adoro código, adoro falar de software e hardware, adoro SQL, índices, tabelas, EJBs e C#s. E sim, sou arquiteto, pelo menos é como me chamam aqui no trabalho, e também me orgulho disso.

por hoje é só.
T+