Como NÃO liderar geeks
“Tradução para português do artigo 'How NOT to lead geeks', que lista os maiores erros que gerentes cometem ao liderar geeks em sua equipe.” A nota foi enviada por Cesar Cardoso (cesarΘzyakannazio·eti·br), que acrescentou este link da fonte para maiores detalhes.(postado por Augusto Campos)
Comentários dos leitores
Comentário de nemesis
21/06/06 7:58 - usuário registrado #1514
precisamente!!: essa deveria ser a razão número 1:
"10- Esquecer que geeks são trabalhadores criativos
Programação é um processo criativo, não industrial. Geeks devem constantemente trazer soluções para novos problemas e raramente resolver o mesmo problema duas vezes; entao é necessário liberdade e flexibilidade. Códigos rígidos de vestimenta e muitas normas matam toda a inovação."
Não poderia concordar mais. Começar um novo projeto já todo amarrado com padrões abstratos pensados antes de qualquer implementação e usando linguagens estaticamente tipadas só traz uma conseqüência: atrasos e mais atrasos no cronograma. É preciso liberdade para se experimentar o que vai funcionar e o que não vai e é preciso rapidez e flexibilidade para adaptar o código à novas exigências.
No passado, havia a figura da fase de prototipação, com uma linguagem "mais leve", para se poder rapidamente experimentar uma solução. Hoje em dia isso virou criação de "telas vazias" apenas para mostrar a parte visual de um programa para o usuário. Pior, já se começa programando na própria linguagem de implementação, geralmente de baixo nível para se conseguir "performance". Dessa forma, fica muito difícil a experimentação.
Mas enfim, é isso mesmo: melhor padrões rígidos, muito copiar e colar de esqueletos de código e diversos hacks para fazê-lo funcionar em projetos diferentes do que ter os programadores dummy que enchem a indústria de hoje fazendo merda... :P
por outro lado, acho que geeks são uma minoria na TI de hoje.
;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")
"10- Esquecer que geeks são trabalhadores criativos
Programação é um processo criativo, não industrial. Geeks devem constantemente trazer soluções para novos problemas e raramente resolver o mesmo problema duas vezes; entao é necessário liberdade e flexibilidade. Códigos rígidos de vestimenta e muitas normas matam toda a inovação."
Não poderia concordar mais. Começar um novo projeto já todo amarrado com padrões abstratos pensados antes de qualquer implementação e usando linguagens estaticamente tipadas só traz uma conseqüência: atrasos e mais atrasos no cronograma. É preciso liberdade para se experimentar o que vai funcionar e o que não vai e é preciso rapidez e flexibilidade para adaptar o código à novas exigências.
No passado, havia a figura da fase de prototipação, com uma linguagem "mais leve", para se poder rapidamente experimentar uma solução. Hoje em dia isso virou criação de "telas vazias" apenas para mostrar a parte visual de um programa para o usuário. Pior, já se começa programando na própria linguagem de implementação, geralmente de baixo nível para se conseguir "performance". Dessa forma, fica muito difícil a experimentação.
Mas enfim, é isso mesmo: melhor padrões rígidos, muito copiar e colar de esqueletos de código e diversos hacks para fazê-lo funcionar em projetos diferentes do que ter os programadores dummy que enchem a indústria de hoje fazendo merda... :P
por outro lado, acho que geeks são uma minoria na TI de hoje.
;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")
Comentário de Kyz
21/06/06 8:11
My god: "e usando linguagens estaticamente tipadas só traz uma conseqüência: atrasos e mais atrasos no cronograma."
Baboseira !!!!
Aprenda o que falar antes de falar.
Baboseira !!!!
Aprenda o que falar antes de falar.
Comentário de nemesis
21/06/06 9:19 - usuário registrado #1514
huh: aprendi por experiência própria. e vc?
;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")
;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")
Comentário de cesarse
21/06/06 9:22 - usuário registrado #5512
Aprenda a argumentar quando: Aprenda a argumentar quando criticar.
Comentário de timm
21/06/06 10:25 - usuário registrado #6071
Caramba...: Nunca me identifiquei tanto com um texto assim. Na verdade eu "sofro" muito dos erros criticados na reportagem, e também, estou procurando outro emprego pois onde eu trabalho atualmente, vou chutar o balde logo logo!
Vou anexar isso aos meus currícula...
(hehe)
Vou anexar isso aos meus currícula...
(hehe)
Comentário de augusto_
21/06/06 11:33 - usuário registrado #7694
huhu: Aqui também, o meu patrão quebra praticamente umas 7 regras dae, to pra pegar o caminho de outra empresa...
Trabalhar com gráficos/programação/administração remota num Duron 1.1 com 119ddr realmente é um saco, =)
Muito bom o texto
"Arapuka AntiVirus, o Primeiro AV Brasileiro OpenSource"
Trabalhar com gráficos/programação/administração remota num Duron 1.1 com 119ddr realmente é um saco, =)
Muito bom o texto
"Arapuka AntiVirus, o Primeiro AV Brasileiro OpenSource"
Comentário de Bruno Laturner
21/06/06 12:33 - usuário registrado #4102
Talvez essa seja a sua: Talvez essa seja a sua realidade, mas eu não concordo que esse seja um problema de criatividade.
Começar um novo projeto já todo amarrado com padrões abstratos pensados antes de qualquer implementação e usando linguagens estaticamente tipadas só traz uma conseqüência: atrasos e mais atrasos no cronograma.
Vou com aqueles comentários do tipo "é mais fácil falar que fazer": Parece que essa equipe não está preparada para seguir o padrão de projeto passado pelo engenheiro/analista, ou o padrão dele é que não condiz com a realidade de quem vai trabalhar no projeto.
Colocar a culpa em "linguagens estaticamente tipadas", fica parecendo que existe uma predileção por fazer gambiarras no código, pra no final ficar um "É um ninho de cobra, mas tá funcionando."
Sinceramente a razão número 1 deveria ficar como a número 1, sem treinamento do pessoal pra poderem formular e seguir esses projetos, esse trem que já está descontrolado, vai descarrilhar.
----------------
AjudaLinux.org
Começar um novo projeto já todo amarrado com padrões abstratos pensados antes de qualquer implementação e usando linguagens estaticamente tipadas só traz uma conseqüência: atrasos e mais atrasos no cronograma.
Vou com aqueles comentários do tipo "é mais fácil falar que fazer": Parece que essa equipe não está preparada para seguir o padrão de projeto passado pelo engenheiro/analista, ou o padrão dele é que não condiz com a realidade de quem vai trabalhar no projeto.
Colocar a culpa em "linguagens estaticamente tipadas", fica parecendo que existe uma predileção por fazer gambiarras no código, pra no final ficar um "É um ninho de cobra, mas tá funcionando."
Sinceramente a razão número 1 deveria ficar como a número 1, sem treinamento do pessoal pra poderem formular e seguir esses projetos, esse trem que já está descontrolado, vai descarrilhar.
----------------
AjudaLinux.org
Comentário de nemesis
21/06/06 12:50 - usuário registrado #1514
não: "Colocar a culpa em 'linguagens estaticamente tipadas', fica parecendo que existe uma predileção por fazer gambiarras no código"
Não, é uma predileção por flexibilidade e rapidez na criação de protótipos.
Em minha opinião, protótipos sem qualquer lógica de negócio, apenas com telas vazias, não vale de nada, exceto para enganar usuários. Protótipos devem ajudar os desenvolvedores a experimentar rapidamente uma solução e para isso, é inútil codificá-las em C++ ou Java: vc está gastando tempo declarando um monte de porcarias que muito provavelmente vão mudar ao longo do desenvolvimento.
Ao invés, usando uma linguagem própria para rápida prototipação, como python e similares, vc ganha rapidez e flexibilidade para fazer alterações. Dessa forma, vc pode rapidamente experimentar com diversos aproaches para a solução do problema.
Se depois vc quiser perder tempo traduzindo a solução prototipada e funcional para C++, Delphi e similares, blz. A lógica já está pronta e funcionando, agora é só atuar como um compilador humano... :)
Se vc percebesse o quanto se gasta tempo escrevendo código cujo único propósito é fazer um compilador feliz, ao invés de focar no negócio...
;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")
Não, é uma predileção por flexibilidade e rapidez na criação de protótipos.
Em minha opinião, protótipos sem qualquer lógica de negócio, apenas com telas vazias, não vale de nada, exceto para enganar usuários. Protótipos devem ajudar os desenvolvedores a experimentar rapidamente uma solução e para isso, é inútil codificá-las em C++ ou Java: vc está gastando tempo declarando um monte de porcarias que muito provavelmente vão mudar ao longo do desenvolvimento.
Ao invés, usando uma linguagem própria para rápida prototipação, como python e similares, vc ganha rapidez e flexibilidade para fazer alterações. Dessa forma, vc pode rapidamente experimentar com diversos aproaches para a solução do problema.
Se depois vc quiser perder tempo traduzindo a solução prototipada e funcional para C++, Delphi e similares, blz. A lógica já está pronta e funcionando, agora é só atuar como um compilador humano... :)
Se vc percebesse o quanto se gasta tempo escrevendo código cujo único propósito é fazer um compilador feliz, ao invés de focar no negócio...
;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")
Comentário de Ataliba
21/06/06 15:17
Hummm: Sinceridade ? O dia que existir uma empresa que respeita funcionário, é porque nao é empresa.
É sonho.
É sonho.
Comentário de Ark
21/06/06 16:47
Hã?: O que Linguagens estaticamente tipadas tem a ver com isso? Sei que você se refere diretamente a Java (que você critica), mas o que isso tem a ver com falta de criatividade? Eu programo em ambos os ambientes, e embora seja mais difícil programar em linguagens tipadas estaticamente, me consideraria burro se dissesse que elas capam minha criatividade. E interfaces (e outras similaridades usadas pra prototipação) existem em várias outra linguagens.
Comentário de Capo de tutti geeki
21/06/06 17:38
Uma verdade e um mito: Geeks odeiam gerentês e vêem como superficial e desonesto.
Verdade. "Quem não sabe dissimular, não sabe governar", dizem.
Programação é um processo criativo, não industrial.
Mito. Mas tudo bem. O bom gerente é aquele que consegue fazer o geek produzir industrialmente, fazendo-o pensar que está sendo criativo, de qualquer forma.
Verdade. "Quem não sabe dissimular, não sabe governar", dizem.
Programação é um processo criativo, não industrial.
Mito. Mas tudo bem. O bom gerente é aquele que consegue fazer o geek produzir industrialmente, fazendo-o pensar que está sendo criativo, de qualquer forma.
Comentário de Damarinho
21/06/06 18:09 - usuário registrado #5860
Gerenciamento e Tecnologia: (*_*)
1 - Gerenciar tecnologia não é apropriado para um gerente de recursos humanos. Há incompatibilidade de conhecimento, produtividde, criatividade, inovação e conflitos e critérios programáticos.
Assim, analistas e programadores e seus auxiliares seriam agrupados em um departamento diferenciado, exclusivista, independente. Direção e Gerenciamento seriam feitos pelo grupo homogeneizado e não por ditames
de cargos de gerente anômalo a diretrizes básica de criatividade. Isto é, escolher um gerente anacrônico para um grupo de geeks, genios, autistas, não segue uma linha de raciocínio e decisão com base em negócios.
2 - Na empresa em que fui analista e programador, somente consegui imprimir conceitos e implementação de processos, controveresos para o gerente, mas revolucinários quanto a criatividade - só pude executar
um produto final ultrapassando a hierarquia da empresa e decidindo, sob risco, e assumindo decições gerenciais próprias, sem consulta. Isto é, tive que ser um rebelde.
3 - Imagem agora, escoher um gerente para os seguintes personagens: Santos Dumont, Thomas Edison, Eistein, etc.
Não haveria consenso gerencial. A primeira voz seria rugir: é um louco e visionário.
4 - Prototipação. Ideografia é uma ramo da filosofia e da Tecnologia, que, após um "brain storm", produz e demonstra por imagens (ideogramas) a via e trilha de implementação de um produto qualquer, utilizando recursos tais como fluxogramas, agora muito mais eficientes com a linguagem java.
5 - Gerente de conteúdo. Jornalismo e Fóruns de discussão, como este, podem tambem ser uma amostra grátis da incompatibilidade gerencial de conteúdo, na expressão livre do pensamento de qualquer que parcitipe de uma discussão, aduzindo comentários, - e que são filtrados e afunilados por MODERAR CONTEÚDO. Alguns moderados decidem que uma opinião poderá resultar em beligerância (fleugmas e polêmicas). Não é simplesmente MODERAR (gerenciando o conteúdo) que se evitam fleugmas,
conquanto o tema fica disponível em LINKS.
Nessa nova fase de MODERAÇÂO, neste Fórum, alguns assuntos são julgados como beligerantes por Gerentes de Conteúdo de plantão que não sabem discernir nem assimilar a essência de alguns simples argumentos ou a inclusão de raciocínios inovadores.
(*_*) //damarinho ::
# Organização e Método executivo-operacional em Linux
==> http://geocities.yahoo.com.br/omlinux
De Ashtar Sheran: http://www.caminhosdeluz.org/10.htm
1 - Gerenciar tecnologia não é apropriado para um gerente de recursos humanos. Há incompatibilidade de conhecimento, produtividde, criatividade, inovação e conflitos e critérios programáticos.
Assim, analistas e programadores e seus auxiliares seriam agrupados em um departamento diferenciado, exclusivista, independente. Direção e Gerenciamento seriam feitos pelo grupo homogeneizado e não por ditames
de cargos de gerente anômalo a diretrizes básica de criatividade. Isto é, escolher um gerente anacrônico para um grupo de geeks, genios, autistas, não segue uma linha de raciocínio e decisão com base em negócios.
2 - Na empresa em que fui analista e programador, somente consegui imprimir conceitos e implementação de processos, controveresos para o gerente, mas revolucinários quanto a criatividade - só pude executar
um produto final ultrapassando a hierarquia da empresa e decidindo, sob risco, e assumindo decições gerenciais próprias, sem consulta. Isto é, tive que ser um rebelde.
3 - Imagem agora, escoher um gerente para os seguintes personagens: Santos Dumont, Thomas Edison, Eistein, etc.
Não haveria consenso gerencial. A primeira voz seria rugir: é um louco e visionário.
4 - Prototipação. Ideografia é uma ramo da filosofia e da Tecnologia, que, após um "brain storm", produz e demonstra por imagens (ideogramas) a via e trilha de implementação de um produto qualquer, utilizando recursos tais como fluxogramas, agora muito mais eficientes com a linguagem java.
5 - Gerente de conteúdo. Jornalismo e Fóruns de discussão, como este, podem tambem ser uma amostra grátis da incompatibilidade gerencial de conteúdo, na expressão livre do pensamento de qualquer que parcitipe de uma discussão, aduzindo comentários, - e que são filtrados e afunilados por MODERAR CONTEÚDO. Alguns moderados decidem que uma opinião poderá resultar em beligerância (fleugmas e polêmicas). Não é simplesmente MODERAR (gerenciando o conteúdo) que se evitam fleugmas,
conquanto o tema fica disponível em LINKS.
Nessa nova fase de MODERAÇÂO, neste Fórum, alguns assuntos são julgados como beligerantes por Gerentes de Conteúdo de plantão que não sabem discernir nem assimilar a essência de alguns simples argumentos ou a inclusão de raciocínios inovadores.
(*_*) //damarinho ::
# Organização e Método executivo-operacional em Linux
==> http://geocities.yahoo.com.br/omlinux
De Ashtar Sheran: http://www.caminhosdeluz.org/10.htm
Comentário de Damarinho
21/06/06 18:21 - usuário registrado #5860
(*_*): (*_*)
""
Colocar a culpa em "linguagens estaticamente tipadas", fica parecendo que existe uma predileção por fazer gambiarras no código, pra no final ficar um "É um ninho de cobra, mas tá funcionando."
""
- Por características singulares e intelectuais em analistas e programadores indianos - a Miscrosoft convidou um grupo deles para refazer o código do Windows 2000. Após uma breve análise do grupo, ficou decidido que as milhares de linhas de código eram semelhantes a um "balaio de gatos" e recusaram a proposta daquela empresa. Seria melhor começar o zero.
(*_*) //damarinho ::
# Organização e Método executivo-operacional em Linux
==> http://geocities.yahoo.com.br/omlinux
De Ashtar Sheran: http://www.caminhosdeluz.org/10.htm
""
Colocar a culpa em "linguagens estaticamente tipadas", fica parecendo que existe uma predileção por fazer gambiarras no código, pra no final ficar um "É um ninho de cobra, mas tá funcionando."
""
- Por características singulares e intelectuais em analistas e programadores indianos - a Miscrosoft convidou um grupo deles para refazer o código do Windows 2000. Após uma breve análise do grupo, ficou decidido que as milhares de linhas de código eram semelhantes a um "balaio de gatos" e recusaram a proposta daquela empresa. Seria melhor começar o zero.
(*_*) //damarinho ::
# Organização e Método executivo-operacional em Linux
==> http://geocities.yahoo.com.br/omlinux
De Ashtar Sheran: http://www.caminhosdeluz.org/10.htm
Comentário de nemesis
21/06/06 21:41 - usuário registrado #1514
otimizações prematuras: "Começar um novo projeto já todo amarrado com padrões abstratos pensados antes de qualquer implementação e usando linguagens estaticamente tipadas só traz uma conseqüência: atrasos e mais atrasos no cronograma."
ficou mais claro? Não estou dizendo para não implementar com C++ e congêneres ou que tais limitam a criatividade. Estou dizendo que amarrar um novo projeto com padrões e linguagens estaticamente tipadas logo de cara, sem uma fase de experimentação com prototipagem em uma linguagem ágil, é prejudicial.
Vc logo vai perceber que os padrões são bons no papel mas não funcionam tão bem na prática e os requerimentos vão constantemente mudar conforme o entendimento das regras de negócio se tornam mais claras. E para se ter um bom entendimento das regras de negócio, é preciso experimentar. E se vc começou implementando com uma linguagem toda pregada com centenas de declarações, nomes quilométricos e enterprise e outras esquizofrenias, vai ser difícil mudar para se adaptar conforme seu entendimento aumenta.
Prototipação é essencial para o entendimento do problema, experimentação da solução e subsequentes modificações. Não deveria servir apenas para mostrar telas vazias de funcionalidade, mas para efetivamente testar a validade das regras.
Infelizmente, como se passou a usar IDEs com uma só linguagem base, geralmente estática e inflexível, prototipar começou a pesar e prefere-se simplesmente partir diretamente para a implementação na linguagem final. E dá-lhe debug, refactoring e prazos se esvaindo a medida que os requerimentos mudam...
Como já dizia C.A.R. Hoare: "Otimizações prematuras são a raiz de todo o mal."
;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")
ficou mais claro? Não estou dizendo para não implementar com C++ e congêneres ou que tais limitam a criatividade. Estou dizendo que amarrar um novo projeto com padrões e linguagens estaticamente tipadas logo de cara, sem uma fase de experimentação com prototipagem em uma linguagem ágil, é prejudicial.
Vc logo vai perceber que os padrões são bons no papel mas não funcionam tão bem na prática e os requerimentos vão constantemente mudar conforme o entendimento das regras de negócio se tornam mais claras. E para se ter um bom entendimento das regras de negócio, é preciso experimentar. E se vc começou implementando com uma linguagem toda pregada com centenas de declarações, nomes quilométricos e enterprise e outras esquizofrenias, vai ser difícil mudar para se adaptar conforme seu entendimento aumenta.
Prototipação é essencial para o entendimento do problema, experimentação da solução e subsequentes modificações. Não deveria servir apenas para mostrar telas vazias de funcionalidade, mas para efetivamente testar a validade das regras.
Infelizmente, como se passou a usar IDEs com uma só linguagem base, geralmente estática e inflexível, prototipar começou a pesar e prefere-se simplesmente partir diretamente para a implementação na linguagem final. E dá-lhe debug, refactoring e prazos se esvaindo a medida que os requerimentos mudam...
Como já dizia C.A.R. Hoare: "Otimizações prematuras são a raiz de todo o mal."
;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")
Comentário de nemesis
21/06/06 21:42 - usuário registrado #1514
aparentemente: "Seria melhor começar o zero."
e cá estamos hoje, com parte do Vista sendo reimplementado do zero segundo notícia de algum tempo atrás... :)
;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")
e cá estamos hoje, com parte do Vista sendo reimplementado do zero segundo notícia de algum tempo atrás... :)
;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")
Comentário de Fagundes
22/06/06 13:59
O link abaixo prova que o chefe sempre tem razão: http://www2.uol.com.br/cafecombobagem/museuimagem94.shtml
Comentário de cesarse
22/06/06 18:46 - usuário registrado #5512
Hein? Protótipo?: As únicas vezes que fiz protótipos foi durante a faculdade, em disciplinas específicas.
Na vida real infelizmente as coisas são um pouquinho diferentes. Ou você tem que entregar o projeto para ontem e aí faz com o mínimo de planejamento ou, se um "protótipo" é feito, pode apostar que o produto final vai ser criado em cima dele, de maneira caótica.
Gostaria de trabalhar em uma empresa que desse valor para *alguma* metodologia de desenvolvimento de software. :-)
Acredito que em empresas grandes isso já não ocorra (tanto), mas em softhouses pequenas ou médias, que tem que entregar projeto rápido pra ganhar dinheiro rápido...
Além disso, está pra nascer o cliente/usuário que não muda a especificação do que pediu de uma semana pra outra... :-D
Na vida real infelizmente as coisas são um pouquinho diferentes. Ou você tem que entregar o projeto para ontem e aí faz com o mínimo de planejamento ou, se um "protótipo" é feito, pode apostar que o produto final vai ser criado em cima dele, de maneira caótica.
Gostaria de trabalhar em uma empresa que desse valor para *alguma* metodologia de desenvolvimento de software. :-)
Acredito que em empresas grandes isso já não ocorra (tanto), mas em softhouses pequenas ou médias, que tem que entregar projeto rápido pra ganhar dinheiro rápido...
Além disso, está pra nascer o cliente/usuário que não muda a especificação do que pediu de uma semana pra outra... :-D
Comentário de nemesis
22/06/06 20:58 - usuário registrado #1514
exatamente: "Ou você tem que entregar o projeto para ontem e aí faz com o mínimo de planejamento"
aí é problema do usuário, que está exigindo um trabalho porco. Ou do gerente de projeto, que calculou mal os prazos.
"se um 'protótipo' é feito, pode apostar que o produto final vai ser criado em cima dele, de maneira caótica."
exatamente. Mas vc assume que vai ser de maneira caótica pq está pensando em programação de protótipos com uma linguagem estaticamente tipada: vai ser caótico pq a cada alteração nos requerimentos, vai ser difícil modificar toda gama de declarações e todo o código "boilerplate" que vc precisa atravessar antes de chegar aos "finalmentes".
o argumento a favor de linguagens como python é exatamente esse: vc fácil e rapidamente coloca uma solução no ar, com algoritmos para regras de negócios efetivamente funcionando. E, às vezes, o "protótipo" já é tão bom e bem testado, com boa performance, que dispensaria a reescrita do código em uma linguagem estaticamente tipada e mais baixo nível...
;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")
aí é problema do usuário, que está exigindo um trabalho porco. Ou do gerente de projeto, que calculou mal os prazos.
"se um 'protótipo' é feito, pode apostar que o produto final vai ser criado em cima dele, de maneira caótica."
exatamente. Mas vc assume que vai ser de maneira caótica pq está pensando em programação de protótipos com uma linguagem estaticamente tipada: vai ser caótico pq a cada alteração nos requerimentos, vai ser difícil modificar toda gama de declarações e todo o código "boilerplate" que vc precisa atravessar antes de chegar aos "finalmentes".
o argumento a favor de linguagens como python é exatamente esse: vc fácil e rapidamente coloca uma solução no ar, com algoritmos para regras de negócios efetivamente funcionando. E, às vezes, o "protótipo" já é tão bom e bem testado, com boa performance, que dispensaria a reescrita do código em uma linguagem estaticamente tipada e mais baixo nível...
;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")
Comentário de nemesis
22/06/06 20:58 - usuário registrado #1514
exatamente: ;; ((lambda (x) x) (lambda (x) x))
Comentário de escovadordebit
22/06/06 21:17 - usuário registrado #282
Não é exclusivo das pequenas...: Isso não é exclusividade de empresa pequena não. Ja trabalhei em um projeto de um grande fabricante de software com consultoria e tudo.
No final o projeto começa a tornar-se tão caro que as coisas começam a ser feitas sem critério algum.
Para mim a fase de pré-projeto é a mais importante pois você discute o sitema não apenas sob o ponto de vista do presente mas do futuro também.
As vezes algumas decisões precipitadas que são tomadas no início do projeto, acabam engessando o sistema no futuro, ou tornando seu upgrade caótico.
Acho que a busca de certificação é muito interessante no desenvolvimento do software a medida que você pode implementar processos para ter esse desenvolvmento mais organizado. A idéia não é "castrar" a criatividade do desenvolvedor, mas implementar processos formais onde se possa obter qualidade no desenvolvimento.
Linux user #226380
"Linux é amigável... Ele apenas sabe escolher os amigos."
No final o projeto começa a tornar-se tão caro que as coisas começam a ser feitas sem critério algum.
Para mim a fase de pré-projeto é a mais importante pois você discute o sitema não apenas sob o ponto de vista do presente mas do futuro também.
As vezes algumas decisões precipitadas que são tomadas no início do projeto, acabam engessando o sistema no futuro, ou tornando seu upgrade caótico.
Acho que a busca de certificação é muito interessante no desenvolvimento do software a medida que você pode implementar processos para ter esse desenvolvmento mais organizado. A idéia não é "castrar" a criatividade do desenvolvedor, mas implementar processos formais onde se possa obter qualidade no desenvolvimento.
Linux user #226380
"Linux é amigável... Ele apenas sabe escolher os amigos."
Comentário de cesarse
23/06/06 10:42 - usuário registrado #5512
E métodos ágeis?: Para finalizar a discussão, acho que sua defesa a favor dessas linguagens dinâmicas é só se você trabalha sozinho; ou numa equipe, mas isoladamente.
"E, às vezes, o "protótipo" já é tão bom e bem testado, com boa performance..."
A idéia de XP é justament o protótipo que evolui naturalmente para o produto final.
Mas a metodologia não exige que você use java, eclipse e design patterns. Desde que a equipe seja proficiente na linguagem, dá certo até programando em brainfuck usando o emacs. :-D
"E, às vezes, o "protótipo" já é tão bom e bem testado, com boa performance..."
A idéia de XP é justament o protótipo que evolui naturalmente para o produto final.
Mas a metodologia não exige que você use java, eclipse e design patterns. Desde que a equipe seja proficiente na linguagem, dá certo até programando em brainfuck usando o emacs. :-D
Comentário de nemesis
23/06/06 14:11 - usuário registrado #1514
quotes: http://www.python.org/about/quotes/
veja lá o testemunho de gente do Google, NASA e outros... prefiro acreditar no que eles dizem sobre produtividade com python e trabalho em equipe.
Muitos produtos nessas empresas começam prototipados em python/lisp/ruby/etc e depois, se performance for realmente necessária, são recodificados em C++/java.
"A idéia de XP é justament o protótipo que evolui naturalmente para o produto final."
essa deveria ser a regra, exatamente. E linguagens ágeis ajudam, certamente.
"Desde que a equipe seja proficiente na linguagem"
ah, mas uma equipe proficiente em python ainda vai dar banho em uma proficiente em java... ;)
;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")
veja lá o testemunho de gente do Google, NASA e outros... prefiro acreditar no que eles dizem sobre produtividade com python e trabalho em equipe.
Muitos produtos nessas empresas começam prototipados em python/lisp/ruby/etc e depois, se performance for realmente necessária, são recodificados em C++/java.
"A idéia de XP é justament o protótipo que evolui naturalmente para o produto final."
essa deveria ser a regra, exatamente. E linguagens ágeis ajudam, certamente.
"Desde que a equipe seja proficiente na linguagem"
ah, mas uma equipe proficiente em python ainda vai dar banho em uma proficiente em java... ;)
;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")
Leitura recomendada: "O monge e o executivo".
Linux user #226380
"Linux é amigável... Ele apenas sabe escolher os amigos."