É correto afirmar que

E essa comparação é desmerecedora para você?

Se for pensar de maneira bem preto e branco, eu diria que sim.
O programador é o peão, o analista é o engenheiro e o arquiteto é, bem, o arquiteto.

Mas na minha sincera opinião, na área de desenvolvimento de software essas “linhas” são mais turvas, acontece de em determinados casos, uma determinada pessoa exercer mais de uma função. Talvez um pouco de todas (dependendo da aplicação).

Eu nunca achei muito certo comparar desenvolvimento de software com construção civil, pois apesar de existirem similaridades, as funções são bem diferentes na prática. (Pelo menos é o que eu penso, pois nunca trabalhei com construção civil).

Mas se for pensar no “peão” como o cara que faz, onde a consistência de uma parede, depende do bom trabalho dele, não vejo isso como uma comparação desmerecedora.

E quando às linhas turvas entre funções, uma boa leitura é a teoria dos DevOps

Não digo desmerecedora de maneira alguma tanto é que peão de obra trabalha honestamente e com seus recursos, mas digo de que o programador não ser o topo da piramide, que era um equivoco que eu achava.

Vlw pelo teu esclarecimento.

Cara eu não classifico a grosso modo deste maneira, porém se você for comparar como você mesmo disse “peão de obra”, ao comparar com uma empresa de eng civil, lá você tem um cliente, um engenheiro e os pedreiros, onde, na nossa área, a meu ver, o cliente é igual pra todos, os analistas são os engenheiros e os programadores os pedreiros, claro que isso não é a forma correta de se analisar, mas como você mesmo disse, se for comparar a “peão d eobra”, da pra fazer essa analise sim.

Sua pergunta é muito abstrata,tem programadores monkey considerados piões e tem os fazem arte.
Quer um exemplo bem simples olha p/ o projeto jogos olímpicos os caras q criaram.

Não.

Em primeiro lugar, está caindo o modelo de que o analista, projetista e programador são pessoas diferentes. Geralmente, eles são a mesma pessoa e o que muda é apenas a fase do projeto que estão.

Depois, você constroi um software enquanto os requisitos mudam. Se programadores fossem pedreiros, seriam nessas condições:
[youtube]http://www.youtube.com/watch?v=UZq4sZz56qM[/youtube]

Finalmente, a analogia também é grosseira pq vc não tem pequenas peças que podem ser montadas em software. Você constrói essas peças. Então, é como se esses pedreiros fossem capazes de fazer seus tijolos, sua argamassa e vários outros itens de construção, além de construir o prédio.

Essa analogia traz o perigo de achar que, com um bom analista e com um bom engenheiro, um programador é um item plenamente substituível. Não é bem assim, pois, embora seja mesmo um cargo operacional, é também um cargo intelectual. E, certamente, um bom programador é muito mais caro de substituir do que um excelente pedreiro.

pelo pouco que entendo da parte de construção civil, acredito que a diferença seja que o “peão” do desenvolvimento de software não é só a mão de obra operacional, este operacional depende quase que exclusivamente do intelectual, o que diferencia muito do “peão” da construção civil, não que não tenha o lado intelectual, existe um como fazer por exemplo, técnica, mas isso depende muito de habilidade manual em contrapartida do programador que depende muito do raciocínio lógico… é como o que o vinigodoy disse… é o que o vinigodoy disse…

eu sou leigo mas imaginava que fosse o contrário… sempre imaginei que o engenheiro mais voltado a um conhecimento mais técnico, mais voltado ao calculo do que o arquiteto, enquanto que em contrapartida o arquiteto pegue mais no lado do design que o engenheiro… com isso eu associo o engenheiro da construção civil ao arquiteto de software e o arquiteto da construção civil ao analista…

O desenvolvimento de software já sofreu demais com essa analogia … Na boa mesmo, não vale nem a pena discutí-la.

Aliás, isso fica nítido no despreparo de muitos gerentes de projetos. A maioria dos MBA’s em GP são baseados no PMBOK, e pelo jeito, os cases mais usados advém da engenharia civil. O desastre ocorre justamente quando os tais gerentes tentam aplicar exatamente as mesmas práticas de engenharia civil na construção de software …

Nada contra o PMBOK, mas o fato de um conjunto X de práticas funcionarem com engenharia civil não quer dizer que funcionarão com outras áreas … Porque ninguém faz analogia de construção civil com marketing por exemplo ? Será que marketing é uma área que não aceita gerência de projetos ou os projetos de marketing tem projetos com características únicas ? Não seria o mesmo caso do desenvolvimento de software ?

Assim, da mesma maneira que é inócuo comparar engenharia civil com desenvolvimento de software, é inútil também ficar comparando os papéis de uma obra com uma equipe de desenvolvimento. Até mesmo dentro do desenvolvimento de software é complicado fazer esse tipo de comparação, será que uma equipe que desenvolve portais de conteúdo deve ter os mesmos papeís que uma equipe que desenvolve software corporativo ?

Concordo com o vini, muito embora em um passado bem remoto o pedreiro provavelmente também construía os tijolos utilizando uma mistura de barro com outras coisas ou pedras recortadas mas é outra questão.

Esta ideia surge quando tentam encaixar as profissões nos modelos de administração utilizados nas industrias (independente do que seja); dai surgem estas deformidades, ainda mais se tratando de uma profissão tão nova e diferenciada como estas ligadas ao processamento de dados.

Ver um programador como pedreiro não é demérito; pois esta profissão (pedreiro) é milenar e muito importante porem muito desvalorizada por outros e principalmente por quem é “profissional”. O problema é que fica difícil ser um bom programador se ele não tiver uma visão / capacidade mais abrangente, os mesmos recursos intelectuais utilizados pelos analistas são utilizados pelos programadores a diferença são os contextos. A partir disto surgiu uma coisa como “um bom programador certamente será um bom analista”, isto já gerou muita discussão aqui no fórum porem é passível de reflexão.

flws

É correto aformar que…
Se formos comparar um ônibus Espacial com um caminhão os Engenheiros da NASA são os mecânicos? e Astronautas caminhoneiros?

Você programa na linguagem mais popular do mercado e não quer ser peao de obra?

Faz sentido… NOT!

jonathan Coelho:

É correto aformar que…
Se formos comparar um ônibus Espacial com um caminhão os Engenheiros da NASA são os mecânicos? e Astronautas caminhoneiros?

outra também seria comparar um mecânico de vila com um de fórmula 1 (que deve ganhar como mecânico muito mais que a maior parte dos engenheiros)… isso não significa que ser peão seja ruim! Significa que ser operacional pode ser muito bom também (embora esta seja a excessão, acredito que em TI esta virando regra)!

Porém… isso foi uma coisa construida na década de 70, onde os analistas praticamente entregavam a lógica do programa toda especificada e os programadores só transformavam isso em código que a máquina entendesse!
Por incrivel que pareça ainda tem fabrica de software que trabalha desta forma!
Hoje como já falaram a realidade é meio diferente, não tem muito essa de analista e programador…

[ironic mode:on]
porém acho que cada dia que passa tem mais programador próximo ao peão de obra (aqueles toscos e não os competentes), mas não o que faz a obra que o engenheiro planejou e sim aquele que faz a obra inteira na sua casa!!! Que sai fazendo no “deixa comigo”… e a qualidade do serviço, já sabe né!
[ironic mode:off]

e você acha que “mecânico” de fórmula 1 não é engenheiro também ?

rmendes08:

outra também seria comparar um mecânico de vila com um de fórmula 1 (que deve ganhar como mecânico muito mais que a maior parte dos engenheiros)… isso não significa que ser peão seja ruim! Significa que ser operacional pode ser muito bom também (embora esta seja a excessão, acredito que em TI esta virando regra)!

e você acha que “mecânico” de fórmla 1 não é engenheiro também ?

Exatamente! Esse é ponto!!! Um bom programador não é aquele que só sabe escrever código!!! O que significa que fazer o serviço operacional (seja escrever código ou consertar carro) seja uma coisa de peão e/ou ruim!

Vamos chama-lo então de desenvolvedor ??? ou até mesmo o nome que muita gente não gosta “analista programador” ??

Faz diferença do que é chamado se tudo que você faz é ficar num cubiculo implementando diagramas UML?

jmmenezes:

rmendes08:

outra também seria comparar um mecânico de vila com um de fórmula 1 (que deve ganhar como mecânico muito mais que a maior parte dos engenheiros)… isso não significa que ser peão seja ruim! Significa que ser operacional pode ser muito bom também (embora esta seja a excessão, acredito que em TI esta virando regra)!

e você acha que “mecânico” de fórmla 1 não é engenheiro também ?

Exatamente! Esse é ponto!!! Um bom programador não é aquele que só sabe escrever código!!! O que significa que fazer o serviço operacional (seja escrever código ou consertar carro) seja uma coisa de peão e/ou ruim!

Vamos chama-lo então de desenvolvedor ??? ou até mesmo o nome que muita gente não gosta “analista programador” ??

acho que nada se compara à prática de algumas empresas, entregam o crachá apenas com o nome e o cara preenche com o cargo que quer …

AAA essa é facil pq estamos em um forum de programação e não em um forum de marketing??

Oi, boa tarde.

Nossa pessoal, que discussão mais sem sentido… kkkk…

Concordo com o Vini… hoje em dia, cada vez mais os papéis se misturam e o que muda são as fases em que o projeto está, ou seja: você pode ser o analista, depois o projetista, depois o arquiteto, depois o desenvolvedor e até o implantador, dependendo do caso…

Abraço,

[ironic mode: on]
Não perca, amanhã, no Guj Repórter: A vida das baratas sem asas do Himalaia e o seu significado para o desenvolvimento java.
Java e o corpo humano, seriam os programadores os glóbulos brancos ou os glóbulos vermelhos?
[ironic mode: off]
Qual a razão para uma analogia como esta?
Qual o ganho obtido após pensar a respeito de um tema cuja finalidade é nenhuma?
Sinceramente, deveríamos nos preocupar mais em estudar, trabalhar ou viver a vida que pensar em coisas como esta.

drsmachado:

[ironic mode: on]
Não perca, amanhã, no Guj Repórter: A vida das baratas sem asas do Himalaia e o seu significado para o desenvolvimento java.
Java e o corpo humano, seriam os programadores os glóbulos brancos ou os glóbulos vermelhos?
[ironic mode: off]
Qual a razão para uma analogia como esta?
Qual o ganho obtido após pensar a respeito de um tema cuja finalidade é nenhuma?
Sinceramente, deveríamos nos preocupar mais em estudar, trabalhar ou viver a vida que pensar em coisas como esta.

o problema disso é que as pessoas gostam de usar de coisas assim para diminuir outras e desvalorizar… é especialmente neste desvalorizar que mora o problema…

A diferenca entre analista e programador é perfil, nao hierarquia.

Existem pessoas que gostam mais de desembaraçar nós, correr atrás de coisas de baixo nível, ganhar alguns segundos de performance com um algoritmo melhor, criar framework para facilitar o seu trabalho. Estes são os programadores. Eles podem nao gostar muito de ficar coletando requisitos, resolvendo probleminhas corriqueiros do cliente e etc. Mas se precisar eles sabem fazer tambem, porque conhecem bem a teoria.

Existem pessoas que gostam de automatizar processos, aprender os detalhes da forma como o cliente trabalha, escrever solucoes em cima delas. Resolver o problema do dia-a-dia do usuario. Nao sao la grandes fãs de ficar “escovando bit” e entendo os minimos detalhes de funcionamento de uma maquina virtual. Estes são os analistas. Eles podem não gostar de inovar em solucoes tecnicas ou de passar a noite fazendo uma placa “cantar” com codigo assembly, mas eles sabem, e muito bem, utilizar uma linguagem de programação para resolver os problemas dos seus usuários.

Analistas que não programam, ou programadores que não sabem modelar são aberrações que já deveriam ter deixado de existir faz tempo.

Só quem quer jogar dinheiro fora vai pagar duas pessoas quando uma só resolveria o problema, mas parece que muita gente tem vontade de atirar dinheiro pela janela.

Se quer uma comparacao com a construcao civil, muito melhor seria: analistas/programadores são os engenheiros que no código desenham o produto final. O compilador é o pedreiro que lê o projeto e o transforma no produto propriamente dito (faz o build).

++

Obs: Não vejo nenhum problema com o peão de obra aliás ele é fundamental… :roll:

Descobrir a piramide hierarquica das coisas!!!

Descobrir a piramide hierarquica das coisas!!!

Porque você n vai estudar ou trabalhar ou viver a vida invez de responder um topico “inutel” (julgado por você deus da programação) ??

Grato.

A questão é que, do ponto de vista da dignidade, pedreiro é uma profissão tão digna quanto programador.
Já do ponto de vista da grana e da degradação à qual a profissão submete, sim, é pejorativo.

E concordo plenamente com o YvGA, há pessoas com perfil voltado à análise e outros voltados ao desenvolvimento. Como há profissionais da construção civil que não se tornam pedreiros, mas, mestre de obras e outros que preferem se manter como pedreiros.
O que eu acho nefasto é permitir-se a tais analogias. Me cheira a preconceito.
E volto a perguntar, qual a razão para isto? O que se ganha com isso?

Volto a responder!!!

Descobrir a piramide hierarquica das coisas!!²²²²²²

Descobrir a piramide hierarquica das coisas!!!

Descobrir a piramide hierarquica das coisas!!!

Porque você n vai estudar ou trabalhar ou viver a vida invez de responder um topico “inutel” (julgado por você deus da programação) ??

Grato.

e quem disse que existe uma hierarquia ? cada empresa divide cargos e papéis da maneira como bem entende … é impossível dizer quem está certo ou quem está errado, mas o fato é que as metodologias modernas se preocupam cada vez menos com papéis, ao invés disso, é mais interessante saber quais práticas contribuem para melhorar a qualidade do software (entre outras coisas …)

samuelM:

se formos comparar um projeto com uma obra o programador seria o peão de obra?
Desculpe minha ignorançia mas é o que transparece ser. me iludam por favor pois amo programar.

Geralmente não, mas acontece. Se vc pega um projeto já PRONTO onde vc só vai dar manutenção no sistema e criar outros módulos, daí fica parecido com peão mesmo. Claro que há peões bons e peões ruins. Uns tem mais habilidade com a pá.

Agora se vc começa um sistema do zero, aí vc tem que ser peão, arquiteto, projetista e calculista ao mesmo tempo. Nem sempre é possível obter um emprego assim, logo sugiro mergulhar em open source quando o seu emprego não lhe permite essa conjunção de cargos. É o famoso “re-inventar a roda”, que alguns bobocas sempre criticam.

samuelM:

Volto a responder!!!

Descobrir a piramide hierarquica das coisas!!²²²²²²

Entao voce deveria deixar a area privada e se dedicar a carreira militar. La sim, eles dao valor a hierarquia.

No setor privado, embora ainda haja uma predominancia de valorizacao da hierarquia, isso cada vez mais tem se mostrado menos eficiente que a colaboracao entre membros com habilidades diferentes.

Ainda que quisesse voce nao conseguiria colocar analista e programador e linha hierarquica porque eles sao exatamente mesma pessoa. Se o que voce almeja é se tornar um analista sem precisar aprender a programar, pode tirar o cavalo da chuva, voce nao tem a menor chance disso.

Muito pelo contrario sou programador e quero me tornar analista

Hierarquias, por excelência, são modelos ultrapassados, social e administrativamente. É coisa herdada de religião e belicismo, onde só por que um sujeito possui uma insígnia ou título melhorzinho, deve ser tratado como superior, mesmo sendo um completo e absoluto decrépito.
É a fonte do pensamento segregador, que diz que brancos são melhores que negros, que diz que homens são superiores às mulheres, que diz que o presidente é mais importante que o povo.
O que, ainda a passos lentos, está sendo percebido é que a meritocracia é fundamental para a evolução. E esse princípio não é novo, tem quase duzentos anos que os comunistas já consideravam isso importante.
É óbvio que mudar esse pensamento, por completo, depende de um fator muito importante, a educação. Quando todos forem suficientemente educados e conscientes, a ponto de entender que diferenciar alguém por seu cargo ou roupas é um equivoco, talvez isso seja o padrão social.
As empresas nada mais são que reflexos de culturas. Donos, presidentes, gerentes, diretores, executivos, tios(as) da limpeza, do café, estagiários, pedreiros, carpinteiros, programadores, analistas são, simplesmente, peças que visam manter a engrenagem do negócio funcionando.
Especificamente em nosso meio, essa divisão hierárquica é tão ou mais confusa que chega a ser uma piada. O gerente de área está, hierarquicamente, acima do gerente de projetos, mas deve reportar ao PMO. O PMO está abaixo da gerência regional, mas é responsável por aprovar ou não projetos que vem desta gerência.
Um analista é contratado como programador sr. Um jr valida a documentação e desenvolve o design do projeto e corrige casos de uso.
Que estrutura hierárquica queremos? O modelo indiano? não, obrigado.

drsmachado:

maior_abandonado:

o problema disso é que as pessoas gostam de usar de coisas assim para diminuir outras e desvalorizar… é especialmente neste desvalorizar que mora o problema…

A questão é que, do ponto de vista da dignidade, pedreiro é uma profissão tão digna quanto programador.
Já do ponto de vista da grana e da degradação à qual a profissão submete, sim, é pejorativo.

E concordo plenamente com o YvGA, há pessoas com perfil voltado à análise e outros voltados ao desenvolvimento. Como há profissionais da construção civil que não se tornam pedreiros, mas, mestre de obras e outros que preferem se manter como pedreiros.
O que eu acho nefasto é permitir-se a tais analogias. Me cheira a preconceito.
E volto a perguntar, qual a razão para isto? O que se ganha com isso?

concordo com tudo o que você disse, em especial em cheirar a preconceito… e respondendo a sua pergunta, a questão não é o que se ganha, mas sim o que se perde… e quem perde… é ai que está o problema…

tinham falado de hierarquias… isso é um problema comum no mercado, em grande parte das empresas o “analista de sistemas” não só tem um nível hierárquico maior que o programador como também tem uma “consideração” maior da empresa, esse termo para se referir ao programador, não digo isso como tendo algo contra o peão de obra, o que tenho contra é o intuito de usarem essa expressão, justamente de forma pejorativa, é ai que ta o problema…

