Uma Pequena Provocação aos Arquitetos

Programação Arquitetura
#81

Mas em momento algum eu disse que arquiteto não programa. O que eu quero dizer é que tem gente que pensa que o arquiteto vai lá fazer uma tela de cadastro de produtos. Mas isso é errado, um arquiteto programaria apenas o que é relacionado a arquitetura da aplicação.
[/quote]

Deixa eu ver se entendi, tem gente que pensa que seu arquiteto poderia ser mais util?

Geralmente vc não precisa de arquiteto pra fazer uma tela de cadastro, mas se arquiteto é um papel e não um cargo, basta tirar o chapeu quando for programar coisas triviais. Me parece que vc tem o privilegio de ser pago pra programar apenas a “arquitetura da aplicação” (seja lao que isto signifique na pratica), neste caso vc devia agradacer seu chefe todo dia.

[/quote]

Uma equipe de 6 profissionais, concordo com você. Agora quando passa dos 40, se o cara ficar programando não faz coaching por exemplo e no mercado, o valor hora de um arquiteto é maior, logo seria um disperdício de dinheiro se ele ficasse programando igual a um programador Sr. e realmente ele terá inúmeras atribuições, pode acreditar.

PS: Dá um pulo em empresas de grande porte como Claro ou Bovespa e espie o dia-a-dia de um arquiteto de lá, vai começar a entender que o buraco é mais embaixo.

PS2: As duas empresas citadas, conheço seus respectivos arquitetos e problemas que caem no colo deles, todo dia.Vai desde Match de operações em tempo real à projetos de Billing para milhões de transações por dia…Aí, não tem tempo mesmo pra fazer qualquer telinha que seja. [/quote]

Então a equipe tem 40 pessoas (!) alocadas no projeto e pra vc desperdício está em 1 arquiteto ficar programando?

O fato de uma empresa ser de grande porte não justifica projetos com 20, 30, 40 pessoas. Nem mesmo o google tem esse monte de gente trabalhando no mesmo projeto. Se esse é o dia-a-dia das empresas citadas eles não servem como exemplo como desenvolvimento de software pra ninguém.

#82

É verdade…

#83

Mas em momento algum eu disse que arquiteto não programa. O que eu quero dizer é que tem gente que pensa que o arquiteto vai lá fazer uma tela de cadastro de produtos. Mas isso é errado, um arquiteto programaria apenas o que é relacionado a arquitetura da aplicação.
[/quote]

Deixa eu ver se entendi, tem gente que pensa que seu arquiteto poderia ser mais util?

Geralmente vc não precisa de arquiteto pra fazer uma tela de cadastro, mas se arquiteto é um papel e não um cargo, basta tirar o chapeu quando for programar coisas triviais. Me parece que vc tem o privilegio de ser pago pra programar apenas a “arquitetura da aplicação” (seja lao que isto signifique na pratica), neste caso vc devia agradacer seu chefe todo dia.

[/quote]

Uma equipe de 6 profissionais, concordo com você. Agora quando passa dos 40, se o cara ficar programando não faz coaching por exemplo e no mercado, o valor hora de um arquiteto é maior, logo seria um disperdício de dinheiro se ele ficasse programando igual a um programador Sr. e realmente ele terá inúmeras atribuições, pode acreditar.

PS: Dá um pulo em empresas de grande porte como Claro ou Bovespa e espie o dia-a-dia de um arquiteto de lá, vai começar a entender que o buraco é mais embaixo.

PS2: As duas empresas citadas, conheço seus respectivos arquitetos e problemas que caem no colo deles, todo dia.Vai desde Match de operações em tempo real à projetos de Billing para milhões de transações por dia…Aí, não tem tempo mesmo pra fazer qualquer telinha que seja. [/quote]

Então a equipe tem 40 pessoas (!) alocadas no projeto e pra vc desperdício está em 1 arquiteto ficar programando?

O fato de uma empresa ser de grande porte não justifica projetos com 20, 30, 40 pessoas. Nem mesmo o google tem esse monte de gente trabalhando no mesmo projeto. Se esse é o dia-a-dia das empresas citadas eles não servem como exemplo como desenvolvimento de software pra ninguém.[/quote]

