Conhecendo o tio da senha

A divisão do software em camadas, atualmente, é certamente uma das formas mais eficiente de estar se organizando a sua aplicação. Facilitando a manutenção, reaproveitamento de código, etc. Vale salientar que camada no inglês tem duas palavras: Tier, a camada física e Layer, camada lógica. No entanto, criar um grande número de camadas além de desnecessário acaba deteriorando a desempenho do seu software. Assim surgiram as chamadas delay layer, camadas lógicas que apenas servem para passar à informação a diante, gerando atraso na reposta e consumo desnecessário na memória. Esses atrasos em alguns casos acontecem fora da parte lógica da aplicação. Acontecem no processo de desenvolvimento (fora do código), pessoas ou profissionais que acabam gerando um atraso na resposta, delay tier, conhecido carinhosamente como os tios da senha.

Exemplificando como eles funcionam, falarei do funcionário que aperta o botão no elevador, não estou desmerecendo nenhuma profissão. O elevador possui uma interface super simples e basta se pressionar o botão com o andar desejado. Você precisa informar o andar desejado e ele por sua vez apertará o botão. Essa chamada gerará um atraso natural até você informar o andar desejado e ação desse profissional, quando entrar 10 pessoas simultaneamente essa demora será “gritante”.

As empresas não o contratam diretamente, os preferem chamar de Arquitetos, gestores de aplicação ou DBAs, são profissionais que centralizam alguns até mesmo todos os processos de software de uma empresa. Essa ação gera uma pseudo controle para a empresa, porém, acaba gerando atraso tanto nas escolhas de tecnologias quanto na execução de um script, alteração no banco de dados etc. e esses atrasos impactam diretamente a entrega desse projeto.

O fato é que as tecnologias, requisitos, metodologias, etc. surgem muito rápidos, assim nascem várias siglas (UX, DDD, TDD, BDD NOSQL, NewSQL, bid data, integração contínua, etc.) e deixar essa responsabilidade na mão de apenas uma pessoa ou uma pequena equipe se torna um erro. Por alguns motivos:

Caso os detentores das senhas, se desmotivarem e parem de se atualizar profissionalmente. O parque tecnológico da empresa em pouco tempo vivará artefato de museu.

Centralizar decisões tecnologias para todos os projetos é um grande erro! Ninguém melhor que um membro da equipe para decidir qual ferramenta é a mais interessante para um requisito específico. Sem falar que pode gerar uma padronização equivocada, ou seja para todos os problemas a mesma solução. Dizer que para todos os problemas precisamos de um martelo é dizer que os parafusos também são pregos.

O aumento demasiado do ego, isso mesmo, um técnico com um ego muito grande faz com que toda a empresa use tecnologias do seu “mundinho” para que assim seja o maioral.

Atraso na resposta, fazer com que muitos processos passem na mão de uma pessoa, quando existir muitas requisições de várias pessoas em algum momento gerará um atraso, é o caso do elevador quando entram dez pessoas ao mesmo tempo.

Mal aproveitamento de um profissional, se queremos executar um simples script ou renomear um campo de uma tabela para que precisamos de um DBA para uma atividade tão trivial ? Seria mais interessante que ele estivesse ajudando em atividades como: trabalhar para dar maior desempenho e diminuir o tempo de resposta no banco, definir índices, ajudar na escalabilidade do banco, uma mudança de estratégia para um banco NOSQL ou NewSQL, bigdata, ajudar na criação de querys com mais desempenho ou talvez criação de views, etc.

Abandono na qualidade do projeto, o software que usa ferramentas muito antigas será a janela quebrada do seu projeto.

Desmotivar a refatoração do projeto, o fato mais comum para os requisitos é que eles mudam com uma grande facilidade, desse modo, a refatoração é importante tanto para um código e banco mais limpo tanto para um bom desempenho para a aplicação. Quando para realizar tal atividade precisa passar por um processo demorado, essa atividade acaba sendo muito custosa para o projeto e em alguns casos sendo descartável.

Ou o que eles precisam fazer ?

Acredito que o primeiro passo é entender que engenharia de software não é comparável com outras áreas, assim, possuem características e metodologias próprias. Em seguida a área evolui muito rápida e precisamos evoluir junto com ela simplesmente “parar no tempo”.

Em relação das ações, o que eles precisam fazer é o processo totalmente inverso, ou seja, o de não centralizar informação e ser o facilitar o acesso ao conhecimento. Descentralizar é fazer com as informações circulem de maneira mais “livre” e que as soluções partem de qualquer parte da empresa. Estimular atividades como codingdojos, participação de eventos, wiki na empresa, etc. Uma equipe autogerenciável deve ser o sonho de qualquer gestor de TI que esteja em 2012.

Remover os atrasos do processo software é crucial para manter um ciclo saudável no desenvolvimento. Conhecer a filosofia “toyotismo”, que se tornaram base para as metodologias ágeis, e dizer adeus ao “Taylorismo”, filosofia de Taylor que visa centralizar as decisões, é um pequeno passo para isso. Desconcentrar processos e decisões de software é muito mais do que apenas remover uma camada física desnecessária, delay tier, também é criar uma equipe auto-gerenciável, impedir que a empresa vire um museu, permitir que exista opções para solucionar um problema e que a mais adequada seja utilizada, deixar fluir a informação e fazer com que o profissionais se atualizem e utilizem tal conhecimento. Sobre tudo demonstrar que gosta do que faz e passar esse prazer para os outros membros da equipe, estimular para que eles também façam o mesmo.