digaoneves:

E essa comparação é desmerecedora para você?
Mas na minha sincera opinião, na área de desenvolvimento de software essas “linhas” são mais turvas, acontece de em determinados casos, uma determinada pessoa exercer mais de uma função. Talvez um pouco de todas (dependendo da aplicação).

Exatamente por isso não faz sentido essa história de peão,engenheiro etc.

Não creio que o problema esteja no conceito de hierarquia e sim nas pessoas que as aplicam.

Eu não sou maior nem menor que ninguém por ser um programador.

Sou programador porque gosto e quero morrer fazendo isso, que se exploda quem não gostar, é o que eu quero fazer.

O grande fato é, o mundo evolui ao seu ritmo. Hierarquias sempre existirão no mundo capitalista, isso não tem jeito. O que vai evoluir e as empresas em breve perceberão (muitas já perceberam e já mudaram sua forma de agir) é que são compostas por humanos e todos os papéis são de alguma forma cruciais.

Tratar o teu funcionário fazendo-o trabalhar pra ti de forma motivada e feliz será o foco ao invés de fazer o cara trabalhar com medo de ser demitido.

Porém, a hierarquia sim, essa sempre existirá e é necessária, só precisa evoluir.

Abs[]

Gente, que linhas turvas são essas?

Toda empresa que eu passei os papeis eram claramente distintos, analistas eram responsaveis por criar o sistema usando UML, e os programadores implementavam no codigo.

Repare que não estou dizendo que isso é certo ou errado, ideal ou desperdício, apenas o que presenciei, por isso acho a comparação valida.

Botocudo:

Gente, que linhas turvas são essas?

Toda empresa que eu passei os papeis eram claramente distintos, analistas eram responsaveis por criar o sistema usando UML, e os programadores implementavam no codigo.

Repare que não estou dizendo que isso é certo ou errado, ideal ou desperdício, apenas o que presenciei, por isso acho a comparação valida.

O que está se querendo dizer é:Não existe uma discrepância intelectual tão grande entre as atividade de analista e arquiteto(ou entre quaisquer outras funções em desenvolvimento de software) que justifique essa divisão.

É claro que num projeto é comum pessoas exercerem essa ou outra atividade,mas não significa que só devam ou só saibam exercer essa atividade.A multidisciplinaridade é muito bem-vinda.

Botocudo:

Gente, que linhas turvas são essas?

Toda empresa que eu passei os papeis eram claramente distintos, analistas eram responsaveis por criar o sistema usando UML, e os programadores implementavam no codigo.

Repare que não estou dizendo que isso é certo ou errado, ideal ou desperdício, apenas o que presenciei, por isso acho a comparação valida.

mas aí você está tomando sua experiência como regra geral não é bem assim …

Como eu disse, cada empresa faz de um jeito, e entre os dois extremos existe um largo espectro de possibilidades. Agora, pelo que eu leio (e vivencio) ultimamente, existe uma grande tendência em suavizar as hierarquias nas empresas. Pelo menos nas empresas em que o seu produto/serviço depende majoritariamente de capital intelectual.

Tem aqueles programadores que viram analistas que não programam (bicho em extinsão) e consideram que foram promovidos!
E pensam que se tiverem que voltar a programar mesmo tendo o título de analista, isso para eles será um desmérito!!

Já cansei de ver isso… parece que programar é algo “vergonhoso” para algumas dessas pessoas… tipo limpar o chão!

Bonito mesmo foi quando eu vi um gerente totalmente estratégico, reclamando do serviço tosco, pegar o sistema que o povo da empresa prestadora tinha demorado 1 mês para fazer, chegar no final de semana, reimplementar tudo e deixar funcionando redondo na segunda feira… nem preciso dizer que ele deu adeus aos contratos com essa empresa!

Isso foi um pouco de culpa de nossos ancestrais programadores também…

Pense que não muito tempo atrás (alguns até bastante recente) nossa classe adorava se colocar no papel de codificadores puros. Como amigo escreveu em outro post, esses caras faziam questão de não ter o menor contato com negócio, eles não sabiam e nem queriam saber como funcionava o negócio para o qual estavam desennvolvendo aquele Sistema que era composto pelo código que ele estava escrevendo.

Meu, as empresas se adequam e isso era o que elas tinham, logo nossos processos evoluiram pra achar uma forma de unir pessoas que entendiam dos negócios com pessoas que entendiam de código.

Venhamos e convenhamos, quem é mais importante pra empresa e quem é mais facilmente substituível ??? Qual informação é mais preciosa e difícil de passar ??? Qual é o perfil que eu não posso perder de jeito nenhum pra meu concorrente ???

Daí surgiu essa importância maior para o cara que define e menos para o cara que só escreve código, simples assim…

Hoje, ainda bem, o cenário mudou. Eu falo de boca cheia que além de entender de código, entendo muito bem do negócio para o qual estou trabalhando, não como um especialista na área, mas garanto que não sou facilmente substituível e que meu passe vale ouro. Consegui isso estudando e desenvolvendo habilidades além da lógica, da matemática e da capacidade de codificar os problemas do mundo real.

Mas vamos com calma minha gente, essa geração que está chegando agora no mercado, está chegando cheia de vontade e com muita informação. Logo logo as coisas mudam.

Abs []

raf4ever:

O que está se querendo dizer é:Não existe uma discrepância intelectual tão grande entre as atividade de analista e arquiteto(ou entre quaisquer outras funções em desenvolvimento de software) que justifique essa divisão.

É claro que num projeto é comum pessoas exercerem essa ou outra atividade,mas não significa que só devam ou só saibam exercer essa atividade.A multidisciplinaridade é muito bem-vinda.

Na prática acaba havendo uma discrepancia sim.

O analista, pela sua posição, acaba acumulando informação essencial para o projeto, enquanto que o programador, pode ser qualquer um que entenda UML e saiba usar uma IDE.

Novamente, não estou dizendo que é certo, mas querer dar xilique como se isso não acontecesse é ignorar a realidade.

Isso vai mudar cara… Nós programadores mudamos o mundo… Pense que todas as tecnologias evoluíram devido a existência de pessoas com nosso perfil.

Mark Zuckeberg e Bill estão cagando pra quem os chamaram de “limpadores de chão” um dia… rsrsrsrsrs

Porém, seguindo o exemplo desses caras, subir na vida requer dedicação, e a grande maioria quer que caia do céu o respeito pelo trabalho que têm.

Abs []

Botocudo:

Na prática acaba havendo uma discrepancia sim.

O analista, pela sua posição, acaba acumulando informação essencial para o projeto, enquanto que o programador, pode ser qualquer um que entenda UML e saiba usar uma IDE.

Novamente, não estou dizendo que é certo, mas querer dar xilique como se isso não acontecesse é ignorar a realidade.

O que os colegas estão colocando, seria o mundo ideal, aquele pelo qual devemos lutar todos os dias para que seja o mundo real…

Devemos incentivar os técnicos a adquirirem expertise de negócios e comunicação, devemos tentar mostrar a nossos gerentes as vantagens de tentar flexibilizar nossos processos de desenvolvimento tradicionais e que essa cultura de separação de papéis pode sim ser suprimida.

Enfim, como disse, encaro isso como evolução natural das coisas. Daqui a 20 anos a discussões serão em torno do modelo XPTO de desenvolvimento porque nossas discussões atuais terão esbarrados em novas variáveis desse mundão que está em constante evolução.

Abs []

adriano_si:

Porém, seguindo o exemplo desses caras, subir na vida requer dedicação, e a grande maioria quer que caia do céu o respeito pelo trabalho que têm.

Abs []

Eles não tiveram que abandonar a carreira de programador para se tornar quem eles são hoje?

Botocudo:

Eles não tiveram que abandonar a carreira de programador para se tornar quem eles são hoje?

Ahhhh o foco é a carreira ??? Morrer em uma empresa sendo programador em carteira ??? Sim, tiveram sim, mas foi assim que eles chegaram onde estão hoje.

É justamente isso que estou tentando colocar. Nosso papel é fazer a diferença. Você não precisa ser um Bill da vida pra poder ser respeitado no seu trabalho e sim evoluir a cada dia como profissional mostrando para seus colegas de trabalho porque você é importante “mesmo sendo programador”. ([EDIT] - Sem as aspas deu a impressão que eu desdenhei da profissão e não foi a intenção)

Esses caras deixaram a carreira de Programadores, mas ambos SÃO programadores… Sacou ???

Abs[]

Botocudo:

adriano_si:

Porém, seguindo o exemplo desses caras, subir na vida requer dedicação, e a grande maioria quer que caia do céu o respeito pelo trabalho que têm.

Abs []

Eles não tiveram que abandonar a carreira de programador para se tornar quem eles são hoje?

eles pararam de programar porque viraram empresários … mas suas respectivas empresas foram construídas enquanto eles eram o que ? analistas ? (na prática os 2 eram estudantes de Harvard, mas programavam no tempo livre).

adriano_si:

Você só deve levar em consideração que muita gente que frequenta o fórum não trabalha mais nesse modelo há bastante tempo. Eu trabalho ainda em empresas com essa hierarquia tradicional e entendo bem pelo que você passa.

O que os colegas estão colocando, seria o mundo ideal, aquele pelo qual devemos lutar todos os dias para que seja o mundo real…

Devemos incentivar os técnicos a adquirirem expertise de negócios e comunicação, devemos tentar mostrar a nossos gerentes as vantagens de tentar flexibilizar nossos processos de desenvolvimento tradicionais e que essa cultura de separação de papéis pode sim ser suprimida.

Enfim, como disse, encaro isso como evolução natural das coisas. Daqui a 20 anos a discussões serão em torno do modelo XPTO de desenvolvimento porque nossas discussões atuais terão esbarrados em novas variáveis desse mundão que está em constante evolução.

Abs []

Sou a favor de incentivar técnicos usando experiências reais, pra mim dizer que o produto é construido em código é lindo, só que infelizmente esta longe de ser realidade na maioria das empresas.

adriano_si:

Ahhhh o foco é a carreira ??? Morrer em uma empresa sendo programador em carteira ??? Sim, tiveram sim, mas foi assim que eles chegaram onde estão hoje.

É justamente isso que estou tentando colocar. Nosso papel é fazer a diferença. Você não precisa ser um Bill da vida pra poder ser respeitado no seu trabalho e sim evoluir a cada dia como profissional mostrando para seus colegas de trabalho porque você é importante “mesmo sendo programador”. ([EDIT] - Sem as aspas deu a impressão que eu desdenhei da profissão e não foi a intenção)

Esses caras deixaram a carreira de Programadores, mas ambos SÃO programadores… Sacou ???

Abs[]

Não. Os dois nunca foram programadores de carreira.

Sorry.

Botocudo:

adriano_si:

Você só deve levar em consideração que muita gente que frequenta o fórum não trabalha mais nesse modelo há bastante tempo. Eu trabalho ainda em empresas com essa hierarquia tradicional e entendo bem pelo que você passa.

O que os colegas estão colocando, seria o mundo ideal, aquele pelo qual devemos lutar todos os dias para que seja o mundo real…

Devemos incentivar os técnicos a adquirirem expertise de negócios e comunicação, devemos tentar mostrar a nossos gerentes as vantagens de tentar flexibilizar nossos processos de desenvolvimento tradicionais e que essa cultura de separação de papéis pode sim ser suprimida.

Enfim, como disse, encaro isso como evolução natural das coisas. Daqui a 20 anos a discussões serão em torno do modelo XPTO de desenvolvimento porque nossas discussões atuais terão esbarrados em novas variáveis desse mundão que está em constante evolução.

Abs []

Sou a favor de incentivar técnicos usando experiências reais, pra mim dizer que o produto é construido em código é lindo, só que infelizmente esta longe de ser realidade na maioria das empresas.

minha percepção é justamente a contrária … a maioria dos sitemas são construídos em código apenas … pode até ser código bagunçado, mas é código … afinal , é o único artefato indispensável em qualquer produto de software

rmendes08:

Botocudo:

adriano_si:

Você só deve levar em consideração que muita gente que frequenta o fórum não trabalha mais nesse modelo há bastante tempo. Eu trabalho ainda em empresas com essa hierarquia tradicional e entendo bem pelo que você passa.

O que os colegas estão colocando, seria o mundo ideal, aquele pelo qual devemos lutar todos os dias para que seja o mundo real…

Devemos incentivar os técnicos a adquirirem expertise de negócios e comunicação, devemos tentar mostrar a nossos gerentes as vantagens de tentar flexibilizar nossos processos de desenvolvimento tradicionais e que essa cultura de separação de papéis pode sim ser suprimida.

Enfim, como disse, encaro isso como evolução natural das coisas. Daqui a 20 anos a discussões serão em torno do modelo XPTO de desenvolvimento porque nossas discussões atuais terão esbarrados em novas variáveis desse mundão que está em constante evolução.

Abs []

Sou a favor de incentivar técnicos usando experiências reais, pra mim dizer que o produto é construido em código é lindo, só que infelizmente esta longe de ser realidade na maioria das empresas.

minha percepção é justamente a contrária … a maioria dos sitemas são construídos em código apenas … pode até ser código bagunçado, mas é código … afinal , é o único artefato indispensável em qualquer produto de software

++

Quer provas para isso??? Ta cheio de software livre que nasceu só do código… e funcionando muito bem!

Depois vieram as documentações, wikis, e afins! Mas que foram dispensáveis em muitos projetos!

rmendes08:

minha percepção é justamente a contrária … a maioria dos sitemas são construídos em código apenas … pode até ser código bagunçado, mas é código … afinal , é o único artefato indispensável em qualquer produto de software

Certamente tivemos experiência bem distintas.

Botocudo:

Sou a favor de incentivar técnicos usando experiências reais, pra mim dizer que o produto é construido em código é lindo, só que infelizmente esta longe de ser realidade na maioria das empresas.

Se nós não evoluirmos nossas ideias, isso não mudará nunca…

Entenda que a divisão dos papéis surgiu por conta de uma necessidade. Porém esse perfil do nerd que ficava no seu canto produzindo código está sumindo… Quem não se adequar, vai vazar…

Eu trabalho hoje com mais 5 programadores, todos entendem MUITO BEM do negócio e procuram ao máximo deixar as coisas claras com o cliente em questão.

Pergunta pra meu cliente se ele ainda fica feliz em ter que pagar alguns encostos que ficam aqui conosco alocados, só porque é processo da empresa ter alguém responsável pelo documento ???

Não estou te dizendo que a documentação e os modelos não são importantes, de forma alguma, eu sou um exemplo vivo, pois sem eles eu me perderia no projeto que temos aqui, mas hoje, colocamos isso como um norte do negócio e não uma barreira, não o principal, não um impeditivo.

Os ganhos ??? Pra mim, o maior de todos é o feedback do usuário final… Isso o Mastercard não compra…

Entenda. Esse modelo que hoje você enxerga, ainda vai durar por algum tempo, mas precisamos levantar a bandeira do certo, tirando todo e qualquer rastro de tirania e burocracia em nossas empresas. Trabalhamos com Intelecto, logo não somos “apertadores de parafusos”.

Abs []

Não precisa se desculpar de nada não cara…

Como lhe falei, eles largaram a carreira (esqueça aqui CARTEIRA ASSINADA ou TRABALHAR COMO EMPREGADO DE ALGUÉM) de Programadores porque suas ideias evoluíram porque não pararam de estudar…

Porém ambos são Programadores sim… Talvez fique confuso de entender… Desculpe se não tive a habilidade de conseguir me fazer entender…

Abs []

Poderia citar pelo menos 1 software livre inovador?

Que me lembre todos eles nascem como alternativa de baixo custo à um software proprietário existente.

Botocudo:

jmmenezes:

++

Quer provas para isso??? Ta cheio de software livre que nasceu só do código… e funcionando muito bem!

Depois vieram as documentações, wikis, e afins! Mas que foram dispensáveis em muitos projetos!

Poderia citar pelo menos 1 software livre inovador?

Que me lembre todos eles nascem como alternativa de baixo custo à um software proprietário existente.

e o que isso tem a ver ? vai me dizer que todo software proprietário é desenvolvido com diagramas antes ?

Botocudo:

jmmenezes:

++

Quer provas para isso??? Ta cheio de software livre que nasceu só do código… e funcionando muito bem!

Depois vieram as documentações, wikis, e afins! Mas que foram dispensáveis em muitos projetos!

Poderia citar pelo menos 1 software livre inovador?

Que me lembre todos eles nascem como alternativa de baixo custo à um software proprietário existente.

Hibernate ?

Botocudo:

jmmenezes:

++

Quer provas para isso??? Ta cheio de software livre que nasceu só do código… e funcionando muito bem!

Depois vieram as documentações, wikis, e afins! Mas que foram dispensáveis em muitos projetos!

Poderia citar pelo menos 1 software livre inovador?

Que me lembre todos eles nascem como alternativa de baixo custo à um software proprietário existente.

Eu não disse que todos eram ou não inovadores, embora se não tivesse existido linux e apache provavelmente a internet não seria o que é hoje!
Falei de software livre pq qualquer um pode ver como foi feito! Tem empresa que tem sistema de qualidade rodando também e ZERO de documentação.

Na questão de inovação, alguns exemplos mais:

• beryl (e depois Compiz)… na época inovou em efeitos no desktop
• gnome 3, inovou na forma que a interface trabalha
• eclipse inovou em muita coisa em questão de IDE (pode não ter nascido livre, mas as primeiras versões eram uma caca)

se for colocar aqui a lista é gigante!

rmendes08:

Hibernate ?

rmendes08:

e o que isso tem a ver ? vai me dizer que todo software proprietário é desenvolvido com diagramas antes ?

Por onde passei sim. Mas pelo visto o pessoal não esta interessado em fatos.

Botocudo:

rmendes08:

e o que isso tem a ver ? vai me dizer que todo software proprietário é desenvolvido com diagramas antes ?

Por onde passei sim. Mas pelo visto o pessoal não esta interessado em fatos.

Para você colocar isso como fato você teria que conhecer todas as empresas de software do mundo …

jmmenezes:

Eu não disse que todos eram ou não inovadores, embora se não tivesse existido linux e apache provavelmente a internet não seria o que é hoje!
Falei de software livre pq qualquer um pode ver como foi feito! Tem empresa que tem sistema de qualidade rodando também e ZERO de documentação.