Normalmente são projetos Correlatos, vide Grupo Sem Parar, que na “nova plataforma” há mais ou menos esse número de pessoas envolvidas, e fui 1 dos arquitetos no primeiro ano.

Outra empresa era a YMF que tinha um software sendo produzido por uma equipe de 20 profissionais. Se justifica ou não, acho que é muito empírico julgar dessa maneira, sem conhecer os fatos.

PS: Bovespa a equipe de Match tem aproximadamente 20 pessoas também, detalhe, levam 8 meses só para preparar um profissional para depois desse período ele de fato começar a produzir, dado a complexidade técnica-negócio.

Só pra fechar, a equipe de desenvolvimento de jogos modernos como Gran Turismo 5 (PS3) está por volta de 150 pessoas. O time que trabalha no produto WebLogic está por volta disso e poderia ficar aqui citando muitos exemplos, que serveriam sim de exemplos e projetos bem sucedidos, mas acho que esse não é o ponto da discussão e sim o papel do arquiteto e creio que coloquei minha posição. Ninguém precisa aceitá-la, apenas é minha ótica e como encaro a função.

#84

Não duvido que existam projetos com essa quantidade de gente alocada, mas é importante ressaltar que nestes casos, o que importa não é a qualidade dos seus programadores e arquitetos, mas sim da capacidade do gerente de bolar um processo capaz de tornar as pessoas em recursos humanos substituíveis. Todos sabem que, a não ser que vc utilize alguma inovação em termos de comunicação (telepatia?), um projeto com mais de 10 programadores provavelmente a dificuldade técnica do problema que eles resolvem é zero. São simplesmente code monkeys cumprindo checklists. Não existe maneira de um líder técnico, por mais competente que seja, dar conta de tanta gente para liderar/guiar, sem falar em ter que garimpar no mercado 10 (30, 40, 150!) profissionais realmente experts.

Dito isso, não entendo porque chamar um “arquiteto com perfil gerencial” de arquiteto ao invés de gerente junior e, CASO NECESSÁRIO, passe a bola da arquitetura para o programador Senior, mas não misture as funções.

[quote=Kenobi]
Só pra fechar, a equipe de desenvolvimento de jogos modernos como Gran Turismo 5 (PS3) está por volta de 150 pessoas. O time que trabalha no produto WebLogic está por volta disso e poderia ficar aqui citando muitos exemplos, que serveriam sim de exemplos e projetos bem sucedidos, mas acho que esse não é o ponto da discussão e sim o papel do arquiteto e creio que coloquei minha posição. Ninguém precisa aceitá-la, apenas é minha ótica e como encaro a função. [/quote]

ps: Alguma referência/link para essas informações da equipe do GT5 e WebLogic?

#85

[quote=mochuara]Não duvido que existam projetos com essa quantidade de gente alocada, mas é importante ressaltar que nestes casos, o que importa não é a qualidade dos seus programadores e arquitetos, mas sim da capacidade do gerente de bolar um processo capaz de tornar as pessoas em recursos humanos substituíveis. Todos sabem que, a não ser que vc utilize alguma inovação em termos de comunicação (telepatia?), um projeto com mais de 10 programadores provavelmente a dificuldade técnica do problema que eles resolvem é zero. São simplesmente code monkeys cumprindo checklists. Não existe maneira de um líder técnico, por mais competente que seja, dar conta de tanta gente para liderar/guiar, sem falar em ter que garimpar no mercado 10 (30, 40, 150!) profissionais realmente experts.
[/quote]

Na verdade não estamos falando de um único profissional para a equipe toda e sim o papel do arquiteto. Talvez nesse caso explicitado seja mais de um ( o mais provável), cada qual cuidando de uma parte específica do problema, seu domínio.

Não vejo como um Gerente poderia conhecer sobre problemáticas técnicas, como latência, escabilidade, segurança e resolver essas questões para sua equipe.

[quote]
ps: Alguma referência/link para essas informações da equipe do GT5 e WebLogic?[/quote]

