Arquitetura like wataaaaa, participação especial de Bruce Lee e outros ninjas

(Sexta-feira, então vai começar com uma sátira, mas vc tem que prometer que vai se esforçar para imaginar a cena.)

Entra na sala de desenvolvimento um maluco vestido de ninja segurando um pedaço de papel. Na luz fica claro que o pedaço foi arrancado dos pergaminhos sagrados do Lean startup.

fullEle apoia as costas na parede e com as pontas dos dedos vai se movendo, in-vi-sí-vel e silenciosamente, na direção do project owner. Para evitar chamar a atenção dos desenvolvedores ele usa toda sua mana em uma técnica ninja de invisibilidade “Quando os devs virem o novo requisito eles não saberão de onde veio”.

Os dois conversam durante um tempo entre gestos amenos e outros mais efusivos. O PO faz sinal com o indicador chamando o arquiteto.

E ai, o que acha? pergunta para o arquiteto.

Aqui existem duas versões do diálogo. O arquiteto diz que foi “Manda ela aqui que vamos conseguir dar suporte com o design atual”, mas os ninjas que estavam em volta juram pelas suas Hattori Hanzō que o que foi dito foi algo mais emblemático, dizem que foi “be like wataaaaaa!!!”.

E eu pergunto:

Será possível que uma arquitetura de software seja como água? Que exista uma arquitetura que assume a forma de onde for colocada?

Vamos inverter essa pergunta:

Na arquitetura em que você trabalha todos os dias qual é a resistência a novas funcionalidades

Vamos definir resistência. Ela é zero quando um requisito pode ser adicionado ao software sem redesign e é 1 quando um redesign do domínio principal é necessário.

Para fins de comparação, a água tem resistência zero ao “tomar a forma do recipiente em que é colocada”.

Quando um requisito entra num software com zero de resistência é por que ele havia sido planejado, reflexo de um arquiteto e um time que fizeram um bom trabalho entendendo o domínio e sua mecânica de negócios. É provável também que um especialista de domínio tenha participado das discussões de design e ainda esteja no time, como um contato permanente entre código e mundo real.

Um dos riscos de tentar ter um arquitetura com essa característica é que na tentativa de estar sempre à frente o arquiteto pode cair na armadilha do Overengineering, gastando tempo e dinheiro em coisas que serão utilizadas depois de muito tempo ou mesmo que nunca chegarão  a ser utilizadas, mas que impactam na complexidade do software.

Agora, se a resistência não é zero podemos utilizar o valor da resistência para ouvir algo sobre o design do software.

Uma resistência de 0.1, ou seja, muito baixa, como quando o desenvolvedor entende que vai precisar de um refactoring para transformar um trecho de código para trabalhar com uma coleção, aponta que a arquitetura é totalmente aderente a negócios e é capaz de suportar o modelo de pensamento existente.

Um novo requisito não coberto por uma arquitetura mas que apresenta uma resistência baixa para ser implementado diz que a equipe está fazendo o melhor trabalho possível com o conhecimento, o dinheiro, o tempo e os desenvolvedores disponíveis.

No outro extremo, uma resistência 1.0 , muito alta, aquela que exige um refactoring total da arquitetura.

Essa situação indica uma mudança brusca nas diretrizes de negócio, ou um erro de interpretação do domínio, quer seja por falta de informação ou má compreensão.

900069Dentre as situações que levam a essa situação esta aquela onde a equipe de desenvolvimento sofre pressão para trabalhar muito mais rápido que possível. Veja, pressão é natural, mas a pressão por resultado daquele tipo que cobra código e impede a equipe de pensar não é natural.

.

Outra situação é quando a empresa se reposiciona no mercado. Ontem ela era um pet-shop e hoje ela se tornou uma empresa de logística de produtos veterinários.

Não tem arquitetura que se encaixe bem nos dois mundos e se o código se adaptar a essas duas situações é sinal de que não existe arquitetura e provavelmente você está gastando 100 horas para fazer algo que deveria ser feito em 4.

É uma questão de escolha. O que você prefere, ter a sensação de que está avançando ou realmente estar avancando?

Alguns profissionais se satisfazem com a sensação de que está difícil de dar cada passo, mas ele é um campeão e está avançando, de maneira cara mas está. Outros preferem pensar que isso é um exercício de rolar uma pedra morro acima só para vê-la escorregar e ter de começar tudo de novo e não gostam do apelido de Sísifo.

Outra coisa que devemos ter em mente é que arquitetura de software é dinheiro.

O custo de desenvolvimento do software para realizar negócios é pesado. Se a resistência da arquitetura é alta a empresa oportunidades de negócio, perde dinheiro em horas de trabalho desnecessárias, perde programadores e arquitetos que não vão considerar esse um trabalho gratificante e outras coisas mais.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s