Na questão de inovação, alguns exemplos mais:

• beryl (e depois Compiz)… na época inovou em efeitos no desktop
• gnome 3, inovou na forma que a interface trabalha
• eclipse inovou em muita coisa em questão de IDE (pode não ter nascido livre, mas as primeiras versões eram uma caca)

se for colocar aqui a lista é gigante!

Não entendo de que forma software livre prova alguma coisa sobre a maioria das empresas desenvolver no código.

Mas sua lista foi uma boa piada, valeu!

Minha experiência é fato. A separação de papéis no desenvolvimento de software é uma tendência que não vejo diminuir.

Que pena. Eu trabalho com desenvolvimento ágil, ou sem o papel de analista há pelo menos 12 anos.
Fico muito triste em saber que ainda tem gente que está passando pelo que você passa, e pior, descrente quanto à novas práticas de desenvolvimento serem aceitas ou possíveis.

O fato é que, basta olhar um pouco a sua volta, e vai ver que a tendência de desenvolvimento ágil é inexorável. O número de empresas adotando esse modelo só cresce e, com isso, somem as vagas de analista “puro”.

Sugiro que procure um emprego numa empresa de qualidade o mais rápido possível.

ViniGodoy:

Que pena. Eu trabalho com desenvolvimento ágil, ou sem o papel de analista há pelo menos 12 anos.
Fico muito triste em saber que ainda tem gente que está passando pelo que você passa, e pior, descrente quanto à novas práticas de desenvolvimento serem aceitas ou possíveis.

O fato é que, basta olhar um pouco a sua volta, e vai ver que a tendência de desenvolvimento ágil é inexorável. O número de empresas adotando esse modelo só cresce e, com isso, somem as vagas de analista “puro”.

Sugiro que procure um emprego numa empresa de qualidade o mais rápido possível.

O pior é que a maioria se dizia agile e o analista apenas mudou de nome para <insira nome usado pela sua metodologia preferida aqui>.

samuelM:

se formos comparar um projeto com uma obra o programador seria o peão de obra?
Desculpe minha ignorançia mas é o que transparece ser. me iludam por favor pois amo programar.

Você já viu algum peão de obra refatorar o projeto do engenheiro?

al.barbosa:

samuelM:

se formos comparar um projeto com uma obra o programador seria o peão de obra?
Desculpe minha ignorançia mas é o que transparece ser. me iludam por favor pois amo programar.

Você já viu algum peão de obra refatorar o projeto do engenheiro?

Pois é.

Infelizmente este conceito não funciona na prática, nunca funcionou, nem nunca vai funcionar, por mais que tentem.

Talvez este ainda seja o modelo que muitas empresas seguem (ou tentam seguir), mas ele é fracassado e o resultado deste modelo é o que temos hoje, empresas ineficientes, produzindo software mais ou menos, dificil de evoluir e absurdamente caro. Mas este é o reflexo da tentativa de comparar desenvolvimento de software com engenharia civil.

Eu disse “infelizmente não funciona” porque seria muito mais barato pagar um analista ótimo e cinco programadores mais ou menos e ter um produto ótimo no final. Mas não é o que acontece na prática. Na prática ou o analista vai ter que detalhar tudo exatamente, nos minimos detalhes, cada fator, cada porem, cada possibilidade, por tudo isso numa especificacao, rezar para que o programador entenda e depois rezar para que após ele ter entendido ele consiga de fato traduzir aquilo para codigo.

Ora, fazer uma especificacao como esta é tao ou mais trabalhoso que simplesmente sentar e programar a solucao. Entao porque o proprio analista já nao implementa a solucao que ele criou? Voce remove um enorme potencial de problema que é falha de comunicacao. E mesmo assim nada impede de voce ter um programador junior que vai fazer um pouco do trabalho “chato” de programar interfaces de telas mais simples ou relatorios basicos, enquanto vai ganhando experiencia.

Seria otimo tambem o contrario, ter quatro ou cinco analistas meia boca e um programador “pau pra toda obra”, que manja muito e resolve tudo. Bom, nesse caso, o numero de problemas de analise tende a ser tão grande que o tal programador vai ter que ficar revendo cada regra projetada, tendo que reavaliar e corrigir quase tudo. Entao, deixe que ele faça, assim voce nao precisa pagar os cinco analistas e o programador resolve de maneira tão ou mais rapida o mesmo problema.

Numa empresa em que eu trabalhava existia esta distinção de forma bem clara (analistas e programadores) - na verdade ainda existe, eu é que não existo mais lá. Um projeto do qual eu participava estava indo bem, o nosso coordenador era também o analista principal, alem de programar, e muito bem. Nosso produto deveria ser integrado a um outro desenvolvido por uma segunda equipe, composta por dois programadores, um arquiteto e um analista que um dia, num passado remoto, diz ter sido programador. E a frase dita por esse cara e respondida pelo meu coordenador é que me fez entender bem porque o nosso projeto andava e o deles não.

O analista que um dia programou disse, como desculpa, quase que apontando o dedo para o seu arquiteto. “Veja, o arquiteto do sistema deles entende TUDO da regra de negocio”, ao que o nosso coordenador, nao muito humilde, e já de saco cheio das desculpas do analista, respondeu: “sim, mas o analista aqui programa pra cacete tambem”.

O ponto é que o nosso projeto andava e o deles não porque nós sabiamos o que estavamos fazendo, eles não. Nós tinhamos uma visao do todo, tinhamos alguem na equipe que entendia o problema a ferramenta que o solucionava e não tinha pudor em dividir a visão dele.

A equipe deles se comunicava por papel, ninguem la tinha uma visao completa. Ou conhecia a regra ou conhecia a linguagem, ou falava com o cliente, ou escolhia a arquitetura. E quando dava merda, e dava muita, um punha a culpa no outro.

samuelM:

se formos comparar um projeto com uma obra o programador seria o peão de obra?
Desculpe minha ignorançia mas é o que transparece ser. me iludam por favor pois amo programar.

O cliente é o patrão. Logo todo mundo é peão de alguem.

Existem hierarquias dentro das empresas também, e se quiser afundar o barco, é só começar a desrespeitar, não ouvir ou ficar lembrando contantemente e sem motivos seus subordinados quem é que “manda”. Neste caso, basta os subordinados abandonem o projeto no meio para deixar um problemão na mão do gerente.
Acho que se é peão ou não, o que importa é o respeito e a boa comunicação. Se não, é melhor nem iniciar projetos.

ViniGodoy:

Não.

Em primeiro lugar, está caindo o modelo de que o analista, projetista e programador são pessoas diferentes. Geralmente, eles são a mesma pessoa e o que muda é apenas a fase do projeto que estão.

Depois, você constroi um software enquanto os requisitos mudam. Se programadores fossem pedreiros, seriam nessas condições:
[youtube]http://www.youtube.com/watch?v=UZq4sZz56qM[/youtube]

Finalmente, a analogia também é grosseira pq vc não tem pequenas peças que podem ser montadas em software. Você constrói essas peças. Então, é como se esses pedreiros fossem capazes de fazer seus tijolos, sua argamassa e vários outros itens de construção, além de construir o prédio.

Essa analogia traz o perigo de achar que, com um bom analista e com um bom engenheiro, um programador é um item plenamente substituível. Não é bem assim, pois, embora seja mesmo um cargo operacional, é também um cargo intelectual. E, certamente, um bom programador é muito mais caro de substituir do que um excelente pedreiro.

vídeo bem legal.

Como vc falou, direto temos que fazer os “tijolos”, pois não os encontramos disponíveis para serem utilizados.
Quantos aqui nunca tiveram que implementar amscaras utilizando regex ou alguma forma de validação para os campos?
Já vi um montão de analistas apanhando nisso. Neste ponto, ele deve ficar com a especificação do que deve ser feito e parou por ai.

Voce como dono da empresa, diante desta mesma situacao, com dois analistas com igual capacidade de levantar requisitos, experiencia para lidar com o cliente… (enfim do mesmo nivel), qual voce contrataria? o que sabe ou o que não sabe usar as ferramentas com as quais sera feita a aplicação?

faço minhas palavra as suas

Vini:

O fato é que, basta olhar um pouco a sua volta, e vai ver que a tendência de desenvolvimento ágil é inexorável. O número de empresas adotando esse modelo só cresce e, com isso, somem as vagas de analista “puro”.

Muitos estão dizendo que a separação entre analista e programador é “antiga”, é verdade, mas percebo claramente que esquecem o fato de que existe a linha do tempo. Quando os computadores começaram a serem aplicados na industria eles custavam muuuuuuito dinheiro, o sistema deveria ser previamente ser muito bem entendido, ainda hoje deve ser assim obviamente mas na época era uma obsessão, haviam várias técnicas de como fazer entrevistas com os usuários, organizar as informações e etc… a parte da analise era profunda e principalmente mais extensiva. O programador não poderia errar muito pois cada vez que submetia o programa a uma compilação daria para ouvir o barulho da caixa registradora. Dependendo o número de erros em cada compilação o programador poderia ser demitido. Vocês pensam que compilar um programa ou executar um programa éra igual apertar uma tecla em seu microcomputador para acionar uma função em sua IDE maravilhosa? Não, não, não…ao termino e UMA compilação era disponibilizado um relatório dos erros (com poucos detalhes) e outros dados como tempo gasto pelos microprocessadores, alguns dizem que até o custo da compilação poderia ser deduzida nestes relatórios. Em fim a coisa não era tão simples assim.

A estrutura organizacional utilizada pelo setor de processamento de dados foi tão impactante que afeta a todos de várias maneiras até hoje. O trem da historia tomou um rumo diferente, bacana porem MUITO ESTRANHO quando um carinha chamado Bill Gates mostrou ao mercado que pessoas comuns poderiam colocar suas patinhas em um computador e que isto iria render uma GRANA PRETA (ele ficou milionário aos 30 anos eu acho). Computador não seria mais um “privilégio” de poucos que eram chamados de analistas e programadores, seres especiais ao extremo.

Bem, perceba que quando o microcomputador foi colocado na mão do povão e dentro deles a possibilidade de se fazer programas utilizando linguagens como basic, fortran e assembler (acho que havia outras) um cidadão comum começou a fazer coisas que um analista e um programador fazia SOZINHO, obviamente que não fazia da mesma maneira e nem tão bem pois não fora educado para desempenhar tais atividades; tudo era na dedução e na tentativa e erro. Até ai nada demais porque o microcomputador é uma coisa DOMESTICA com fins de LAZER e ESTUDO, produzir textos científicos para quem estava na escola ou universidade.

Isto é apenas um resuminho para dizer que discutir sobre ser analista ou programador e principalmente a importância de suas atividades sem levar em conta fatores históricos não é bom e pode levar a equívocos gigantes. A estrutura organizacional na industria não se alterou desde que o computador foi introduzido no mercado logo tudo que é inserido neste contexto tende a ser colocado em uma hierarquia, o ser humano gosta de hierarquizar as coisas (existe uma explicação mas é melhor não comentar rsrs) por isso que fica difícil de mudar, principalmente se você for um funcionário de alguma empresa onde não se tem o domínio de tais estruturas.

flws

Carinha, já ouvi varias historias de pedreiro e mestre de obras sobre bobeadas de engenheiro…a principal critica é: subestimar / superestimar a infraestrutura da obra. Superestimar até que passa se houver muita grana envolvida mas subestimar com certeza deve rolar uma refatoraçãozinha porque colocar a vida dos outros em jogo pode até dar cadeia.

flws

A própria palavra peão de obra já embute uma dose de preconceito. O nome correto da profissão, se não me engano, é trabalhador da construção civil ou pedreiro. É o mesmo problema de chamar de leproso um doente de hanseníase (hoje hanseníase tem cura).

Veja o link abaixo para entender o problema com o peão de obra:

http://www.dislexia.org.br/espaco/artes/artes_008.html

Mas sei que essa visão existe (e bastante).

Estava pesquisando em um livro de análise estruturada de 1978. Destaco o trecho abaixo do livro:

Davis:

As especificações desenvolvidas durante o projeto detalhado são análogas às plantas do engenheiro (pág. 13)
(…)
A planta baixa fornece um plano geral para a localização das paredes, encanamento, dutos de aquecimento, fiação elétrica, e outros componentes. Utilizando-a como guia, o construtor divide o trabalho entre diversos carpinteiros, encanadores, eletricistas e outros. (pág. 76).

Felizmente essa visão está mudando. Craig Larman tem outra opinião, que ele publicou em 2000:

Larman:

Entretanto, em geral, o trabalho de programação não é um passo trivial de geração de código - muito pelo contrário! De fato, os resultados gerados durante a modelagem de projeto são um primeiro passo imcompleto; durante a programação e os testes, milhares de modificações vão ser feitas e problemas detalhados vão ser descobertos e resolvidos.

Bem executados, idéias e entendimentos (não diagramas ou documentos!) gerados durante a modelagem de projeto OO vão fornecer uma ampla base que permite a ampliação de escala com elegância e robustez para resolver os novos problemas encontrados durante a programação. Mas prepare-se e planeje para muitas modificações e desvios do projeto durante a programação. Essa é uma atitude-chave - e pragmática - nos métodos iterativos e evolutivos.

Por tudo isso, acho a comparação inadequada. Acho que o programador não deve ser um mero executor. Ele deve interferir e participar do projeto do sistema. Com as linguagens orientadas a objetos e métodos iterativos acho que isso é uma necessidade.

Se fizermos uma analogia do programador com o operário em uma fábrica de carros, e do analista com o engenheiro que projeta o carro, acho que surge o mesmo problema. Imagine que o operário está fabricando o carro, mas descobre que o projeto da unidade de injeção eletrônica não é muito adequado na hora de implementar. Então divide essa unidade em dois componentes separando as responsabilidades. Acho que isso não ocorre com frequência numa fábrica de carros. Mas acho perfeitamente comum o programador interferir no projeto do sistema, porque é praticamente impossível o analista construir um projeto perfeito e acabado antes de ser feita a programação.

Outra diferença que acho importante é que após construir um prédio ou um carro, é bastante difícil alterar o seu projeto. Será preciso quebrar o prédio para implementar o novo projeto. Alterar o projeto de um sistema após construí-lo é bem mais viável. E as técnicas de refatoração ajudam bastante nisso. Para ilustrar, cito abaixo Martin Fowler:

Fowler:

Refatoração é o processo de alteração de um sistema de software de modo que o comportamenteo externo do código não mude, mas que sua estrutura interna seja melhorada. É uma maneira disciplinada de aperfeiçoar o código que minimiza a chance de introdução de falhas. Em essência, quando você usa refatoração, você está melhorando o projeto do código após este ter sido escrito.

“Melhorar o projeto após ele ter sido escrito.” Esta é uma frase esquisita. Na nossa compreensão atual de desenvolvimento de software, acreditamos que projetamos e depois codificamos. Um bom projeto vem antes, e a codificação em seguida. O problema é que, como o passar do tempo, o código será modificado e a integridade do sistema, sua estrutura em relação ao projeto original, aos poucos enfraquece. O processo de construção de código, lentamente passa da engenharia à experimentação.

Refatorar é o oposto desta prática. Com a refatoração, você pode pegar um projeto ruim, até mesmo caótico, e transofrmá-lo em um código bem projetado.

Sei que existe a visão de que o programador é como um peão de obra (ou trabalhador da construção civil ou pedreiro), mas acho a comparação inadequada. Sei que existem pessoas que ainda têm essa visão, mas acho que estão com uma visão antiga e ultrapassada.

Carinha, já ouvi varias historias de pedreiro e mestre de obras sobre bobeadas de engenheiro…a principal critica é: subestimar / superestimar a infraestrutura da obra. Superestimar até que passa se houver muita grana envolvida mas subestimar com certeza deve rolar uma refatoraçãozinha porque colocar a vida dos outros em jogo pode até dar cadeia.

flws

Vou alterar um pouco o que disse. Como eu disse na outra resposta, a própria palavra peão de obra já embute uma dose de preconceito. O que quis dizer é que em geral os trabalhadores da construção civil e pedreiros seguem um projeto pronto, até onde eu conheço. Entendo que os mestres de obras e pedreiros podem sim interferir no projeto, mas acho que é bem menos comum do que um programador.

Absolutamente não falei isso para desmerecer o programador (e nem os trabalhadores da construção civil). Só acho que a comparação é inadequada. Acho que o programador interfere mais, e até modifica o projeto do sistema. Na resposta anterior explico as razões e cito alguns autores.

E é bem mais difícil refatorar um prédio depois que ele está construído do que refatorar um sistema.

YvGa:

Luiz Augusto Prado:

Como vc falou, direto temos que fazer os “tijolos”, pois não os encontramos disponíveis para serem utilizados.
Quantos aqui nunca tiveram que implementar amscaras utilizando regex ou alguma forma de validação para os campos?
Já vi um montão de analistas apanhando nisso. Neste ponto, ele deve ficar com a especificação do que deve ser feito e parou por ai.

Voce como dono da empresa, diante desta mesma situacao, com dois analistas com igual capacidade de levantar requisitos, experiencia para lidar com o cliente… (enfim do mesmo nivel), qual voce contrataria? o que sabe ou o que não sabe usar as ferramentas com as quais sera feita a aplicação?

Isso dependeria de muita coisas.
Pelo que vc tá sugerindo, alguem já decidiu as ferramentas que serão utilizadas.
Se quem decidiu isso será o responsavel pela lógica de negócios, eu contrataria o Analista que não sabe nenhuma ferramenta, daria o treinamento nas ferramentas necesssarias e pagaria 2x menos que o Analista que disse saber trabalhar com a ferramenta.

Carinha, já ouvi varias historias de pedreiro e mestre de obras sobre bobeadas de engenheiro…a principal critica é: subestimar / superestimar a infraestrutura da obra. Superestimar até que passa se houver muita grana envolvida mas subestimar com certeza deve rolar uma refatoraçãozinha porque colocar a vida dos outros em jogo pode até dar cadeia.

flws

++

Não queria comentar mas vamos lá…

Falta de informação sobre profissões é fogo, quem disse que o peão de obra não pensa, tem que fazer calculos muitas vezes e definir a estrutura… O problema aqui não é a comparação e sim o orgulho de dizer sou programador e dai se for praticamente a mesma coisa que diferança vai fazer no seu dia a dia. A vida vai além de ser ou não programador…