GTA: http://www.develop-online.net/news/29626/Polyphony-looks-to-PC-game-development#after_ad

Na verdade havia lido em outro site, até detalhava funções, como programdores especializados em física, outros em inteligência artificial, outros em iluminação e por aí vai …

WebLogic, havia ouvido dentro da BEA e com a compra da Oracle soube que aumentaram o quadro, pois dobraram o investimento no produto.

Como disse esse é meu ponto de vista, mas existem outros. Seria legal também ouvir o resto do pessoal do fórum para saber o que acham. Já percebi que temos pontos divergentes e essa discussão não tem condições de prosseguir, ou vai ficar repetitiva…

#86

E qual a diferença entre um gerente e um arquiteto que não programa?

#87

ai tem a pergunta: “Você já viu mestre de obra que antes não foi pedreiro ?”

#88

É mais fácil para o mestre de obra garantir a qualidade do serviço prestado pelos pedreiros sem por a mão na massa. Com relação a software a coisa muda. Um arquiteto que não esta em contato diariamente com o código que esta sendo produzido não esta em condições de garantir a qualidade da arquitetura que ele definiu. Experiência técnica anterior não garante qualidade aqui.

#89

Não.

Mas eu nunca vi um grande cozinheiro que tivesse deixado de cozinhar.

Vc não pode comparar um pedreiro com um programador, um cozinheiro sim… :wink:

#90

[quote=mochuara][quote=Kenobi]
Não vejo como um Gerente poderia conhecer sobre problemáticas técnicas, como latência, escabilidade, segurança e resolver essas questões para sua equipe.
[/quote]

E qual a diferença entre um gerente e um arquiteto que não programa?[/quote]

Eu nunca disse que um arquiteto não deve saber programar, pelo contrário, ele deve fazê-lo e bem !! Mas usando a analogia, seria como uma evolução - pedreiro - mestre de obras - arquiteto - engenheiro (embora arquiteto e engeheiro tenham papéis distintos sei disso, foi só para um exemplo).

Ele pode fazer “coching”, fundição de infraestrutura para a equipe ( como um framework), ensinar como se faz um grid de memória por exemplo com Hadoop - MapReduce para match de operações, Complex Events - EDA, quando e como utilizar e por aí vai. Só não vai ficar no dia-a-dia fazendo “telinha”, “regras de negócio”. Faz uma poc junto à equipe e deixa os caras tocarem o resto.

Ao menos minha idéia e pode olhar o repositório de temos em tempos pra ver como anda a qualidade do design, código, entre outros…

O carinha afundando em regras de negócio, fazendo telas por exemplo, não tem tempo de olhar nada, pois está preocupado em fazer a sua entrega e como disse, quando a equipe aumenta o arquiteto precisa ter um olhar mais de cima.

Pega um exemplo, uma arquitetura SOA por exemplo, deve-se utilizar SOAP + WSDL ou REST + Hypermedia ? Quem vai responder a este tipo de questão, com certeza não é o programador, pois dificilmente eles tem tempo pra se reciclar, estudar ou fazer pesquisas. Se a equipe tiver bons programadores, como citei anteriormente ótimo, dá pra criar um comitê que sou bastante favorável, senão, sobra mesmo pro coitado do arquiteto arcar com todas as decisões e pagar o seu devido preço. Aliás, alguns dizem que a diferença salarial está muito mais na responsabilidade do que no conhecimento técnico.

#91

[quote=Kenobi]
Eu nunca disse que um arquiteto não deve saber programar, pelo contrário, ele deve fazê-lo e bem !! Mas usando a analogia, seria como uma evolução - pedreiro - mestre de obras - arquiteto - engenheiro (embora arquiteto e engeheiro tenham papéis distintos sei disso, foi só para um exemplo).[/quote]

Voce esta confundindo consultor com arquiteto. Consultor não implementa as soluções, enquanto arquiteto que não programa é conhecido como “arquiteto astronauta” (só ve as coisas de longe).

