Fork me on GitHub

Keep Learning Conhecimento nunca é o bastante

Postado em
4 November 2009 @ 11:16

Tag(s)
Agile, Desenvolvimento, Opinião

Desenvolvedor, arquiteto, programador, engenheiro…

É realmente necessário ter equipes de arquitetura separadas de equipes de desenvolvimento? Essa pergunta é muito antiga e cada um tem uma resposta. Pra mim, não. Mas vamos pensar mais sobre isso.

Em primeiro lugar, o que é um arquiteto de software? É um desenvolvedor com muito conhecimento e experiência (minha resposta)? É um profissional diferente, especificamente treinado para a arquitetura de sistemas? É alguém que possui algum “dom” especial?

O cargo de “Arquiteto de Software” como empregado hoje na indústria do software é mais uma herança ruim da comparação entre desenvolvimento de software e construção civil. Nesta última, o arquiteto faz o projeto mas, em geral, não suja as mãos no cimento. O ponto é: arquitetar um sistema de software é ou não é fundamentalmente diferente de construir software, isto é, programá-lo, testá-lo e mantê-lo? Não. Existem algumas diferenças e algumas preocupações diferentes mas é impossível dissociar as atividades no nível em que é feito em outras áreas.

Um fato interessante é que apenas empresas grandes, com orçamentos folgados (que, em geral, desperdiçam tempo e dinheiro com futilidades e becos sem saída) costumam oferecer o cargo de arquiteto de software. Eles geralmente ficam em equipes de arquitetura, longe das equipes que “sujam” as mãos no código no dia-a-dia. Ora, isso, por si só, cria as Torres de Marfim e uma certa animosidade latente entre as diferentes equipes – que deveriam trabalhar em conjunto todos os dias.

Não faz sentido (e não é eficiente) ter equipes de arquitetura separadas, sem contato direto e constante com as equipes de desenvolvimento. Também não faz sentido empregar arquitetos de software que só planejam e não participam da execução diariamente.

Usando a já batida metáfora do desenvolvimento de software como jardinagem é fácil perceber que estamos longe do processo utilizado, por exemplo, na construção civil ou na indústria automobilística. Não é possível projetar todo o software com antecedência, como um prédio ou um carro, comprar a matéria-prima, contratar os operários e implementá-lo praticamente sem desvios. O projeto é o software e o software é o projeto.

Podemos, sim, ter um plano geral, um conjunto de guias e processos a serem seguidos, interfaces definidas, padrões e tudo mais, mas é preciso adaptação rápida à mudança. Na criação (e não construção, isso é importante) de um jardim, uma planta pode não se desenvolver por um entre vários fatores. Na criação de software, uma especificação da equipe de arquitetura pode não se encaixar nas necessidades do projeto.

Se houver uma “equipe de arquitetura” como uma entidade especial, separada, perde-se muito tempo para reagir às mudanças. Se os arquitetos são do tipo que se acha bom demais pra se sujar na programação as conseqüências são ainda piores – em primeiro lugar porque eles não tem noção da realidade do projeto enquanto fazem os planos e, em segundo, porque tendem a resistir à mudanças no que consideram um plano perfeito.

Se insistíssemos em utilizar a metáfora da construção civil, podemos comparar todo o ciclo de desenvolvimento de software com o ciclo de arquitetura e projeto de um edifício, excluindo sua construção. O desenvolvimento de software é uma atividade criativa, não “mecânica”.

Um desenvolvedor de software que não se atenta à arquitetura, que não tenta melhorar nos fundamentos básicos necessários ao entendimento do software como um todo, não passa de um programador – um mero codificador, facilmente substituível.

Um arquiteto de software que não programa, não se envolve com o dia-a-dia da produção de software e não se interessa pelos outros aspectos da disciplina, não passa de um “masturbador mental de software“. Daí para o que os americanos chamam de “Death by PowerPoint” leva um piscar de olhos.

Sim, é necessário que tenhamos a figura do “líder técnico”, aquele desenvolvedor com bastante experiência e jogo de cintura, que já viu e já fez de tudo na área. Ele, inclusive, pode ter o cargo formal de arquiteto de software. O que não pode acontecer é que ele seja um profissional isolado em uma esfera de cristal, um “deus” criando o que ele pensa ser adequado, dando ordens e ignorando eventuais questionamentos de sua intocável arquitetura. Isso é tudo o que um time de verdade não precisa.

Em resumo, um bom desenvolvedor é também um bom arquiteto. E um bom programador. E um bom qualquer coisa que seja necessária para criar software consistentemente.


7 Comentários

Comentário por
Alberto Leal
4 November 2009 @ 12:06

Interessante o seu ponto de vista.
Mas, afirmar que: “[…]um bom desenvolvedor é também um bom arquiteto[…]” não é uma verdade absoluta. Existem ótimos desenvolvedores que não conhecem SOA, ESB, REST, DDD, quando e onde aplicar Padrões de Projeto, enfim…Daí, montar uma arquitetura para uma aplicação de médio e/ou grande porte não se torna algo tão trivial.
Concordo quando você diz que, arquitetos devem trabalhar junto aos desenvolvedores. E que, os melhores arquitetos são desenvolvedores com muita experiência e que já viram de “tudo”.

Abraços,
Alberto


Comentário por
Lucas Húngaro
4 November 2009 @ 12:25

Alberto, realmente não é algo absoluto. Refazendo a afirmação: acredito que, no mínimo, um bom desenvolvedor precisa querer ser um bom arquiteto.


Comentário por
Roger Leite
4 November 2009 @ 14:51

Aê Lucas! Belo post! Concordo plenamente, e tenho certeza que da onde vocẽ tirou “inspiração” para este post, continua a mesma coisa.

Sem novelas mexicanas e voltando a código!

Sucesso!


Comentário por
Lucas Húngaro
4 November 2009 @ 15:14

Roger, com certeza! O que aconteceu antes foi totalmente acidental e não deve se repetir, a gente aprende, né?

Obrigado pelo apoio! 🙂


Comentário por
Robson Chikasawa
13 November 2009 @ 14:38

Lucas, cheguei aqui no seu post através do blog do Ronaldo
http://logbr.reflectivesurface.com/2009/11/09/a-pratica-de-arquitetura/ , que por sinal quero parabenizá-lo pelo ótimo post!
A interação entre as partes no desenvolvimento do software é essencial. Muito das coisas boas que acontece, são as trocas de experiências. Não apenas o desenvolvedor aprende com a arquitetura mas como o inverso tbm é verdadeiro.

Abraços!


Comentário por
O melhor da semana 15/11 a 21/11 « QualidadeBR
22 November 2009 @ 19:32

[…] Desenvolvedor, arquiteto, programador, engenheiro… – Lucas Húngaro (Keep Learning); […]


Comentário por
sergio Saad
23 September 2010 @ 7:59

A futilidade da nomenclatura, a frescura academica querendo superar a praxis comercial, em vez de melhora-la.
Programadors (junior, pleno, senior)
Analistas (sistema, negocio)
Gerentes,
Diretores,
Presidente

Arquitetura mais para plataforma

E desenvolvimento mais para pessoa juridica que para fisica, pois quem desenvolve é o conjunto, nao um individuo, e sim uma equipe.

Como a area é nova um monte de “especialistas” quer fazer analogias, neste ponto concordando com o artigo, e misturar construcao civil com TI.

Muito achismo e pouco trabalho.


Deixe um comentário