Luiz Augusto Prado:

YvGa:

Luiz Augusto Prado:

Como vc falou, direto temos que fazer os “tijolos”, pois não os encontramos disponíveis para serem utilizados.
Quantos aqui nunca tiveram que implementar amscaras utilizando regex ou alguma forma de validação para os campos?
Já vi um montão de analistas apanhando nisso. Neste ponto, ele deve ficar com a especificação do que deve ser feito e parou por ai.

Voce como dono da empresa, diante desta mesma situacao, com dois analistas com igual capacidade de levantar requisitos, experiencia para lidar com o cliente… (enfim do mesmo nivel), qual voce contrataria? o que sabe ou o que não sabe usar as ferramentas com as quais sera feita a aplicação?

Isso dependeria de muita coisas.
Pelo que vc tá sugerindo, alguem já decidiu as ferramentas que serão utilizadas.
Se quem decidiu isso será o responsavel pela lógica de negócios, eu contrataria o Analista que não sabe nenhuma ferramenta, daria o treinamento nas ferramentas necesssarias e pagaria 2x menos que o Analista que disse saber trabalhar com a ferramenta.

E teria 2x mais erros e situacoes inesperadas, o que poderia te levar a acreditar que estava com pessoal insuficiente, o que por consequencia te levaria a contratar mais um analista por metade do preço, te levando a 4x mais erros e situacoes inesperadas. Acredite, isso acontece, e muito. E diagnosticar este problema é muito dificil.

E no final das contas a tua suposta economia vai te custar muito mais caro, alem de dar um produto de baixa qualidade.

Carinha, já ouvi varias historias de pedreiro e mestre de obras sobre bobeadas de engenheiro…a principal critica é: subestimar / superestimar a infraestrutura da obra. Superestimar até que passa se houver muita grana envolvida mas subestimar com certeza deve rolar uma refatoraçãozinha porque colocar a vida dos outros em jogo pode até dar cadeia.

flws

++

Não queria comentar mas vamos lá…

Falta de informação sobre profissões é fogo, quem disse que o peão de obra não pensa, tem que fazer calculos muitas vezes e definir a estrutura… O problema aqui não é a comparação e sim o orgulho de dizer sou programador e dai se for praticamente a mesma coisa que diferança vai fazer no seu dia a dia. A vida vai além de ser ou não programador…

Tá bom, já retirei minhas palavras. Como eu disse na outra resposta não quero desmerecer nem uma profissão nem outra.

E “peão de obra” embute preconceito, melhor chamar pedreiro ou trabalhador da construção civil.

Só acho a comparação inadequada, conforme disse na outra resposta.

PS - depois pensando bem vi que não precisava retirar as palavras porque não disse nenhum absurdo. Apenas não acho correto discriminar o programador com adjetivos como “peão de obra” ou “digitador de luxo”, não é questão de orgulho. Acho que a refatoração atualmente é uma necessidade na programação, enquanto que na construção civil entendo que é uma exceção - nada para discriminar o “peão de obra”, que nem mesmo é o nome de uma profissão - o correto seria pedreiro ou trabalhador da construção civil.

al.barbosa:

Anime:

++

Não queria comentar mas vamos lá…

Falta de informação sobre profissões é fogo, quem disse que o peão de obra não pensa, tem que fazer calculos muitas vezes e definir a estrutura… O problema aqui não é a comparação e sim o orgulho de dizer sou programador e dai se for praticamente a mesma coisa que diferança vai fazer no seu dia a dia. A vida vai além de ser ou não programador…

Tá bom, já retirei minhas palavras. Como eu disse na outra resposta não quero desmerecer nem uma profissão nem outra.

E “peão de obra” embute preconceito, melhor chamar pedreiro ou trabalhador da construção civil.

Só acho a comparação inadequada, conforme disse na outra resposta.

Tudo bem cada um tem seu ponto de vista, coloquei o meu…

Carinha, já ouvi varias historias de pedreiro e mestre de obras sobre bobeadas de engenheiro…a principal critica é: subestimar / superestimar a infraestrutura da obra. Superestimar até que passa se houver muita grana envolvida mas subestimar com certeza deve rolar uma refatoraçãozinha porque colocar a vida dos outros em jogo pode até dar cadeia.

flws

++

Não queria comentar mas vamos lá…

Falta de informação sobre profissões é fogo, quem disse que o peão de obra não pensa, tem que fazer calculos muitas vezes e definir a estrutura… O problema aqui não é a comparação e sim o orgulho de dizer sou programador e dai se for praticamente a mesma coisa que diferança vai fazer no seu dia a dia. A vida vai além de ser ou não programador…

O problema não é a comparação em si, o fato de tal profissao valer mais que outra, ou orgulho, nem nada disso.

O ponto é que um pedreiro executa algo que já está definido, especificado e que tem que ser seguido a risca. Caso ele, com a experiencia dele, ache algo errado, ele vai corrigir, se possivel ou devolver para o engenheiro corrigir. E é assim que as coisas funcionam melhor na engenharia civil.

Em desenvolvimento de software isso não funciona assim, embora muitas empresas insistam nisso. E é, em boa parte, essa a razão para o enorme caso de falhas na nossa área, o enorme numero de projetos cancelados, nunca entregues, entregues e abandonados ou que não satisfazem a expectativa do cliente.

O projeto de software é o codigo e só ele, o pedreiro de software é o compilador, que vai tranformar o projeto em produto. Em habitacoes populares uma mesma planta (projeto) é construida varias vezes, gerando centenas de casas iguais, mas o projeto é o mesmo. O engenheiro só fez um, os pedreiros irão realizar as diversas construcoes (build) do mesmo projeto.

Seria ridiculo propor pra ele que um analista de planta coletasse com o cliente as informacoes do projeto, fizesse um esboco de como a planta deveria ser construida, depois passasse para o engenheiro fazer o calculo estrutural daquela planta, decidir os materiais a serem usados e concluisse o projeto, para só então os pedreiros executarem a obra.

Em desenvolvimento de software quando voce precisa de mais de uma copia de um mesmo produto voce simplesmente pede para o compilador gerar pra voce e pronto.

Então a diferença não é só o nome que se dá a coisa, é o conceito errado que se tem. A comparação é falha por si só, nao simplesmente por desmerecer essa ou aquela profissao.

Bom, conheço pessoas que são disputadas a unha que se apresentam como o tal “peão” por que aprenderam tudo na pratica fazem o projeto e pagam um engenheiro para assinar, mas ai a discussão será outra. Talvez minha visão seja mais humana do que tecnica, talvez!

YvGa:

Luiz Augusto Prado:

YvGa:

Luiz Augusto Prado:

Como vc falou, direto temos que fazer os “tijolos”, pois não os encontramos disponíveis para serem utilizados.
Quantos aqui nunca tiveram que implementar amscaras utilizando regex ou alguma forma de validação para os campos?
Já vi um montão de analistas apanhando nisso. Neste ponto, ele deve ficar com a especificação do que deve ser feito e parou por ai.

Voce como dono da empresa, diante desta mesma situacao, com dois analistas com igual capacidade de levantar requisitos, experiencia para lidar com o cliente… (enfim do mesmo nivel), qual voce contrataria? o que sabe ou o que não sabe usar as ferramentas com as quais sera feita a aplicação?

Isso dependeria de muita coisas.
Pelo que vc tá sugerindo, alguem já decidiu as ferramentas que serão utilizadas.
Se quem decidiu isso será o responsavel pela lógica de negócios, eu contrataria o Analista que não sabe nenhuma ferramenta, daria o treinamento nas ferramentas necesssarias e pagaria 2x menos que o Analista que disse saber trabalhar com a ferramenta.

E teria 2x mais erros e situacoes inesperadas, o que poderia te levar a acreditar que estava com pessoal insuficiente, o que por consequencia te levaria a contratar mais um analista por metade do preço, te levando a 4x mais erros e situacoes inesperadas. Acredite, isso acontece, e muito. E diagnosticar este problema é muito dificil.

E no final das contas a tua suposta economia vai te custar muito mais caro, alem de dar um produto de baixa qualidade.

Vc pode supor um monte de problemas pras as escolhas de qualquer um assim como posso supor outro monte de problemas pra suas escolhas.

Por exemplo, prefiro utilizar apenas codigo nativo com o mínimo de dependências possiveis. Sabe por que?
Porque se eu precisar substituir o funcionário, não vou precisar ficar meses procurando um. Um projeto parado por meses, na minha opinião é uma das piores coisas que pode acontecer.

Voltando para o caso de quem escolheu a ferramenta.
Se existe um padrão a ser seguido, e é isso que o novo funcionário deve entender, ele deve ser avaliado se é consegue logo na primeira semana.
Quem escolheu a ferramenta deve, obrigatoriamente, ser capaz de avaliar a qualidade do trabalho do novo funcionario em pouco tempo.

A questão qualidade é algo que vc só pode avaliar comparando com outro produto do mesmo tipo.

Concordo contigo nesse ponto. Se formos ficar supondo, podemos supor qualquer coisa e exemplificar como bem entender.

Quanto ao substituir um funcionario, eu acho que um programador bom é aquele que consegue se adaptar as ferramentas que voce usa rapidamente. Se eu uso Hibernate e JSF nos meus projetos, este não vai ser o criterio de contratação de um programador, mas sim a base e a experiencia dele. Eu sei que quanto mais bem preparado ele for, mais rapidamente ele vai se adaptar a estas ferramentas. E principalmente, a qualquer outra que um dia eu precisar usar.

O que eu quis dizer com os meus exemplos é que não vejo sentido em contratar um analista que nao saiba, nem queira programar. E se ele não sabe criar uma expressao regex, que ele tenha capacidade de aprender rapidamente, porque eu não vou contratar outro só pra esse tipo de serviço.

Primeiramente gostaria de agradecer todos os esclarecimentos até mesmo os nao construtivos, esclareceu muita coisa a respeito.

Quero deixar claro que minha intenção em momento algum é desmerecer o serviço de ngm nem do programador(sou um) e nem do peão de obra que sao servicos honestos assim como de um analista.

O que absorvi de toda essa discução?

R: Hierarquia existe em qualquer tipo de gestão e a comparação que fiz quem achou que é desmerecer alguem aposto que é programador que se achou desmerecido por compara-lo com peão de obra, mas fiz esse tipo de comparação em relação ao peão de obra ou pedreiro, porque logico que não é o mesmo serviço porém a metodologia de trabalho é semelhante pois geralmente o programador faz o que lhe é passado assim como o peão de obra.

Mais uma vez obrigado pelos comentarios.

Grato.

samuelM:

Primeiramente gostaria de agradecer todos os esclarecimentos até mesmo os nao construtivos, esclareceu muita coisa a respeito.

Quero deixar claro que minha intenção em momento algum é desmerecer o serviço de ngm nem do programador(sou um) e nem do peão de obra que sao servicos honestos assim como de um analista.

O que absorvi de toda essa discução?

R: Hierarquia existe em qualquer tipo de gestão e a comparação que fiz quem achou que é desmerecer alguem aposto que é programador que se achou desmerecido por compara-lo com peão de obra, mas fiz esse tipo de comparação em relação ao peão de obra ou pedreiro, porque logico que não é o mesmo serviço porém a metodologia de trabalho é semelhante pois geralmente o programador faz o que lhe é passado assim como o peão de obra.

Mais uma vez obrigado pelos comentarios.

Grato.

Como eu ja disse, o ponto nao eh a profissao, nem a comparacao, nem se sentir ofendido, nem se deve se dizer pedreiro, peao de obra, o trabalhador da construcao civil. O ponto eh que a analogia nao faz sentido. Vou repetir meu post:

O ponto é que um pedreiro executa algo que já está definido, especificado e que tem que ser seguido a risca. Caso ele, com a experiencia dele, ache algo errado, ele vai corrigir, se possivel ou devolver para o engenheiro corrigir. E é assim que as coisas funcionam melhor na engenharia civil.

Em desenvolvimento de software isso não funciona assim, embora muitas empresas insistam nisso. E é, em boa parte, essa a razão para o enorme caso de falhas na nossa área, o enorme numero de projetos cancelados, nunca entregues, entregues e abandonados ou que não satisfazem a expectativa do cliente.

O projeto de software é o codigo e só ele, o pedreiro de software é o compilador, que vai tranformar o projeto em produto. Em habitacoes populares uma mesma planta (projeto) é construida varias vezes, gerando centenas de casas iguais, mas o projeto é o mesmo. O engenheiro só fez um, os pedreiros irão realizar as diversas construcoes (build) do mesmo projeto.

Seria ridiculo propor pra ele que um analista de planta coletasse com o cliente as informacoes do projeto, fizesse um esboco de como a planta deveria ser construida, depois passasse para o engenheiro fazer o calculo estrutural daquela planta, decidir os materiais a serem usados e concluisse o projeto, para só então os pedreiros executarem a obra.

Em desenvolvimento de software quando voce precisa de mais de uma copia de um mesmo produto voce simplesmente pede para o compilador gerar pra voce e pronto.

Então a diferença não é só o nome que se dá a coisa, é o conceito errado que se tem. A comparação é falha por si só, nao simplesmente por desmerecer essa ou aquela profissao.

Sim, existe hierarquia nas empresas, mas nao na diferenca entre analista e programador. O nome dessa diferenca é burrice.

O mais engraçado do tópico não é o objetivo dele, mas, o modo 8 ou 80 que alguns assumem. E mais interessante é ver que muitos defendem a idéia de que nada é solução para tudo.
Existem modelos de negócios onde o modelo ágil é necessário e muito bem empregado. Ele exige um pouco mais de cada pessoa envolvida, pois, disciplina e foco são essenciais. Senão, voltamos à idéia da hierarquia, um manda e os demais cumprem funções.
Em contrapartida, existem lugares que só funcionam no modelo clássico. não por que as pessoas que trabalham ali são incompetentes ou por que são menos disciplinadas ou focadas. A estrutura do negócio, onde eles estão inseridos exige isto. É o caso da empresa para a qual presto serviço atualmente.
Aqui todos os papéis são muito bem definidos (quando alguém é contratado, lê todas as definições de cargo e função existentes). Isso viabiliza a gestão, dentro deste modelo. Pode não ser o adequado, mas é a forma como funciona. Isso, por que, não é uma empresa cuja atividade principal é a tecnologia. Somos apenas um dos setores. E, para manter o nível administrativo equiparado, emprega-se tal opção.
Não estou dizendo que é mais certo ou menos certo que implementar um modelo ágil, apenas que, para a complexidade do negócio, está funcionando muito bem, obrigado.
Aliás, a complexidade da coisa é tão absurda que a implantação do SAP e toda sua infra estrutura administrativa, vai mais lento que corrida de tartaruga. Mudar a cultura de toda uma corporação é algo delicado que pode trazer consequências desastrosas, principalmente para uma empresa que fatura mais de 20 milhões por dia.
Agora, se fosse para começar hoje uma empresa, certamente eu buscaria empregar um modelo ágil. Não por uma questão de economia, pago um programador e ele que se vire para ser analista. Mas pelo apelo lógico que isso possui.
Fazendo um paralelo, eu certamente preferiria contratar um pedreiro com diploma de engenheir, que um engenheiro que não assenta tijolos e um pedreiro que não assina plantas.
Reafirmo meu pensamento, a idéia de hierarquia só funciona quando o argumentum ad verendicum é verdade, ou seja, pela farda, pela insígnia e pelo cargo alguém merece mais respeito que seus subalternos. Errado, todos somos capazes.

“Se você tem facilidade em adquirir conhecimento, transmita-o para outras pessoas. Com isto, o respeito virá gradativamente” - Princípio anarquista

Um peão pedreiro, não precisa estudar, não precisa ser inteligente, não precisa pensar, não precisa nem saber ler nem escrever, só precisa ser forte para carregar as pedras e os sacos de cimento.
Agora me diz uma coisa, um programador se encaixa nesses mesmo itens acima ?

OBVIAMENTE QUE NÃO !!

Cara, pra ser programador, tem que estudar muito e além de se manter ligado em novas tecnologias para não sair do mercado de trabalho.

Quem pensa que um programador pode ser comparado a um peão, é um completo ignorante.

Sim! Com certeza!
Hoje eu penso assim porque passei por algumas experiências ruins com o Seam e o JBoss. O usuario inesperiende pode demorar até 2 meses pra ficar bom nele. Os resultados são excelentes. Mas se ocorrer alguma inovação, bug ou ocorrer o fim do suporte do fabricante que lhe obrigue a fazer mudança para uma versão melhor, possivelmente terá que refatorar todo o seu projeto além de gastar tempo com atualização do conhecimento.

YvGa:

O que eu quis dizer com os meus exemplos é que não vejo sentido em contratar um analista que nao saiba, nem queira programar. E se ele não sabe criar uma expressao regex, que ele tenha capacidade de aprender rapidamente, porque eu não vou contratar outro só pra esse tipo de serviço.

Correto. Mas as vezes temos que ceder em alguns pontos. Ninguem é bom em tudo.
Eu já prefiro ficar com o trabalho de programar do que ir conversar com o cliente, levantar requisitos e especificar. Essas 3 ultimas coisas não são pra mim.

.

guilherme.dio:

Um peão pedreiro, não precisa estudar, não precisa ser inteligente, não precisa pensar, não precisa nem saber ler nem escrever, só precisa ser forte para carregar as pedras e os sacos de cimento.
Agora me diz uma coisa, um programador se encaixa nesses mesmo itens acima ?

OBVIAMENTE QUE NÃO !!

Cara, pra ser programador, tem que estudar muito e além de se manter ligado em novas tecnologias para não sair do mercado de trabalho.

Quem pensa que um programador pode ser comparado a um peão, é um completo ignorante.

:shock:

guilherme.dio:

Um peão pedreiro, não precisa estudar, não precisa ser inteligente, não precisa pensar, não precisa nem saber ler nem escrever, só precisa ser forte para carregar as pedras e os sacos de cimento.
Agora me diz uma coisa, um programador se encaixa nesses mesmo itens acima ?

OBVIAMENTE QUE NÃO !!

Cara, pra ser programador, tem que estudar muito e além de se manter ligado em novas tecnologias para não sair do mercado de trabalho.