[quote=Kenobi]
Ele pode fazer “coching”, fundição de infraestrutura para a equipe ( como um framework), ensinar como se faz um grid de memória por exemplo com Hadoop - MapReduce para match de operações, Complex Events - EDA, quando e como utilizar e por aí vai. Só não vai ficar no dia-a-dia fazendo “telinha”, “regras de negócio”. Faz uma poc junto à equipe e deixa os caras tocarem o resto.[/quote]

Pra que se preocupar com regras de negócio e experiência do usuário quando pode ficar viajando na ultima tecnologia da “moda” ne?

[quote=Kenobi]
Quem vai responder a este tipo de questão, com certeza não é o programador, pois dificilmente eles tem tempo pra se reciclar, estudar ou fazer pesquisas.[/quote]

:shock: Agora entendi qual o nível dos programadores que vc esta falando.

[quote=Kenobi]
Se a equipe tiver bons programadores, como citei anteriormente ótimo, dá pra criar um comitê que sou bastante favorável, senão, sobra mesmo pro coitado do arquiteto arcar com todas as decisões e pagar o seu devido preço.[/quote]

Bons programadores não podem ter líderes que tomam as decisões de arquitetura (aka arquiteto)? Não entendi essa de comite.

Pode ser. Mas o que isso tem a ver? Estamos discutindo a melhor configuração para um projeto ou quem ganha mais?

#92

E pela sua linha o gerente de projetos seria a evolução do arquiteto/engenheiro… rsrsrs

A Engenharia Civil não é parâmetro de comparação. Ela FOI parâmetro na Idade Média quando os “pedreiros” (maçons) arquitetavam e ao mesmo tempo construíam grandes projetos. A história mudou completamente devido ao alto grau de padronização que foi criado para atender às necessidades da Engenharia Civil. Padronização nos materiais, nas medidas, nos processos e nas ferramentas. Isso permitiu que o Arquiteto pudesse ter uma visão completa do projeto, antes mesmo de que o terreno fosse escolhido. Isso permitiu que o canteiro de obras fosse transformado numa grande linha de produção. Isso permitiu a separação das responsabilidades dos envolvidos no projeto.

Programação ainda é diferente. Programação ainda não é repetitivo. Programação ainda é arte. Vc como artista precisa evoluir. Portanto, precisa continuar praticando a arte e ensinando-a a outros.

Mais uma vez: compare um projeto de software com uma cozinha e não com um canteiro de obras.

#93

[quote=mochuara]

Pior que tb é verdade… :stuck_out_tongue:

#94

Exato, não disse que o Arquiteto não vai programar, ele apenas vai “inventar” os pratos, criar o cardápio, pra isso ele deve saber cozinhar e bem não ? Pode fazer até um prato ou outro, mas não vai ficar cozinhando o dia todo…minha visão vide Alex Atala :slight_smile:

#95

Exato, não disse que o Arquiteto não vai programar, ele apenas vai “inventar” os pratos, criar o cardápio, pra isso ele deve saber cozinhar e bem não ? Pode fazer até um prato ou outro, mas não vai ficar cozinhando o dia todo…minha visão vide Alex Atala :slight_smile: [/quote]

Então vc quis dizer que o engenheiro civil também pega na pá e no martelo, certo? :roll:

#96

Virou papo de boteco, parei por aqui … sem cerveja, não dá :smiley:

#97

Opá. Se quiser combinar, tamos aí.

Mas não me vai falar que programador = pedreiro e que projeto de software = canteiro de obra. Eu só aceito isso depois de tomar umas caixas. :wink:

#98

Opá. Se quiser combinar, tamos aí.