Quem pensa que um programador pode ser comparado a um peão, é um completo ignorante.

Vc quem pensa. Um peão tem que saber e ser inteligente em muitas coisas.
Eu já tive oportunidade de trabalhar em obras.
Vc acha que é fácil levantar uma parede? Existe técnica para isso. A proporção de cimento, areia, água.
A forma como colocar entre os tijolos, a velocidade, o nível…
Sem contar o risco de um acidente.
Encontrar pedreiro bom é mais difícil que um programador bom.
E pra ser sincero, é uma profissão que atualmente tá pagando tão bem quanto a de um simples programador.
Eu não entendo o porque do preconceito e o motivo da comparação ser jocosa. É uma profissão lindissima e que tem seus refinamentos.
Acho que deveria passar uma semana em uma obra antes de ficar imaginando que tal profissional não tem estudo.

O que eu acho de verdade:

Todos querem ter razão em tudo, e ninguém aceita quando alguém fala uma verdade.

samuelM:

Primeiramente gostaria de agradecer todos os esclarecimentos até mesmo os nao construtivos, esclareceu muita coisa a respeito.

Quero deixar claro que minha intenção em momento algum é desmerecer o serviço de ngm nem do programador(sou um) e nem do peão de obra que sao servicos honestos assim como de um analista.

O que absorvi de toda essa discução?

R: Hierarquia existe em qualquer tipo de gestão e a comparação que fiz quem achou que é desmerecer alguem aposto que é programador que se achou desmerecido por compara-lo com peão de obra, mas fiz esse tipo de comparação em relação ao peão de obra ou pedreiro, porque logico que não é o mesmo serviço porém a metodologia de trabalho é semelhante pois geralmente o programador faz o que lhe é passado assim como o peão de obra.

Mais uma vez obrigado pelos comentarios.

Grato.

Samuel, achei que o seu tópico foi muito interessante. Abriu uma discussão importante porque muita gente tem a visão de que o programador é como um “peão de obra”.

Entendi que você não quis desmerecer a profissão. Também não vejo nenhum demérito na profissão de pedreiro ou trabalhador da construção civil. O fato é que há preconceito contra essa profissão.

Concordo que a metodologia de trabalho é semelhante. Mas acho que essa comparação não é boa porque, no cenário atual com linguagens orientadas a objetos e métodos iterativos, é necessário que o programador entenda o projeto, interfira, altere e refatore. Acho que no caso da construção civil essa interferência é bem menos comum.

Assim como você eu também amo programar, mas essas analogias me tiram do sério. Assim como contra o “peão de obra”, há um preconceito contra o programador, alguns acham que o programador é um “digitador de luxo”. Veja o post abaixo:

http://www.marcosdellantonio.net/2008/08/24/analista-desenvolvedor/

É por isso que eu me posiciono contra esse tipo de analogia e esse tipo de preconceito.

Nada contra os digitadores também, só acho que é diferente.

guilherme.dio:

O que eu acho de verdade:

Todos querem ter razão em tudo, e ninguém aceita quando alguém fala uma verdade.

Entendo o que disse.
É que para alguns que participam do forum, isso significa vender uma imagem.
Mas hoje no mundo de TI, não existe a melhor resposta pra tudo (verdade).
Depende dos seus objetovos, da sua estratégia de desenvolvimento, de gestão…
Cada pessoa tem suas limitações.
Comparar profissionais pode até ser algo interessante desde que seja feito com respeito.
As piadas geralmente são feitas por quem quer liberdade para tratar mal um funcionario, poder paga-lo mal ou mesmo demostrar poder.
E nesse ponto vc tem razão. Não dá pra comparar com quem não teve oportunidade de estudar sobre o assunto.

Otimo topico.

guilherme.dio:

O que eu acho de verdade:

Todos querem ter razão em tudo, e ninguém aceita quando alguém fala uma verdade.

Estamos colocando ponto de vista e quem ler vai ou não concordar, porém falar por falar até papagaio fala e nem por isso é verdade… :roll:
Não sou a dona da verdade, a unica verdade que conheço é que… “Só sei que nada sei.”

Bom, vamos lá.

Lendo as respostas, eu acredito que estamos misturando duas coisas completamente distintas: administração e desenvolvimento de software. O desenvolvimento é uma capacidade criativa, enquanto a administração tenta gerir o ecossistema funcional da empresa. Acontece que, a administração empresarial (com suas hierarquias, etc) não pode ter o bedelho no desenvolvimento.
Afinal, não existe um bom software com uma única voz, os bons softwares são feitos por times, e em times, todos são jogadores. Não é porquê existe o cargo de atacante que ele vai estar em escala superior ao zagueiro. Acontece que o atacante talvez ganhe mais pelo seu talento que o zagueiro. Entendem? Mas aí é outra questão.

A comparação só faria sentido se tivéssemos métodos tayloristas, aí eu concordaria 100%. Isso pode acontecer? Pode. Mas garanto que o produto gerado ficará muito pior, não necessariamente por isso, mas pelas implicações que esse tipo de visão traz consigo.

[]'s

Anime:

guilherme.dio:

O que eu acho de verdade:

Todos querem ter razão em tudo, e ninguém aceita quando alguém fala uma verdade.

Estamos colocando ponto de vista e quem ler vai ou não concordar, porém falar por falar até papagaio fala e nem por isso é verdade… :roll:
Não sou a dona da verdade, a unica verdade que conheço é que… “Só sei que nada sei.”

Sim, concordo com este seu ponto, mas também concorda que quando alguém fala uma verdade ninguem aceita, simplesmente por ser a verdade ?

Concordo plenamente acima de tudo liberdade de expressão e respeito ao próximo.

guilherme.dio:

Anime:

guilherme.dio:

O que eu acho de verdade:

Todos querem ter razão em tudo, e ninguém aceita quando alguém fala uma verdade.

Estamos colocando ponto de vista e quem ler vai ou não concordar, porém falar por falar até papagaio fala e nem por isso é verdade… :roll:
Não sou a dona da verdade, a unica verdade que conheço é que… “Só sei que nada sei.”

Sim, concordo com este seu ponto, mas também concorda que quando alguém fala uma verdade ninguem aceita, simplesmente por ser a verdade ?

Penso que não é assim se fomos discutir sobre verdades vai ser outro lupe infinto como esse tópico, minha verdade pode ser diferente da sua, o que tomo no café da manhã pode ser veneno para alguém…

Gostei muito da analogia do Yvga sobre o pedreiro ser o compilador, e não o programador. Faz todo sentido, inclusive no termo usado pelo próprio compilador (Build).

AUser:

Bom, vamos lá.

Lendo as respostas, eu acredito que estamos misturando duas coisas completamente distintas: administração e desenvolvimento de software. O desenvolvimento é uma capacidade criativa, enquanto a administração tenta gerir o ecossistema funcional da empresa. Acontece que, a administração empresarial (com suas hierarquias, etc) não pode ter o bedelho no desenvolvimento.
Afinal, não existe um bom software com uma única voz, os bons softwares são feitos por times, e em times, todos são jogadores. Não é porquê existe o cargo de atacante que ele vai estar em escala superior ao zagueiro. Acontece que o atacante talvez ganhe mais pelo seu talento que o zagueiro. Entendem? Mas aí é outra questão.

A comparação só faria sentido se tivéssemos métodos tayloristas, aí eu concordaria 100%. Isso pode acontecer? Pode. Mas garanto que o produto gerado ficará muito pior, não necessariamente por isso, mas pelas implicações que esse tipo de visão traz consigo.

[]'s

Estou pra conhecer esse lugar onde a administração não mete o bedelho no desenvolvimento.

Mas em relação ao futebol, o que me diz sobre o tecnico? Ele não faz parte do time e ao mesmo tempo esta numa escala superior na hierarquia?

Quando a tecnologia é mais do que suficiente (e a maioria das empresas se encaixa nessa categoria), qualidade passa representar outra coisa. Nessas circunstâncias qualidade significa 1) rapidez, 2) conveniência, 3) baixo custo, e não uma solução bem feita, usando uma linguagem moderna e a metodologia da moda, que todos nós programadores sonhamos.

Uma solução bem feita, usando linguagem moderna e a metodologia da moda não contribui diretamente para 1, 2 e 3.

Botocudo:

YvGa:

E teria 2x mais erros e situacoes inesperadas, o que poderia te levar a acreditar que estava com pessoal insuficiente, o que por consequencia te levaria a contratar mais um analista por metade do preço, te levando a 4x mais erros e situacoes inesperadas. Acredite, isso acontece, e muito. E diagnosticar este problema é muito dificil.

E no final das contas a tua suposta economia vai te custar muito mais caro, alem de dar um produto de baixa qualidade.

Quando a tecnologia é mais do que suficiente (e a maioria das empresas se encaixa nessa categoria), qualidade passa representar outra coisa. Nessas circunstâncias qualidade significa 1) rapidez, 2) conveniência, 3) baixo custo, e não uma solução bem feita, usando uma linguagem moderna e a metodologia da moda, que todos nós programadores sonhamos.

Uma solução bem feita, usando linguagem moderna e a metodologia da moda não contribui diretamente para 1, 2 e 3.

Cara, sei que tem administradores que pensam assim.

Mas já vi sistemas dando tanto erro que não dava para usar. O que adiantou a rapidez, conveniência e baixo custo?

Acho que não é questão de linguagem moderna e metodologia da moda, porque se isso for mal utilizado não adianta nada.

Botocudo:

YvGa:

E teria 2x mais erros e situacoes inesperadas, o que poderia te levar a acreditar que estava com pessoal insuficiente, o que por consequencia te levaria a contratar mais um analista por metade do preço, te levando a 4x mais erros e situacoes inesperadas. Acredite, isso acontece, e muito. E diagnosticar este problema é muito dificil.

E no final das contas a tua suposta economia vai te custar muito mais caro, alem de dar um produto de baixa qualidade.

Quando a tecnologia é mais do que suficiente (e a maioria das empresas se encaixa nessa categoria), qualidade passa representar outra coisa. Nessas circunstâncias qualidade significa 1) rapidez, 2) conveniência, 3) baixo custo, e não uma solução bem feita, usando uma linguagem moderna e a metodologia da moda, que todos nós programadores sonhamos.

Uma solução bem feita, usando linguagem moderna e a metodologia da moda não contribui diretamente para 1, 2 e 3.

So nao tenho certeza o que voce quis dizer com conveniencia, se é a satisfacao do cliente tendo exatamente aquilo que ele pediu, eu concordo com voce. É isso que é qualidade.

1)rapidez: Uma solucao bem feita traz rapidez, porque código bem feito é mais facil de ser compreendido, alterado, testado, etc… Possibilitando maior velocidade no desenvolvimento. O grande problema é que codigo bem feito, que trará velocidade são feitos normalmente por programadores caros. Enquanto programadores “baratos”, geram uma massaroca de codigo quase incompreensivel, diminuindo o tempo de resposta da equipe, diminuindo a velocidade e finalmente aumentando o custo, porque na esperança de aumentar a velocidade da equipe mais programadores “baratos” são contratados. Muitas vezes aumentando ainda mais a confusao do produto.

2. conveniência: Linguagem moderna e metodologia da moda não servem pra nada se não atenderem ao que o cliente deseja. Aí está o que seria a conveniencia. Entao, nesse ponto eu concordo com voce.

3. baixo custo: Este é o ponto mais complexo. É complexo porque apesar de parecer óbvio que quanto menor o seu custo maior o seu lucro, a conta pode ser traiçoeira em alguns casos. E no nosso caso (software) ela é traiçoeira, e muito. E é exatamente este o assunto do tópico, e exatamente por isso que essa comparação de programador com alguem que simplesmente executa um serviço repetitivo, previsivel, quase mecanico, pode levar a um erro muito grande na relação custo/lucro.

Se eu tenho uma construtora, preciso escolher entre dois pedreiros, um pediu X dinheiros, outro 2X, eu posso contratar o que pediu X e supervisionar o trabalho dele, garantindo a qualidade do que ele faz. Se a velocidade dele for 30% menor daquele de 2X eu sairei no lucro.

Aplicando o exemplo dos dois pedreiros à programação vamos ver o que acontece:

Primeiro, a maioria das empresas aplicaria uma provinha aos dois pedreiros pra garantir que eles sabem a diferença entre cimento e cal. Contrataria o mais barato e daria um treinamento para que ele aprenda a forma da empresa de empilhar tijolos. A partir dai é com ele.

Na primeira semana o cliente liga dizendo que a parede que o pedreiro estava fazendo caiu. Ok, acontece, principalmente no começo, ainda não está habituado com o tipo dos tijolos. Tudo bem, é só refazer a parede. Mais uma semana e o cliente liga dizendo que apesar da parede estar de pé, quando chove verte água, pelos vãos que ficaram na parede. Hmmm, é que ele tinha deixado aqueles espaços para agilizar, porque o tempo estava curto, estavam pressionando, a parede tinha que estar pronta até sexta, então ele fez correndo. E a parede foi homologada, mas somente para dias de sol, ninguem se tocou da chuva.

Então ele vai arrumar os buracos que deixou na parede, quebrar um monte de tijolos, fazer umas gambiarras pra tapar os buracos. O cliente vai olhar, ver que ta feio, mas já gastou uma fortuna na casa e se for pedir pra deixar como ele gostaria mesmo, vai levar mais tempo ainda. Então ele aceita, construção civil é assim mesmo.

E como está tudo atrasado, o prazo já se foi, foram tres semanas pra fazer uma parede, quando deveria ter ido uma, entao como faltam 3 paredes, mas so se tem uma semana, contrata-se mais 3 pedreiros por X dinheiros. E assim por diante…

A unica diferença entre este exemplo e o desenvolvimento de software é que no caso de software o problema óbvio do exemplo acima não é tão obvio.

A diferença de produtividade entre dois programadores não é proporcional ao salario, ela é exponencial. É preciso muito cuidado nesse corte de custos aí. Ao contratar um programador de 2.5K ao invés de um de 5K pode fazer com que no fim das contas voce precise de mais uns dois ou tres de 2.5K, e ainda assim eles nao resolvam, o que vai te obrigar a enfim, desesperadamente contratar um de 5K. No fim das contas quando esta gasta 12K por mes, quando poderia estar gastando 5. E ainda assim voce tem 3 programadores de 2.5K gerando bug, um em cima do outro e um só removendo.

Só cuidado ao contratar pra nao pagar 5K pra um programador que vale 2.

al.barbosa:

Cara, sei que tem administradores que pensam assim.

Mas já vi sistemas dando tanto erro que não dava para usar. O que adiantou a rapidez, conveniência e baixo custo?

Acho que não é questão de linguagem moderna e metodologia da moda, porque se isso for mal utilizado não adianta nada.

Adianta porque a alternativa, que seria contar com os melhores programadores na equipe, tb não é garantia que o resultado seria diferente.

1. Estou me referindo a rapidez no desenvolvimento. Todos nos sabemos que código bem feito não traz rapidez no desenvolvimento, pelo contrário, da mais trabalho.

2. Atender o que o cliente deseja não é uma conveniência, a não ser que o fracasso seja uma opção. Por conveniência me refiro por exemplo a usar frameworks de referência no lugar de soluções originais para evitar que alguém na equipe se torne indispensável para o projeto.

3. Na verdade esse é o mais simples. Tudo que contribui para redução de custo é bem vindo! Usar linguagem de mercado, por exemplo, é uma maneira de evitar programadores caros.

Se o cliente do software não é capaz de supervisionar o trabalho e medir a qualidade do que esta sendo produzido contratar o programador que vale 2 é a opção que oferece menos risco.

Botocudo:

al.barbosa:

Cara, sei que tem administradores que pensam assim.

Mas já vi sistemas dando tanto erro que não dava para usar. O que adiantou a rapidez, conveniência e baixo custo?

Acho que não é questão de linguagem moderna e metodologia da moda, porque se isso for mal utilizado não adianta nada.

Adianta porque a alternativa, que seria contar com os melhores programadores na equipe, tb não é garantia que o resultado seria diferente.

Acho que a questão não é ter linguagem moderna, é ter a linguagem adequada a cada necessidade.

Usar uma metodologia só porque está na moda também não resolve o problema. Acho que é preciso usar a metodologia adequada a cada caso, e adaptar de acordo com a equipe. Existem metodologias novas que estão fazendo sucesso e é preciso conhecê-las, saber quando usar e quando não usar. Se não aprendermos novas metodologias, iremos permanecer no ciclo de vida em cascata com todos os problemas que ele pode trazer.

Acho que a alternativa não é apenas contar com os melhores programadores na equipe. Acho que é contar com programadores, analistas, arquitetos, testadores, pessoas com competência necessária para fazer um bom trabalho. Não é possível sempre contar com os melhores, mas acho importante ter pessoas que consigam fazer um bom trabalho de acordo com as necessidades.

Certamente é preciso considerar custo e rapidez. Mas abrir mão de um sistema bem feito acho que não resolve o problema. Muitas vezes um sistema feito sem planejamento, sem preocupação com qualidade, acaba consumindo mais tempo de desenvolvimento devido ao retrabalho. É preciso corrigir muita coisa, há trabalho duplicado. Sem falar na dificuldade de manutenção depois.

Botocudo:

Se o cliente do software não é capaz de supervisionar o trabalho e medir a qualidade do que esta sendo produzido contratar o programador que vale 2 é a opção que oferece menos risco.

Sim, então o carinha que vale por 2 escolheria a tecnologia que iria utilizar. E não o cliente.

:shock: :shock: :shock: :shock: :shock:

Uma das coisas que mais atrasa o desenvolvimento é codigo mal feito. Código bem feito traz simplicidade, facilidade de alteração, extensao, compreensao, testabilidade. Ele te da muito mais velocidade no desenvolvimento. O grande problema é saber fazer codigo. Escrever bom código é dificil, requer muito tempo de estudo e prática. Mas nunca, em nenhuma circunstancia, sob nenhuma hipótese, código bem feito diminui a velocidade no desenvolvimento.

Concordo que usar coisas que sao padroes de mercado é menos arriscado que solucoes caseiras. Sim, primeiro porque vai ser dificil encontrar alguem no mercado que esteja disposto a por a mal naquela porcaria toda que foi feita. E porque ferramentas padroes sao usadas por muitas pessoas, tem seus problemas resolvidos rapidamente, são mais madura e etc…

Atender o que o cliente deseja é uma obrigação da empresa. “Ah, mas o cliente quer tudo e ao mesmo tempo não sabe o que quer”, voce vai dizer. Não ele sabe exatamente o que quer, o que ele geralmente não sabe é como te dizer isso, já que voce não conhece a fundo o problema dele. Existe muito estudo nessa área e muitas técnicas recentes que diminuem esse abismo de comunicacao entre nós e o cliente, o que faz com que estejamos bem mais próximos daquilo que ele realmente deseja. Cabe a nós estudarmos essas técnicas e as aplicarmos. Não simplesmente dizer, “ah o cliente é burro e nao sabe o que quer, se eu for dar ouvidos a ele estou f…”. Se voce pensa assim, quem esta f… é ele.

Enquanto voce tentar evitar programadores caros voce só vai construir produtos de merda.

Botocudo:

Se o cliente do software não é capaz de supervisionar o trabalho e medir a qualidade do que esta sendo produzido contratar o programador que vale 2 é a opção que oferece menos risco.

Com o tempo voce vai descobrir, mas existem programadores capazes de substituir uma equipe inteira e ainda ter tempo para trabalhar em projetos novos. Eu já vi isso acontecer e mais de uma vez.

Se voce não acredita em mim, simplesmente meça. Veja onde voce trabalha qual o numero de demandas que são abertas por efeitos colaterais, códigos quebrados, implementações mal feitas, regras deixadas de lado e coisas do genero. Verifique quanto do tempo se gasta com correções e quanto com melhorias. Quase todo o tempo que voce gasta corrigindo bugs não existira se voce mantivesse somente bons programadores. Bons programadores, alem de automatizarem muita coisa, mas muita coisa mesmo, utilizam a maior parte do seu tempo para criar novas funcionalidades, não para ficar corrigindo besteira que fizeram.

Poderia trabalhar com qualquer solução comercial, mas eu prefiro por a mão em “porcaria”.

1º motivo: sou programador;

2º motivo: quero aprender;

3º motivo: quando existe um bug é fácil encontrar onde está;

4º motivo: gosto de inovar e arriscar faz parte deste negócio;

Se alguem ai tiver alguma “porcaria” em mãos e queira uma ajuda tamos ai.

Conheço uma galera que hoje tá chorando nos Delphis 5,6,7 porque utilizaram soluções comerciais e estão sendo obrigados a “refatorar” todo o codigo para versões mais novas do Delphi ou mudando para o C#.
As DLLs comerciais do Delphi antigas não funcionam nas versões mais novas do windows. Se vc acha que o mesmo não pode acontecer com as soluções comerciais para Java e C# então boa sorte.

Nem vai deixar de ser se concentrar-se apenas no problema do seu cliente.

Aprender é uma coisa, usar algo profissionalmente, enquanto deveria ser apenas teste é outra bem diferente.

Se foi bem feito, se foi voce quem fez e se for pequeno. Do contrario pode se tornar um inferno.

Sim, quando há ganho. Mas tem que cuidar com riscos desnecessarios.

Acho que voce esta confundindo criar um produto com usar uma solucao caseira quando já existem outras no mercado.

Uma coisa é voce criar uma ferramenta do zero, utiliza-la em projetos pessoais, testar, validar, distribuir para os amigos e liberar para a comunidade. Nesse caso eu te apoiaria sempre. Mas outra coisa bem diferente é voce arriscar uma ferramenta, completamente diferente só porque você quer aprender o conceito de MVC enquanto o seu cliente espera uma solucao que poderia perfeitamente ser feita em php sem maiores problemas.

Há casos e casos. Sim, existem, e muitas, empresas que estao presas nos Delphis 5 e 6 e agora tem que correr atras do prejuizo. E isso vai acontecer com Java tambem. Mas qual a solucao? As tecnologias se sobrepoem uma a outra muito rapidamente e mesmo as suas proprias solucoes estão sujeitas a deixar de funcionar em SOs mais novos, ou hardwares mais novos. A diferenca é que se voce escreve sua propria solução, voce vai saber muito facilmente escreve-la em outra linguagem. Entao voce tem uma vantagem, mas a sua vantagem é o conhecimento em si, não a ferramenta “caseira” sua.

Veja, se eu preciso de um ORM por que eu vou escrever um se eu tenho um disponivel, maduro e bem aceito? A nao ser que seja para estudo eu nao vejo sentido.

Agora, é minha obrigação saber como as coisas funcionam por baixo dos panos, pelo menos o suficiente para o que eu estou usando. Saber como e porque as coisas acontecem fazem muita diferença.

Mas as soluções caseiras tendem a ser pior do que solucoes comerciais, ou da comunidade, via de regra. Talvez voce quando voce argumente voce tenha em mente algo que seja uma excecão a esta regra. Mas normalmente o resultado dessas tentativas malucas de soluções caseiras para problemas que já foram resolvidos é um desastre.

YvGa:

Luiz Augusto Prado:

Poderia trabalhar com qualquer solução comercial, mas eu prefiro por a mão em “porcaria”.
1º motivo: sou programador;

Nem vai deixar de ser se concentrar-se apenas no problema do seu cliente.

Aprender é uma coisa, usar algo profissionalmente, enquanto deveria ser apenas teste é outra bem diferente.

Se foi bem feito, se foi voce quem fez e se for pequeno. Do contrario pode se tornar um inferno.

Sim, quando há ganho. Mas tem que cuidar com riscos desnecessarios.

Acho que voce esta confundindo criar um produto com usar uma solucao caseira quando já existem outras no mercado.

Uma coisa é voce criar uma ferramenta do zero, utiliza-la em projetos pessoais, testar, validar, distribuir para os amigos e liberar para a comunidade. Nesse caso eu te apoiaria sempre. Mas outra coisa bem diferente é voce arriscar uma ferramenta, completamente diferente só porque você quer aprender o conceito de MVC enquanto o seu cliente espera uma solucao que poderia perfeitamente ser feita em php sem maiores problemas.

Há casos e casos. Sim, existem, e muitas, empresas que estao presas nos Delphis 5 e 6 e agora tem que correr atras do prejuizo. E isso vai acontecer com Java tambem. Mas qual a solucao? As tecnologias se sobrepoem uma a outra muito rapidamente e mesmo as suas proprias solucoes estão sujeitas a deixar de funcionar em SOs mais novos, ou hardwares mais novos. A diferenca é que se voce escreve sua propria solução, voce vai saber muito facilmente escreve-la em outra linguagem. Entao voce tem uma vantagem, mas a sua vantagem é o conhecimento em si, não a ferramenta “caseira” sua.

Veja, se eu preciso de um ORM por que eu vou escrever um se eu tenho um disponivel, maduro e bem aceito? A nao ser que seja para estudo eu nao vejo sentido.

Agora, é minha obrigação saber como as coisas funcionam por baixo dos panos, pelo menos o suficiente para o que eu estou usando. Saber como e porque as coisas acontecem fazem muita diferença.

Mas as soluções caseiras tendem a ser pior do que solucoes comerciais, ou da comunidade, via de regra. Talvez voce quando voce argumente voce tenha em mente algo que seja uma excecão a esta regra. Mas normalmente o resultado dessas tentativas malucas de soluções caseiras para problemas que já foram resolvidos é um desastre.

Ok amigo!
Como lhe disse, poderia sim trabalhar com qualquer outra solução comercial, mas minha preferência é evita-las.
Vc quer utilizar soluções comerciais ou de comunidade? OK utiliza, mas não diga que outras formas de pensamento são ruins, porque antes delas surgirem, já existiam softwares feitos na unha. É deles que vieram muitas das idéias que são utilizadas hoje.
Quer ver um exemplo legal de alguem que também não tá preso no quadrado?
Dá uma olhada nesse perfil, na assinatura desse cara aqui do GUJ. Escolhe qualquer mensagem dele e veja:
http://www.guj.com.br/user/profile/2702.java
Eu já sou fã das annotatiosn, mas ai entra no gosto meu. Algo do qual ele não se interessa pelos motivos dele.
Se acha que isso possa parecer arrogancia nossa, me desculpe, mas ai o problema já é seu.

Outro exemplo pra quem gosta de socar alquer solução comercial ou de comunidade:

Se vc for fazer algum software para banco, controle de tráfego aréreo ou para uma usina nuclear, eu pensaria em utilizar algo como C ou Cobol e fazer tudo na unha.
Se vc não sabe quem fez e como foi feito, não se arrisque em qualquer projeto.

Luiz Augusto Prado:

YvGa:

Luiz Augusto Prado:

Poderia trabalhar com qualquer solução comercial, mas eu prefiro por a mão em “porcaria”.
1º motivo: sou programador;

Nem vai deixar de ser se concentrar-se apenas no problema do seu cliente.

Aprender é uma coisa, usar algo profissionalmente, enquanto deveria ser apenas teste é outra bem diferente.

Se foi bem feito, se foi voce quem fez e se for pequeno. Do contrario pode se tornar um inferno.

Sim, quando há ganho. Mas tem que cuidar com riscos desnecessarios.

Acho que voce esta confundindo criar um produto com usar uma solucao caseira quando já existem outras no mercado.

Uma coisa é voce criar uma ferramenta do zero, utiliza-la em projetos pessoais, testar, validar, distribuir para os amigos e liberar para a comunidade. Nesse caso eu te apoiaria sempre. Mas outra coisa bem diferente é voce arriscar uma ferramenta, completamente diferente só porque você quer aprender o conceito de MVC enquanto o seu cliente espera uma solucao que poderia perfeitamente ser feita em php sem maiores problemas.

Há casos e casos. Sim, existem, e muitas, empresas que estao presas nos Delphis 5 e 6 e agora tem que correr atras do prejuizo. E isso vai acontecer com Java tambem. Mas qual a solucao? As tecnologias se sobrepoem uma a outra muito rapidamente e mesmo as suas proprias solucoes estão sujeitas a deixar de funcionar em SOs mais novos, ou hardwares mais novos. A diferenca é que se voce escreve sua propria solução, voce vai saber muito facilmente escreve-la em outra linguagem. Entao voce tem uma vantagem, mas a sua vantagem é o conhecimento em si, não a ferramenta “caseira” sua.

Veja, se eu preciso de um ORM por que eu vou escrever um se eu tenho um disponivel, maduro e bem aceito? A nao ser que seja para estudo eu nao vejo sentido.

Agora, é minha obrigação saber como as coisas funcionam por baixo dos panos, pelo menos o suficiente para o que eu estou usando. Saber como e porque as coisas acontecem fazem muita diferença.

Mas as soluções caseiras tendem a ser pior do que solucoes comerciais, ou da comunidade, via de regra. Talvez voce quando voce argumente voce tenha em mente algo que seja uma excecão a esta regra. Mas normalmente o resultado dessas tentativas malucas de soluções caseiras para problemas que já foram resolvidos é um desastre.

Ok amigo!
Como lhe disse, poderia sim trabalhar com qualquer outra solução comercial, mas minha preferência é evita-las.
Vc quer utilizar soluções comerciais ou de comunidade? OK utiliza, mas não diga que outras formas de pensamento são ruins, porque antes delas surgirem, já existiam softwares feitos na unha. É deles que vieram muitas das idéias que são utilizadas hoje.
Quer ver um exemplo legal de alguem que também não tá preso no quadrado?
Dá uma olhada nesse perfil, na assinatura desse cara aqui do GUJ. Escolhe qualquer mensagem dele e veja:
http://www.guj.com.br/user/profile/2702.java
Eu já sou fã das annotatiosn, mas ai entra no gosto meu. Algo do qual ele não se interessa pelos motivos dele.
Se acha que isso possa parecer arrogancia nossa, me desculpe, mas ai o problema já é seu.

Engraçado você ter citado o saoj, pois até onde eu sei ele criou o Mentawai, que é também um projeto de código aberto.

Até concorodo com você de que é um risco confiar em qualquer solução pronta, seja comercial ou aberta à comunidade, mas acho um tanto radical fazer tudo na unha.

Nao sei porque voce se ofendeu.

Sim, eu acho que solucoes caseiras sao ruins na maioria dos casos. É obvio que grandes ideias, grandes software, surgiram de solucoes implementadas na unha. Mas elas nascem da necessidade, não por simplesmente achar arriscado usar uma solução já pronta. Claro que voce nao vai sair cegamente usando a primeira coisa que aparecer, mas quando o que voce precisa é simplesmente fazer um e-commerce simples para um cliente voce não precisa para isso criar um novo sistema gerenciador de banco de dados relacionais, voce tem um monte aí pra escolher.

Agora, se voce tem novas ideias, conceitos ou simplesmente quer entender como funciona um algoritmo de SGBD voce pode criar um novo e dessa sua tentativa pode nascer um grande produto. Ou ainda pode ser que para o seu problema especifico um SGDB não funcione bem e voce precise de algo diferente. Ou pode ser ainda que voce não goste de como os SGBD sao implemetados e prefira ter a sua propria implementacao.

Mas veja, sao casos excepcionais, se só o que o cliente precisa é de um e-commerce simples, voce criar um framework MVC, um ORM, um XML parser e um SGDB é desnecessário. E fazer isso só porque voce quer original na sua solução ou não quer ficar refem de ferramentas de terceiro é exagero.

Eu só utilizo esse princípio nos projetos pessoais.
Citei ele porque ele começou pensando em mudar algo que não gostava.
Isso que achei bacana.
O cara teve atitude de pensar diferente e mandou ver.

rmendes08:

Até concorodo com você de que é um risco confiar em qualquer solução pronta, seja comercial ou aberta à comunidade, mas acho um tanto radical fazer tudo na unha.

Por favor, não me interprete mal.
Sei que muitas destas soluções são excelentes.
Só acho que não podemos utiliza-las em tudo.
No meu caso tento me preparar para não utiliza-las.
Quando vejo a história de sites e bancos atacados penso nessas possibilidades.
Não sei quem fez nem como foi feito. As vezes a intenção dos autores realmente são boas e inocentes, mas nem sempre isso nos livra dos erros e dos bugs. Quando o fote é aberto, a comunidade hacker tem a chance de estudar as falhas e trocar conhecimentos sobre elas.
Eu vou vou errar? Com certeza, mas até alguem ter ânimo de pegar meu projeto e encontrar as falhas e explorá-las, isso pode demorar.
Os EUA, que tem a economia como uma extensão do segmento militar, dificilmente confiam em programas de terceiros.
Acho isso muito admiravel e inteligente da parte deles. Por que o Brsileiro também não segue o exemplo?

YvGa:

:shock: :shock: :shock: :shock: :shock:

Uma das coisas que mais atrasa o desenvolvimento é codigo mal feito. Código bem feito traz simplicidade, facilidade de alteração, extensao, compreensao, testabilidade. Ele te da muito mais velocidade no desenvolvimento. O grande problema é saber fazer codigo. Escrever bom código é dificil, requer muito tempo de estudo e prática. Mas nunca, em nenhuma circunstancia, sob nenhuma hipótese, código bem feito diminui a velocidade no desenvolvimento.

Acho que esta se contradizendo aqui. Você diz que bom código é difícil e requer muito tempo, ao mesmo tempo não consegue imaginar uma circunstância onde isso pode diminuir a velocidade???

YvGa:

Concordo que usar coisas que sao padroes de mercado é menos arriscado que solucoes caseiras. Sim, primeiro porque vai ser dificil encontrar alguem no mercado que esteja disposto a por a mal naquela porcaria toda que foi feita. E porque ferramentas padroes sao usadas por muitas pessoas, tem seus problemas resolvidos rapidamente, são mais madura e etc…

Atender o que o cliente deseja é uma obrigação da empresa. “Ah, mas o cliente quer tudo e ao mesmo tempo não sabe o que quer”, voce vai dizer. Não ele sabe exatamente o que quer, o que ele geralmente não sabe é como te dizer isso, já que voce não conhece a fundo o problema dele. Existe muito estudo nessa área e muitas técnicas recentes que diminuem esse abismo de comunicacao entre nós e o cliente, o que faz com que estejamos bem mais próximos daquilo que ele realmente deseja. Cabe a nós estudarmos essas técnicas e as aplicarmos. Não simplesmente dizer, “ah o cliente é burro e nao sabe o que quer, se eu for dar ouvidos a ele estou f…”. Se voce pensa assim, quem esta f… é ele.

Não. O que estou dizendo é que qualidade representa outra coisa. A maioria dos clientes não esta interessado em código elegante, e sim no que ele faz.

O verdadeiro abismo aqui portanto é que, diferente dos programadores, o cliente não está disposto a pagar um premium por código simples e nem esta preocupado com a facilidade que o programador vai ter pra dar manutenção no futuro. Quem fala isso (que o cliente não sabe o que quer) esta apenas tentando impor sua visão de programador goela abaixo.

YvGa:

Enquanto voce tentar evitar programadores caros voce só vai construir produtos de merda.

Se for bom o suficiente para o cliente ele vai ficar feliz.

Eu até acredito em vc. O problema com o seu argumento é que ele depende de uma maneira confiável para se medir a qualidade de um programador. Coisa que não existe ainda.

Ele falou que requer tempo de estudo para aprender a saber fazer código bom. Ou seja, você precisa de um programador estudado.
Acho que você entendeu o contexto pela metade.

Ele falou que requer tempo de estudo para aprender a saber fazer código bom. Ou seja, você precisa de um programador estudado.
Acho que você entendeu o contexto pela metade.

Se você ler novamente, vai ver que ele disse estudo e prática.

Isso. Mas isso para formar um programador assim. Depois de formado, ele produz código elegante e rápido.

O problema, claro, é que se programa em equipe. E geralmente você não poderá ter só seniores nela.

Além disso, nem sempre o perfil de profissional elegante é adequado no dia-a-dia. Há sim, situações em que a correção precisa ser feita para ontem, e que um código rápido e sujo pode ter um impacto menor (do ponto de vista de atendimento e de gestão da sua marca) do que deixar o cliente esperando por uma solução elegante para o problema. Cabe à gestão saber quem programa de que forma, e colocar os programadores experientes para corrigirem o bug em definitivo, que os rápidos remendaram.

Como se existisse essa coisa de programador formado…

Não existe, todo projeto requer estudo para se projetar uma boa solução.