Mas não me vai falar que programador = pedreiro e que projeto de software = canteiro de obra. Eu só aceito isso depois de tomar umas caixas. :wink: [/quote]
A coisa que acho mais estúpida é querer comparar banana com limão. Mas vamos lá:
Existem diversos tipos de profissões e algumas sim, necessitam de experiência prévia antes de sair fazendo. Por exemplo, piloto de avião. Aprende a pilotar um “teco-teco” e vai pegar um jumbo pra ver se vc consegue. Pra mim, se o cara chega a arquiteto sem ter “machucado” os dedos programando, é como pegar um jumbo sem antes ter aprendido a pilotar aviões menores. Vai com certeza ter problemas (se não é na subida, é na descida - piadinha podre :lol: ). Se comparar com medicina, a mesma coisa, ninguém se torna cirurgião chefe antes de ter passado por vários estágios e muitos, mas muitos anos de experiência de atendimentos de primeiros socorros até pequenas cirurgias (e ainda assim, erram).
Claro que vai vir um aqui e dizer: ótimo, são profissões de risco e ambas causariam desastres se não tivesse experiência. Concordo. Mas estou apenas mostrando que comparar um tipo ou outro de profissão não explica as barbáries que vejo.
Também concordo que cada profissão tem sua forma de avaliar um líder, um experiente e um qualquer que acha que é arquiteto.
Aqui neste fórum mesmo percebo que tem gente que busca um status de arquiteto mas que não tem muita noção do que fala se você começa a pressionar. Vivenciou poucos problemas, poucas situações (se é que vivenciou). Logo, falar é fácil, fazer é complicado e explicar a cagada é colocar a culpa no programador. Assim, até eu viro arquiteto, afinal, não precisa saber programar o que está sendo feito, não precisa sentar de vez em quando ao lado do desenvolvedor e lhe apontar erros de patterns e problemas que aquela forma de codificar podem causar ao longo do processo do software e da sua vida útil. Basta mandar fazer e se estiver errado, a culpa não é minha, não é verdade?

#99

Opá. Se quiser combinar, tamos aí.

Mas não me vai falar que programador = pedreiro e que projeto de software = canteiro de obra. Eu só aceito isso depois de tomar umas caixas. :wink: [/quote]
A coisa que acho mais estúpida é querer comparar banana com limão. Mas vamos lá:
Existem diversos tipos de profissões e algumas sim, necessitam de experiência prévia antes de sair fazendo. Por exemplo, piloto de avião. Aprende a pilotar um “teco-teco” e vai pegar um jumbo pra ver se vc consegue. Pra mim, se o cara chega a arquiteto sem ter “machucado” os dedos programando, é como pegar um jumbo sem antes ter aprendido a pilotar aviões menores. Vai com certeza ter problemas (se não é na subida, é na descida - piadinha podre :lol: ). Se comparar com medicina, a mesma coisa, ninguém se torna cirurgião chefe antes de ter passado por vários estágios e muitos, mas muitos anos de experiência de atendimentos de primeiros socorros até pequenas cirurgias (e ainda assim, erram).
Claro que vai vir um aqui e dizer: ótimo, são profissões de risco e ambas causariam desastres se não tivesse experiência. Concordo. Mas estou apenas mostrando que comparar um tipo ou outro de profissão não explica as barbáries que vejo.
Também concordo que cada profissão tem sua forma de avaliar um líder, um experiente e um qualquer que acha que é arquiteto.
Aqui neste fórum mesmo percebo que tem gente que busca um status de arquiteto mas que não tem muita noção do que fala se você começa a pressionar. Vivenciou poucos problemas, poucas situações (se é que vivenciou). Logo, falar é fácil, fazer é complicado e explicar a cagada é colocar a culpa no programador. Assim, até eu viro arquiteto, afinal, não precisa saber programar o que está sendo feito, não precisa sentar de vez em quando ao lado do desenvolvedor e lhe apontar erros de patterns e problemas que aquela forma de codificar podem causar ao longo do processo do software e da sua vida útil. Basta mandar fazer e se estiver errado, a culpa não é minha, não é verdade?

[/quote]

Sem falar que, independente do avião, as leis da fisica que permite algo levantar voos são sempre as mesmas. Da mesma forma o funcionamento de um rim ou coração é sempre o mesmo entre diferentes pessoas e até mesmo outras especies. O mesmo não pode ser dito de programadores de software que podem lidar com domínios completamente diferentes a cada novo projeto (e até inventar novos domínios!).

Esse é o problema de quem defende regulamentação da profissão, eles não entendem que o mundo da TI não se resume a aplicações web e ERPs.

#100

Gostaria de dizer que não tenho nada contra o processo descrito pelo Kenobi, apenas discordo que um gerente deva ser chamado de arquiteto só porque foi programador alguma vez no passado.