A não ser claro, quem passa a vida toda resolvendo o mesmo tipo de problema.

Isso. Mas isso para formar um programador assim. Depois de formado, ele produz código elegante e rápido.

O problema, claro, é que se programa em equipe. E geralmente você não poderá ter só seniores nela.

Além disso, nem sempre o perfil de profissional elegante é adequado no dia-a-dia. Há sim, situações em que a correção precisa ser feita para ontem, e que um código rápido e sujo pode ter um impacto menor (do ponto de vista de atendimento e de gestão da sua marca) do que deixar o cliente esperando por uma solução elegante para o problema. Cabe à gestão saber quem programa de que forma, e colocar os programadores experientes para corrigirem o bug em definitivo, que os rápidos remendaram.

Sim, concordo com voce. Muitas vezes, num sistema ja em producao essa é uma pratica comum. Poe um if la, resolve o problema, libera para o usuario e depois, dependendo das prioridades corrige de maneira definitiva.

O problema que eu vejo com relacao a codigo bem escrito, com código feito na correria é que em projetos novos se tem a impressao de que se vai mais rapido com codigo feito de qualquer jeito, do que ficar pensando, analisando, imaginando como fazer.

Mas há duas coisas a serem observadas:

1. As funcionalidade sao revisitadas muito antes do sistema entrar em producao. Por isso, em projetos de medio porte pra cima, o codigo mal feito ja comeca a cobrar seu preco muito cedo. E muito provavelmente vai chegar o momento em que ele vai começar a atrasar o projeto, antes mesmo de ser entregue.

2. Código bem escrito não demora para ser pensado. Com a experiencia uma solucao elegante surge já de cara, voce não vai passar por um longo processo de análise para que ela venha a cabeça.

Lembrando que o meu discurso é contra a ideia de que programador barato significa redução de custo.

Como se existisse essa coisa de programador formado…

Não existe, todo projeto requer estudo para se projetar uma boa solução.

A não ser claro, quem passa a vida toda resolvendo o mesmo tipo de problema.

Agora eu concordo plenamente com voce.

Mas o que o ViniGodoy usou foi forca de expressao, o que ele quis dizer é que quanto mais experiencia tiver um programador, a tendencia é de que mais bem feito seja o codigo dele.

É só voce lembrar quando voce estava comecando, hoje com certeza voce consegue ser bem mais produtivo, porque tem bem mais experiencia. E desse mesmo jeito, voce vai continuar evoluindo. E quanto mais evoluir, maior sera sua produtividade. O mesmo vale para mim, para o Vini e para qualquer um que tenha interesse de estudar e melhorar as praticas.

Programadores menos experientes conhecem menos padrões de projeto, viram menos situações onde aplicá-los. Quase nunca ouviram falar de refatoração. Também erraram pouco, portanto, ainda terão que aprender na prática muitas das coisas que funcionam ou não. No caso dos júniores, erram muitas vezes por falta de experiência empresarial também. Seja por não compreender direito porque de certos requisitos, ou por não saberem como seu código vai afetar outros membros da equipe…

E você vem dizer que não existe isso de “programador formado”?

Claro, para um sistema novo, uma equipe por mais sênior que seja, terá mais chances de errar. Por outro lado, programadores mais experientes tendem a ler com mais atenção manuais, procuram entender as razões dos erros, sabem debugar o código e não tem muita preguiça de alterá-lo quando percebem que erraram. E, por mais que percam um pouco mais de tempo no começo, entendendo a nova tecnologia, esse tempo é mais do que recuperado depois, especialmente na fase de manutenção.

Tem muito programador por aí que quando percebe que errou, faz um remendo para contornar o problema, ou vai levando o erro com a barriga. E aí, como o Yvga comentou, adeus produtividade.

YvGa:

Mas o que o ViniGodoy usou foi forca de expressao, o que ele quis dizer é que quanto mais experiencia tiver um programador, a tendencia é de que mais bem feito
seja o codigo dele.

Não. Isso quem disse fui eu.

Ele disse uma vez formado o programador esta pronto. Ou seja, ignorou experiência.

Sim. O que eu disse é que esse processo de adquirir experiência reduz velocidade.

YvGa:

Lembrando que o meu discurso é contra a ideia de que programador barato significa redução de custo.

Você pode até acreditar mais no potencial de uma estratégia pensada a longo prazo, mas a redução de custo no curto prazo, isso é um fato verificado.

Vc mesmo disse que não poria as mãos nesta “porcaria”.
Ok, escolha sua.
Eu procuro gente que pense diferente e sem preconceitos.

Luiz Augusto Prado:

YvGa:

E fazer isso só porque voce quer ser original na sua solução ou não quer ficar refem de ferramentas de terceiro é exagero.

Vc mesmo disse que não poria as mãos nesta “porcaria”.
Ok, escolha sua.
Eu procuro gente que pense diferente e sem preconceitos.

Vou te dar um exemplo do que eu tinha em mente quando disse isso. Trabalhei numa empresa onde um dos diretores apostou num framework proprio, feito em java, para que cobrisse tudo o que se precisava nos projetos em que trabalhavamos. Desde MVC, comunicacao com banco, web services etc…

Foram gastos dois anos com dois arquitetos trabalhando na solucao ideal que resolveria todos os nossos problemas. O resultado disso foi terrivel, um framework pessimo, cru, que tinha um desempenho muito ruim, codigos indecifraveis, nenhum pouco intuitivo e muito dificil de dar manutencao.

Esse framework causou um caos no desenvolvimento, mas como o diretor preferia nos empurrar ele guela abaixo do que dar o braco a torcer e dizer que a aposta que ele fez nao deu em nada, tivemos que continuar com ele. A primeira consequencia foi a saida de alguns programadores, logo depois, outros que já haviam tentado por sistemas menores em producao comecaram a se recusar a trabalhar com ele (eu entre eles), ao que conseguirmos com muito custo, e muita desculpa do porque do nosso projeto nao se encaixar com o framework novo.

A ferramenta so foi abandonada de vez quando provocou a falha, o cancelamento e um grande prejuizo para a empresa, em projeto de substituicao de um sistema antigo por um novo feito na tal ferramenta. A aplicacao chegou a ir pro ar, ficou uma semana e teve que ser revertida para antiga e depois o projeto simplesmente cancelado. A essa epoca os dois arquitetos já nao estavam na empresa faz tempo. E não se sabe como a cabeça do diretor se safou.

Entao o que eu quero dizer é: Se voce tem um projeto proprio que por paixao pela criacao voce leva a frente apesar de tudo, eu vou te apoiar incondicionalmente. Mesmo que nao de em nada o seu projeto, mesmo que já hajam 500 iguais, pois são de pessoas assim que nascem os grandes produtos.

Mas se voce quiser me empurrar uma solucao maluca no meu dia-a-dia, quando eu sei que tenho algo a mao bem mais simples pra resolver meu problema, na sua empresa eu nao trabalho.

Opa! Não foi isso que eu disse. Quando falei em “formado” estava me referindo ao bom programador, não a um recém formado de faculdade.
Um bom programador, para se tornar bom, precisa da experiência. Você está recortando só trechos do que a gente fala de propósito?

Mas vc não reseta a experiência entre um projeto e outro.

YvGa:

Luiz Augusto Prado:

YvGa:

E fazer isso só porque voce quer ser original na sua solução ou não quer ficar refem de ferramentas de terceiro é exagero.

Vc mesmo disse que não poria as mãos nesta “porcaria”.
Ok, escolha sua.
Eu procuro gente que pense diferente e sem preconceitos.

Vou te dar um exemplo do que eu tinha em mente quando disse isso. Trabalhei numa empresa onde um dos diretores apostou num framework proprio, feito em java, para que cobrisse tudo o que se precisava nos projetos em que trabalhavamos. Desde MVC, comunicacao com banco, web services etc…

Foram gastos dois anos com dois arquitetos trabalhando na solucao ideal que resolveria todos os nossos problemas. O resultado disso foi terrivel, um framework pessimo, cru, que tinha um desempenho muito ruim, codigos indecifraveis, nenhum pouco intuitivo e muito dificil de dar manutencao.

Esse framework causou um caos no desenvolvimento, mas como o diretor preferia nos empurrar ele guela abaixo do que dar o braco a torcer e dizer que a aposta que ele fez nao deu em nada, tivemos que continuar com ele. A primeira consequencia foi a saida de alguns programadores, logo depois, outros que já haviam tentado por sistemas menores em producao comecaram a se recusar a trabalhar com ele (eu entre eles), ao que conseguirmos com muito custo, e muita desculpa do porque do nosso projeto nao se encaixar com o framework novo.

A ferramenta so foi abandonada de vez quando provocou a falha, o cancelamento e um grande prejuizo para a empresa, em projeto de substituicao de um sistema antigo por um novo feito na tal ferramenta. A aplicacao chegou a ir pro ar, ficou uma semana e teve que ser revertida para antiga e depois o projeto simplesmente cancelado. A essa epoca os dois arquitetos já nao estavam na empresa faz tempo. E não se sabe como a cabeça do diretor se safou.

Entao o que eu quero dizer é: Se voce tem um projeto proprio que por paixao pela criacao voce leva a frente apesar de tudo, eu vou te apoiar incondicionalmente. Mesmo que nao de em nada o seu projeto, mesmo que já hajam 500 iguais, pois são de pessoas assim que nascem os grandes produtos.

Mas se voce quiser me empurrar uma solucao maluca no meu dia-a-dia, quando eu sei que tenho algo a mao bem mais simples pra resolver meu problema, na sua empresa eu nao trabalho.

Ok!
Deixa eu ver aqui nos arquivos da empresa…
Ahh. Achei seu curriculo.
Pronto, já foi pro lixo.
Próximo…

Opa! Não foi isso que eu disse. Quando falei em “formado” estava me referindo ao bom programador, não a um recém formado de faculdade.
Um bom programador, para se tornar bom, precisa da experiência. Você está recortando só trechos do que a gente fala de propósito?

Mas vc não reseta a experiência entre um projeto e outro.

Só pra lembrar você, a questão aqui é se código bem feito da mais trabalho e portanto leva mais tempo para se produzir. Não tem nada a ver com resetar experiência.

Por favor, não fique mudando o foco da conversa só para tentar parecer convincente.

Não estou “tentando parecer convincente”. Por favor, mantenha a conversa no nível técnico, e não em ofensas pessoais. Dizer que alguém está tentando “parecer convincente” é um julgamento de valor que não cabe aqui.

O que estou querendo dizer é que: Sim, código bem feito é mais rápido de codificar.
Porém, tornar-se um programador que escreve código assim é um processo lento.

Não vai ser no primeiro e nem no segundo projeto dele que ele será um programador que escreve código elegante e rápido.
Claro, se você somar o tempo que o cara leva para amadurecer como tempo de projeto, aí será mesmo lento escrever direito. Mas essa curva de aprendizado só precisa ser vencida uma vez e, a partir daí, você tem um programador rápido e eficiente para a vida toda (inclusive futuros projetos).

Além disso, do ponto de vista de curto-prazo, pode parecer que um código bem feito leva mais tempo para ser produzido. Isso porque o tempo poupado pelo código bem feito não está no ato da codificação em si, mas no grande tempo que é desperdiçado corrigindo código mau feito, e lidando com seus bugs. O famoso “não sei se fiz certo, mas fiz funcionar” tem efeitos colaterais, como o Yvga citou, que podem ser muitíssimo graves no longo prazo.

Não adianta produzir em volume código que falha. Acho que o que o Yvga e eu estamos falando é sobre produzir código que funciona.

Agradecido.

Interessante notar como o assunto do tópico mudou de foco…

ViniGodoy:

Não estou “tentando parecer convincente”. Por favor, mantenha a conversa no nível técnico, e não em ofensas pessoais. Dizer que alguém está tentando “parecer convincente” é um julgamento de valor que não cabe aqui.

O que estou querendo dizer é que: Sim, código bem feito é mais rápido de codificar.
Porém, tornar-se um programador que escreve código assim é um processo lento.

Não vai ser no primeiro e nem no segundo projeto dele que ele será um programador que escreve código elegante e rápido.
Claro, se você somar o tempo que o cara leva para amadurecer como tempo de projeto, aí será mesmo lento escrever direito. Mas essa curva de aprendizado só precisa ser vencida uma vez e, a partir daí, você tem um programador rápido e eficiente para a vida toda (inclusive futuros projetos).

Além disso, do ponto de vista de curto-prazo, pode parecer que um código bem feito leva mais tempo para ser produzido. Isso porque o tempo poupado pelo código bem feito não está no ato da codificação em si, mas no grande tempo que é desperdiçado corrigindo código mau feito, e lidando com seus bugs. O famoso “não sei se fiz certo, mas fiz funcionar” tem efeitos colaterais, como o Yvga citou, que podem ser muitíssimo graves no longo prazo.

Não adianta produzir em volume código que falha. Acho que o que o Yvga e eu estamos falando é sobre produzir código que funciona.

E dizer que “está recortando só trechos do que a gente fala de propósito” não é julgamento de valor?

Bom, tudo bem, pelo que entendi, seu argumento é que adquirir experiência reduz velocidade apenas quando envolve conhecimento de programação, mas quando envolve conhecimento sobre o que o sistema deve fazer, seus requisitos, ou necessidades específicas do cliente não há redução de velocidade porque não há nada que aprender, e se tiver o programador tira de letra, afinal ele é O programador, então é só produzir. Será…

Pra mim isso é a definição do programador bitolado, e não do bom programador.

Não, não foi isso que eu falei.

O conhecimento sobre o negócio ambos terão que adquirir. No que outro programador codificará mais rápido, já que ele também não terá esse conhecimento?
Como ele codificará mais rápido sem conhecimento do negócio e implementando de qualquer jeito? Claro que nas fases iniciais há redução de velocidade para o programador que faz bem-feito e, aparentemente ele será mais lento do que aquele colega que já sai fazendo código. Mas estamos falando que esse tempo inicial que um programador que capricha “perde”, se paga. Não só o programador que fez direito não perde tempo corrigindo bugs que ele mesmo gerou, como começa a ter reúso.

De qualquer forma, o programador experiente costuma a adquirir o conhecimento do negócio com método. Ele também aprende mais rápido porque a experiência dá a ele situações similares, pelas quais já passou. Como eu falei, ele é mais atento tanto na hora de entender o problema, quanto na hora de corrigi-lo. A maioria dos programadores que escrevem código bem feito que conheço (se não todos) sentem-se mal de simplesmente contornar um problema sem entende-lo, e não tem preguiça de corrigir o erro real.

Como eu falei, eu não estou falando em simplesmente medir “código produzido” por “linhas de código produzidas”. Nisso, com certeza, quem escreve código mau feito é bem mais veloz. Até porque, o copy&paste é uma excelente ferramenta para produzir “linhas de código”, mas péssima em termos de manutenção.

Um dos grandes riscos do “fazer funcionar” ao meu ver, é justamente essa sensação de velocidade que, aos olhos do cliente (e muitas vezes do chefe) dá a impressão de que o programador “sujo” é realmente rápido. Porém, quando o projeto cresce, esse programador torna-se lento, ineficiente e, nos piores casos, perde totalmente o controle do sistema.

Quem aqui nunca programou num sistema que mais parecia uma colcha de retalhos? E considerou programar num ambiente assim algo produtivo?

Eu perguntei, pois você estava cortando frases minhas e do Yvga pela metade, sem sequer levar em consideração o contexto em que foram faladas.

ViniGodoy:

No que outro programador codificará mais rápido, já que ele também não terá esse conhecimento?

Ele não precisa desse conhecimento. Geralmente a empresa adota uma “arquitetura de referência” para não deixar esse conhecimento na mão dos programadores.

Com o conhecimento embutido na ferramenta, o programador é apenas um detalhe no processo, podendo ser trocado que nem se troca um pedreiro numa obra.

ViniGodoy:

Eu perguntei, pois você estava cortando frases minhas e do Yvga pela metade, sem sequer levar em consideração o contexto em que foram faladas.

Só dizendo, mas se trechos contradizem o que vc falou talvez devesse estruturar melhor seus argumentos antes de postar.

Esse é o pensamento de Taylor e Ford, importado do contexto de fabrica. Mas este modelo foi destruido ha mais de 20 anos com a chegada da Honda e da Toyota nos EUA. Nem em fabricas ele é mais usado, menos ainda em ambiente de desenvolvimento, por mais que muita gente insista.

A grande diferenca é que as montadoras eram poucas comparadas a industria de software e pancada que sentiram foi muito mais forte. Elas tiveram que se adaptar ou morreriam. Muitas de fato morreram, foram compradas, fechadas e etc… Mas o efeito Toyota foi pesado no formato tradicional ocidental de desenvolvimento. E eles, na marra, tiveram que se adaptar.

Isso tambem, cedo ou tarde, vai acontecer na industria de software, só vai demorar mais porque o mercado de desenvolvimento não esta concentrado na mao de poucos como sempre foi o mercado de automoveis.

Eu to perdido dessa discussão, alguém me ajuda por gentileza…?

Tive impressão de ter visto pessoas argumentando que adquirir experiência e fazer código bem-feito são Coisas Ruins, mas não to acreditando, tenho certeza que entendi errado.

gomesrod:

Eu to perdido dessa discussão, alguém me ajuda por gentileza…?

Tive impressão de ter visto pessoas argumentando que adquirir experiência e fazer código bem-feito são Coisas Ruins, mas não to acreditando, tenho certeza que entendi errado.

liga não, deve ter caido água no Duran e ele começo a se multiplicar …

YvGa:

Esse é o pensamento de Taylor e Ford, importado do contexto de fabrica. Mas este modelo foi destruido ha mais de 20 anos com a chegada da Honda e da Toyota nos EUA. Nem em fabricas ele é mais usado, menos ainda em ambiente de desenvolvimento, por mais que muita gente insista.

A grande diferenca é que as montadoras eram poucas comparadas a industria de software e pancada que sentiram foi muito mais forte. Elas tiveram que se adaptar ou morreriam. Muitas de fato morreram, foram compradas, fechadas e etc… Mas o efeito Toyota foi pesado no formato tradicional ocidental de desenvolvimento. E eles, na marra, tiveram que se adaptar.

Isso tambem, cedo ou tarde, vai acontecer na industria de software, só vai demorar mais porque o mercado de desenvolvimento não esta concentrado na mao de poucos como sempre foi o mercado de automoveis.

Se você acha que consegue ser mais eficiente e produtivo porque vc insiste em procurar emprego nessas empresas e seu projeto pessoal não é um sucesso?

Quem acha que código bem feito é diferencial que vá criar sua empresa baseada nessa filosofia, querer mudar o status quo é uma briga perdida.

gomesrod:

Eu to perdido dessa discussão, alguém me ajuda por gentileza…?

Tive impressão de ter visto pessoas argumentando que adquirir experiência e fazer código bem-feito são Coisas Ruins, mas não to acreditando, tenho certeza que entendi errado.

Resuminho para os confusos de plantão: Programador caro e código bem feito não são garantia de qualidade.

Eu achava que código bem feito era só o que importava tb, e as pessoas de comando das empresas que eram estúpidas.

Mas pensando bem, colocar o futuro do projeto na mão de programadores é um risco muito grande, e na posição deles eu faria o mesmo.

Botocudo:

Quem acha que código bem feito é diferencial que vá criar sua empresa baseada nessa filosofia, querer mudar o status quo é uma briga perdida.

Porém, já tem muita gente criando empresa por causa disso e o status quo já está sendo largamente mudado em vários locais. Quando as coisas começarem a dar certo (e já estão dando), todo mundo vai querer saber porque e procurar imitar…

Claro que isso ainda vai demorar um tempo, mas há de acontecer. Estava conversando com uma amiga bem antes de responder esse tópico… Estou atrás de montar, ou achar alguém que montou e que aceite um outro maluco pra trabalhar junto em uma empresa assim, porque eu já enchi o saco do Sistema… Como diz o Big Nascimento, O SISTEMA É F0D4…

Enfim.

Abs []

adriano_si:

Botocudo:

Quem acha que código bem feito é diferencial que vá criar sua empresa baseada nessa filosofia, querer mudar o status quo é uma briga perdida.

Concordo nesse ponto com você cara, de verdade. É bem difícil mudar culturas ainda mais quando pegamos pessoas que não entendem as vantagens… Acabou. É que nem aqui, é briga perdida, porque o cara não vai entender o que estás falando e vai te olhar como um verdadeiro E.T. e te rebater até a morte pra dizer que tu estás errado sendo que o cara nem tentou praticar aquilo que estás tentando mostrar pra ele, vai se conformar com o Sistema e pronto…

Porém, já tem muita gente criando empresa por causa disso e o status quo já está sendo largamente mudado em vários locais. Quando as coisas começarem a dar certo (e já estão dando), todo mundo vai querer saber porque e procurar imitar…

Claro que isso ainda vai demorar um tempo, mas há de acontecer. Estava conversando com uma amiga bem antes de responder esse tópico… Estou atrás de montar, ou achar alguém que montou e que aceite um outro maluco pra trabalhar junto em uma empresa assim, porque eu já enchi o saco do Sistema… Como diz o Big Nascimento, O SISTEMA É F0D4…

Enfim.

Abs []

Eu acho que todo mundo quer um código bem escrito.
É sempre bom ter conhecimento sobre padrões de projetos, mas soluções novas sempre aparecem por ai.
Eu sou maluco e tenho interesse em trabalhar com outros malucos.
[]'s

adriano_si:

Concordo nesse ponto com você cara, de verdade. É bem difícil mudar culturas ainda mais quando pegamos pessoas que não entendem as vantagens… Acabou. É que nem aqui, é briga perdida, porque o cara não vai entender o que estás falando e vai te olhar como um verdadeiro E.T. e te rebater até a morte pra dizer que tu estás errado sendo que o cara nem tentou praticar aquilo que estás tentando mostrar pra ele, vai se conformar com o Sistema e pronto…

Porém, já tem muita gente criando empresa por causa disso e o status quo já está sendo largamente mudado em vários locais. Quando as coisas começarem a dar certo (e já estão dando), todo mundo vai querer saber porque e procurar imitar…

Claro que isso ainda vai demorar um tempo, mas há de acontecer. Estava conversando com uma amiga bem antes de responder esse tópico… Estou atrás de montar, ou achar alguém que montou e que aceite um outro maluco pra trabalhar junto em uma empresa assim, porque eu já enchi o saco do Sistema… Como diz o Big Nascimento, O SISTEMA É F0D4…

Enfim.

Abs []

Sim. Esta mudando (software esta cada vez mais acessível ao consumidor por meio de dispositivos móveis por exemplo), mas lentamente.

Mas sem dúvida, se vc achar o mercado certo ele vai compensar e o consumidor vai agradecer.

Botocudo:

gomesrod:

Eu to perdido dessa discussão, alguém me ajuda por gentileza…?

Tive impressão de ter visto pessoas argumentando que adquirir experiência e fazer código bem-feito são Coisas Ruins, mas não to acreditando, tenho certeza que entendi errado.

Resuminho para os confusos de plantão: Programador caro e código bem feito não são garantia de qualidade.
Eu achava que código bem feito era só o que importava tb, e as pessoas de comando das empresas que eram estúpidas.
Mas pensando bem, colocar o futuro do projeto na mão de programadores é um risco muito grande, e na posição deles eu faria o mesmo.

Na verdade você está misturando duas coisas diferentes: Uma é código bem feito. Outra é código “vaidoso”, cheio de classes e patterns desnecessários.

O programador que gosta de código bem-feito é sim um passo na direção do software de qualidade (não exatamente uma GARANTIA, mas é um dos fatores). Ele faz código limpo, rápido de desenvolver e fazer manutenção, testado rigorosamente; além disso esse programador estudou muito bem os requisitos do cliente e os atenderá da melhor maneira.

Aí tem o programador porco. Alguns por preguiça, outros simplesmente porque tem orgulho de ser assim. Sabe aquele cara que acha que “código pronto” e “código funcionando” são duas coisas diferentes? Então, é ele… geralmente atinge a etapa do “código pronto” rapidamente, e por isso bate no peito para dizer que sua maneira é melhor porque é mais rápida.

E também esse cara - que acho que é o que te incomoda - o programador vaidoso, que cria um monstro que eventualmente o acaba engolindo

Enfim, nossa fauna tem vários outros tipos também, tem aquele carinha que sabe tudo de marketing pessoal, tem os juniors que por estarem aprendendo podem acabar indo para qualquer um dos lados, etc etc mas enfim! esse não é o foco

Pense com carinho no que significa ser um programador BOM para você (estou falando de SER bom, não de FALAR que é bom, nem de SE ACHAR o bom, nem de COBRAR CARO, nada disso… estou falando de fazer software com qualidade), e no final acabará concordando com o restante do pessoal.

gomesrod:

Realmente me esclareceu

Na verdade você está misturando duas coisas diferentes: Uma é código bem feito. Outra é código “vaidoso”, cheio de classes e patterns desnecessários.

O programador que gosta de código bem-feito é sim um passo na direção do software de qualidade (não exatamente uma GARANTIA, mas é um dos fatores). Ele faz código limpo, rápido de desenvolver e fazer manutenção, testado rigorosamente; além disso esse programador estudou muito bem os requisitos do cliente e os atenderá da melhor maneira.

Aí tem o programador porco. Alguns por preguiça, outros simplesmente porque tem orgulho de ser assim. Sabe aquele cara que acha que “código pronto” e “código funcionando” são duas coisas diferentes? Então, é ele… geralmente atinge a etapa do “código pronto” rapidamente, e por isso bate no peito para dizer que sua maneira é melhor porque é mais rápida.

E também esse cara - que acho que é o que te incomoda - o programador vaidoso, que cria um monstro que eventualmente o acaba engolindo

Enfim, nossa fauna tem vários outros tipos também, tem aquele carinha que sabe tudo de marketing pessoal, tem os juniors que por estarem aprendendo podem acabar indo para qualquer um dos lados, etc etc mas enfim! esse não é o foco

Pense com carinho no que significa ser um programador BOM para você (estou falando de SER bom, não de FALAR que é bom, nem de SE ACHAR o bom, nem de COBRAR CARO, nada disso… estou falando de fazer software com qualidade), e no final acabará concordando com o restante do pessoal.

hehe… estou me divertindo aqui com os diferentes perfis.

Mas pra ser sincero não entendi qual o propósito disso, ou qual relação com o que está sendo discutido.

Botocudo:

Mas pra ser sincero não entendi qual o propósito disso, ou qual relação com o que está sendo discutido.

Bom, fugiu um pouco do assunto principal do tópico, mas está relacionado.

O tema central é: o programador é um cara que apenas executa um projeto pronto (similar ao operário da obra), ou é alguém que participa da elaboração do projeto ?

E aí a discussão foi para outros caminhos… sobre qual a postura que um programador deve ter (aprender, evoluir, se aperfeiçoar ou apenas executar), sobre a diferença entre um programador bem preparado e um fraco, sobre se um programador “true” deve usar ferramentas de terceiros, etc etc…

Como estamos falando da filosofia das empresas de software, vou falar sobre uma filosofia que vocês devem reconhecer.
Há empresas que entregam software considerado bom o suficiente (good enough) para ser vendido, mas com qualidade duvidosa e grande quantidade de bugs. Como essas empresas têm marketing eficiente e grande número de usuários, conseguem emplacar esses produtos.
Vocês devem conseguir lembrar alguma empresa assim.
Há uma discussão nos meios de engenharia de software sobre essa filosofia. Cito um link:

http://www.se.rit.edu/~se361/Slides/se361_Chapter_14.pdf

Coloco abaixo a tradução:

slides de Roger Pressman (traduzido por mim):

Então as pessoas na indústria tentar chegar a esse mágico meio termo onde o produto é bom o suficiente para não ser rejeitado imediatamente, como durante o processo de avaliação, mas também não é objeto de tanto perfeccionismo e tanto trabalho para demorar muito tempo ou ter custos demasiado elevados. [Ven03]

Software “Good enough” oferece funcionalidade de alta qualidade e características que os usuários finais desejam, mas, ao mesmo tempo, fornece outras funcionalidades mais obscuras ou especializadas que contêm erros conhecidos.

Argumentos contra o “good enough”:

• É verdade que “good enough” pode funcionar em alguns domínios e aplicações para um pequeno número de grandes empresas de software. Afinal, se uma empresa tem um grande orçamento de marketing e pode convencer pessoas suficientes para comprar a versão 1.0 , ela conseguiu consolidar o produto. Se você trabalhar para uma empresa pequena desconfie dessa filosofia. Se você fornecer um produto “good enough” cheio de buggies, você corre o risco de danos permanentes à reputação da sua empresa.

Você pode nunca ter uma chance de entregar a versão 2.0 porque maus comentários podem fazer suas vendas decaírem e quebrar a sua empresa.

Se você trabalhar em certos domínios (por ex., software embarcado de tempo real, software de aplicação integrado ao hardware) pode ser acusado de negligência e sua empresa ser processada.

Parabéns, vocês conseguiram ficar 10 páginas discutindo com um troll! (Botocudo)

O cara tá aqui só pra causar polêmica: o fórum é sobre Java e ele se registra só pra falar mal de Java. O fórum é frequentado por programadores e ele posta só pra menosprezar o trabalho de um programador. O pessoal defende desenvolvimento ágil aqui e ele fica falando de modelo de fábrica de software

Quem disse que eu insisto? A empresa em que eu trabalho divide boa parte dessas ideias comigo e estamos melhorando a cada dia. Longe da perfeição ainda, mas melhoramos a cada dia. E eu sai de uma empresa onde desisti da briga pra ganhar um pouco menos aqui, so por causa disso. E valeu a pena.

É uma briga perdida se voce ficar so na garganta, só falando, falando e não fazendo nada. Mas mostrando resultado as pessoas começam a te ouvir, pode ter certeza.

Quanto a criar a minha empresa, eu ainda chego la, mas ainda não é a hora.

victorcosta:

Parabéns, vocês conseguiram ficar 10 páginas discutindo com um troll! (Botocudo)

O cara tá aqui só pra causar polêmica: o fórum é sobre Java e ele se registra só pra falar mal de Java. O fórum é frequentado por programadores e ele posta só pra menosprezar o trabalho de um programador. O pessoal defende desenvolvimento ágil aqui e ele fica falando de modelo de fábrica de software

Por isso penso que ele expôs a opinião dele aqui. Há alguns tópicos do Botocudo que eu não respondo mesmo, mas esse aqui eu achei que ele colocou sua opinião sincera e nada custa colocar a minha também…

Mas entendo você, tenho esse mesmo pensamento algumas vezes também, não para determinados usuários específicos, mas sim para certos tipos de mensagem…

Quanto ao fórum, lembre que há muitos programadores de outras linguagens aqui e que Agil ainda não é maioria no nosso meio cara. Eu mesmo sou um entusiasta Agil, porque o que faço hoje definitivamente está errado, mas ainda não o usei a nível corporativo e sim só a nível pessoal.

Abs []

Porque somos obrigados a ganhar menos se somos tão importante para as empresas?

YvGa:

É uma briga perdida se voce ficar so na garganta, só falando, falando e não fazendo nada. Mas mostrando resultado as pessoas começam a te ouvir, pode ter certeza.

Pode ser. Mas acho que se software fosse tão importante para essas empresas o programador não precisaria ficar fazendo, fazendo pra ganhar menos.

victorcosta:

Parabéns, vocês conseguiram ficar 10 páginas discutindo com um troll! (Botocudo)

O cara tá aqui só pra causar polêmica: o fórum é sobre Java e ele se registra só pra falar mal de Java. O fórum é frequentado por programadores e ele posta só pra menosprezar o trabalho de um programador. O pessoal defende desenvolvimento ágil aqui e ele fica falando de modelo de fábrica de software

Alguns usuários são mesmo uma piada.

Crucifiquem-no, Crucifiquem-no…

Botocudo:

YvGa:

Quem disse que eu insisto? A empresa em que eu trabalho divide boa parte dessas ideias comigo e estamos melhorando a cada dia. Longe da perfeição ainda, mas melhoramos a cada dia. E eu sai de uma empresa onde desisti da briga pra ganhar um pouco menos aqui, so por causa disso. E valeu a pena.

Porque somos obrigados a ganhar menos se somos tão importante para as empresas?

Botocudo:

Ganhar menos nao significa ganhar como junior. Ganhar menos, mas com melhores condicoes vale mais a pena, e hoje ja ganho mais do que estaria se estivesse na empresa que trata programador como “recurso” e que acha que salario é suficiente pra manter o cara pagando pau pra idiota engravatado.

Nao é! Lamento por quem tenha que se sacrificar por isso.

YvGa:

Porque ninguem te paga so pela conversa.

Mas paga pra ser recurso. Se isso acontece é porque pra elas um programador medíocre é suficiente.

Botocudo:

Ganhar menos nao significa ganhar como junior. Ganhar menos, mas com melhores condicoes vale mais a pena, e hoje ja ganho mais do que estaria se estivesse na empresa que trata programador como “recurso” e que acha que salario é suficiente pra manter o cara pagando pau pra idiota engravatado.

Nao é! Lamento por quem tenha que se sacrificar por isso.

Que bom você não ve isso como um sacrifício, mas pra mim, se quero ser bom e encontro uma empresa sem perspectiva de crescimento e depois quando mudo a outra não valoriza minha experiência anterior (e ainda corre-se o risco de encontrar uma que seja apenas igual a primeira), enfim…

Vamos combinar que tb não é o melhor dos cenários para o profissional aspirante.

Primeiro voce faz, depois voce cobra. E a empresa nao tem que valorizar a minha experiencia, ela tem que valorizar o ganho de fato que eu dou a ela.

O simples fato do cara numa entrevista pedir cem mil reais de salario, nao faz com que automaticamente ele valha cem mil. Se o cara diz: “pagar mais do que X nao vale o risco para a minha empresa”, eu digo sim ou nao. Lembre-se de que se voce corre o risco ao mudar de empresa, a empresa tambem corre risco ao te contratar.

E realmente este nao é o melhor dos cenarios, o melhor cenario seria as empresas disputando o meu curriculo a tapa fazendo leilao e mudando todas as suas estruturas de departamento para me ter trabalhando pra elas. Mas não eh o meu caso.

digaoneves:

E essa comparação é desmerecedora para você?

Se for pensar de maneira bem preto e branco, eu diria que sim.
O programador é o peão, o analista é o engenheiro e o arquiteto é, bem, o arquiteto.

Mas na minha sincera opinião, na área de desenvolvimento de software essas “linhas” são mais turvas, acontece de em determinados casos, uma determinada pessoa exercer mais de uma função. Talvez um pouco de todas (dependendo da aplicação).

Eu nunca achei muito certo comparar desenvolvimento de software com construção civil, pois apesar de existirem similaridades, as funções são bem diferentes na prática. (Pelo menos é o que eu penso, pois nunca trabalhei com construção civil).

Mas se for pensar no “peão” como o cara que faz, onde a consistência de uma parede, depende do bom trabalho dele, não vejo isso como uma comparação desmerecedora.

E quando às linhas turvas entre funções, uma boa leitura é a teoria dos DevOps

Vejo vários Analistas Programadores se titulando de Engenheiros de Software… Vocês concordam com essa denominação?

Eu entendo que Engenharia de Software é a aplicação de princípios da engenharia ao desenvolvimento de software. É a utilização de uma abordagem sistemática, disciplinada e quantificável ao desenvolvimento de software. Envolve a utilização de processos adequados (métodos ágeis, RUP, etc.) e a adaptação destes processos à equipe e ao projeto. Envolve executar as atividades necessárias (estimativas, requisitos, análise, projeto, programação, testes, etc.). Envolve a utilização de ferramentas, como por exemplo ferramentas de testes automáticos. Envolve controle de qualidade, gerenciamento de projetos, etc. Acho que hoje em dia um Analista Programador se preocupa com estes tipos de coisa, então acho que ele pode ser chamado de Engenheiro de Software.

O que eu acho é que hoje em dia os papéis não estão claramente definidos no desenvolvimento. Quando imperava o processo em cascata o analista de sistemas fazia a análise e passava para o programador, que muitas vezes programava sem interferir na análise e no projeto. Como disse o digaoneves, hoje em dia “as linhas são mais turvas”. Então não fica muito bem definido até onde vai o trabalho do analista e onde começa o trabalho do programador.