Preciso sair de onde estou hoje, pois o cenário que venho vivendo há uns 4 anos é completamente o oposto disso… O que vejo é sempre uma guerrinha entre “TI vs Cliente” onde a culpa sempre é do outro e ninguém está satisfeito.
Estou terminando um Post em meu blog sobre isso e gostaria de atualizar o status, pois até onde eu pensava, era a realidade do mercado
Nessas horas que vejo que estou no lugar errado.
Creio que a discussão está indo em um nível muito bom e cada opinião, achamos novidades…
[quote=adriano_si]
Os clientes estão satisfeitos ???
Preciso sair de onde estou hoje, pois o cenário que venho vivendo há uns 4 anos é completamente o oposto disso… O que vejo é sempre uma guerrinha entre “TI vs Cliente” onde a culpa sempre é do outro e ninguém está satisfeito.
Estou terminando um Post em meu blog sobre isso e gostaria de atualizar o status, pois até onde eu pensava, era a realidade do mercado
Nessas horas que vejo que estou no lugar errado.
Creio que a discussão está indo em um nível muito bom e cada opinião, achamos novidades…
Abs [][/quote]
Oi Adriano,
Sobre a guerrinha TI x Cliente acho que muitos por aqui tem experiências semelhantes.
Na minha opinião a culpa é de ambos. TI não consegue mostrar valor real para o cliente (ROI) e os clientes não querem perder “tempo” se envolvendo com os projetos, por medo, por não quererem perder o trabalho/comodismo deles, vários fatores.
Não fugindo ao tópico tem dois links que eu gostaria de compartilhar, acho que muitos aqui já devem ter lido
Um mais recente
Outro mais antigo mas que ainda se aplica totalmente a nossa realidade
Preciso sair de onde estou hoje, pois o cenário que venho vivendo há uns 4 anos é completamente o oposto disso… O que vejo é sempre uma guerrinha entre “TI vs Cliente” onde a culpa sempre é do outro e ninguém está satisfeito.
[/quote]
Acho que o JoseIgnacio quiz dizer “se as consultorias estão vendendo e o cliente não sabe que está sendo enganado”.
Na realidade o que vc observa é a insastifação de um cliente que não sabe que está sendo enganado. Poderiamos argumentar que ele que está enganando a TI, mas se ele estiver fazendo isso, isso é uma forma de se enganar a si mesmo (achando que está levando vantagem).
Aliás este é um assunto para uma thread inteira. O que realmente é vendido e o que realmente é entregue e como são as prespetivas e expectativas de cada lado.
Respondendo ao JoseIgnacio. Se vc estiver sozinho no meio do nada e matar, digamos, uma raposa quem vai saber ? Você vai saber.
É a mesma coisa no software. Se o cara faz um software porcaria ele vai saber. Agora, tal como no caso da raposa isso não significa que vc saiba que é mau ou bom, mas o fato em si , vc conhece-o. O juizo de valor é feito depois e à luz de uma moral e uma cultura. Ao discutir a prática A vs B estamos discutindo essa moral e essa cultura. Se a empresa A faz um software X por Z com .net e a empreza B faz o mesmo software X com java pelo menos preço , qual está enganando o cliente ?
Considerando que o preço é algo que se negocia, nenhuma. Mas considerando que o custo não é o mesmo, a empresa B , provavelmente teve menos lucro. Contudo, se B é proficiente em java e conta uma plataforma de aplicação , e ela que tem o maior lucro (ou igual). No prática o primeiro cenário é mais comum. Aliás o ceário mais comum é para um mesmo projeto X , java saia mais caro. Se sai melhor ou pior, teriamos que analizar caso a caso. Mas com certeza, o esforço em java é maior na prática devido à insuficiencia de investimento em plataformas de aplicação.
[quote=André Fonseca]Na minha opinião a culpa é de ambos. TI não consegue mostrar valor real para o cliente (ROI) e os clientes não querem perder “tempo” se envolvendo com os projetos, por medo, por não quererem perder o trabalho/comodismo deles, vários fatores.
[/quote]
Verdade cara, como dizia minha finada avó: “Só briga 2 quando todos 2 querem”… rsrsrsrsrs
O que eu vejo como grave nisso tudo é que a responsabilidade de orientar os clientes, é nossa, como PROFISSIONAIS de TI.
Se você abre um Banco e contrata alguém pra assumir sua TI, você está dizendo que confia nesse alguém pra te direcionar no assunto TI.
Eu me passo e fico de cara quando vejo pessoas de consultoria, começando essa guerra, enganando os clientes, colocando a culpa de erros que poderiam ter sido evitados com algumas skils, puramente nos clientes, forçando os mesmos a assinar um calhamaço de documento de coisas mal escritas, fazendo o mesmo pensar que alí estão as regras reais, etc… Vocês podem me dizer que se o cliente assina está assumindo a responsabilidade, eu já discordo disso de forma sumária e definitiva, mas isso é assunto pra outro Post, sem desviar o assunto…
Nunca tinha pensado nisso, mas realmente o tempo nos dá essa capacidade, ou a apura para quem já nasce com ela no sangue.
Interessante que o Post não toca no tema “Tecnologia utilizada” levando em consideração que a importância disso beira o 0, afinal sem saber o problema, difícil fica de saber o que usar, e já que o artigo trata de problemas em geral, porque então falar de linguagens ???
Acho que um grande problema em medir produtividade é a falta de métricas.
Raramente se vê alguém coletando indicadores do desenvolvimento de um projeto para saber o que foi bom ou ruim, lento ou rápido.
Com isso a produtividade não é medida, ela é “achada”, por feeling, experiências, velocidade do vento.
Isso faz com que na hora de comparar tecnologia, os mais sensatos adotem uma postura mais politicamente correta.
“Cada tecnologia tem seu caso de uso” ou “A produtividade individual conta mais do que a ferramenta”.
Apesar das frases fazerem todo sentido, acabam ocultando situações válidas:
Cada tecnologia tem seu caso de uso? Sim, mas tem tecnologias voltadas para os mesmos casos. Por que não compará-las?
A produtividade individual conta mais do que a ferramenta? Ok, comparem então duas pessoas com proficiência equivalente em ambas.
Se eu disser que o java 7 é bem mais produtivo do que o 1.1, acho que poucos vão se opor.
Por que não podemos comparar com a mesma frieza então, linguagens diferentes?
[quote=AbelBueno]Acho que um grande problema em medir produtividade é a falta de métricas.
Raramente se vê alguém coletando indicadores do desenvolvimento de um projeto para saber o que foi bom ou ruim, lento ou rápido.
Com isso a produtividade não é medida, ela é “achada”, por feeling, experiências, velocidade do vento.
Isso faz com que na hora de comparar tecnologia, os mais sensatos adotem uma postura mais politicamente correta.
“Cada tecnologia tem seu caso de uso” ou “A produtividade individual conta mais do que a ferramenta”.
Apesar das frases fazerem todo sentido, acabam ocultando situações válidas:
Cada tecnologia tem seu caso de uso? Sim, mas tem tecnologias voltadas para os mesmos casos. Por que não compará-las?
A produtividade individual conta mais do que a ferramenta? Ok, comparem então duas pessoas com proficiência equivalente em ambas.
Se eu disser que o java 7 é bem mais produtivo do que o 1.1, acho que poucos vão se opor.
Por que não podemos comparar com a mesma frieza então, linguagens diferentes?[/quote]
Na minha opinião o problema não é a falta de metricas, apesar de eu não conhecer métricas precisas a longo prazo.
Eu acredito que o principal problema é a natureza dinâmica da nossa profissão.
As pessoas trocam muito rápido de emprego, de função.
Um bom desenvolvedor demora tempo para se tornar produtivo também. E esse tempo é algo que muitas vezes não temos.
Muitas vezes uma pessoa que saiba muito acaba sendo menos produtiva do que outra que saiba muito menos do que ela mas que já está acostumada a lidar com as particularidades do ambiente do trabalho.
Uma coisa que eu sempre pensei é que: o problema dos projetos de SW não atingirem as metas dejadas raramente tem relação direta com a tecnologia adotada.
Não conheço a plataforma .NET da mesma forma que conheço Java. Pouco posso opniar sobre produtividade, mas da opnião que expresso abaixo, toda ela está baseada em leituras e conversas com amigos.
A questão não se referente apenas a produtividade, mas a curva de aprendizado, evolução da plataforma e ferramentas. Se comparamos todos esses quesitos, acho que .NET leva uma certa vantagem.
Do pouco que conheço, a plataforma .NET oferece tudo integrado, desde a parte de desenvolvimento ate o deploy da aplicação. Não é necessário baixar diversas ferramentas como maven, ant, softwares para integração continua plugins para eclipse ou netbeans.
Outra quesito que .NET leva vantagem é que. Um desenvolvedor java dependendo da empresa que vai, precisa conhecer Hibernate, Spring, JSF, Struts, DWR, JBoss, Websphere, Maven, Ant eclipse ou netbeans. E isso varia de empresa para empresa. Na plataforma .NET todo esse conhecimento não é exigido. A adptação de um desenvolvedor .NET é muito mais rápida quando ocorre a troca de emprego.
Peço desculpas caso tenha falado alguma besteira. Talvez uma pessoa com conhecimentos em ambas das plataformas, possa melhor opnar sobre o assunto.
[quote=MauNunes]Não conheço a plataforma .NET da mesma forma que conheço Java. Pouco posso opniar sobre produtividade, mas da opnião que expresso abaixo, toda ela está baseada em leituras e conversas com amigos.
A questão não se referente apenas a produtividade, mas a curva de aprendizado, evolução da plataforma e ferramentas. Se comparamos todos esses quesitos, acho que .NET leva uma certa vantagem.
Do pouco que conheço, a plataforma .NET oferece tudo integrado, desde a parte de desenvolvimento ate o deploy da aplicação. Não é necessário baixar diversas ferramentas como maven, ant, softwares para integração continua plugins para eclipse ou netbeans.
Outra quesito que .NET leva vantagem é que. Um desenvolvedor java dependendo da empresa que vai, precisa conhecer Hibernate, Spring, JSF, Struts, DWR, JBoss, Websphere, Maven, Ant eclipse ou netbeans. E isso varia de empresa para empresa. Na plataforma .NET todo esse conhecimento não é exigido. A adptação de um desenvolvedor .NET é muito mais rápida quando ocorre a troca de emprego.
Peço desculpas caso tenha falado alguma besteira. Talvez uma pessoa com conhecimentos em ambas das plataformas, possa melhor opnar sobre o assunto.
[/quote]
vejo muito isso, soma-se esse mesmo problema quando a empresa precisa manter sistemas legados em frameworks antigos…
porém microsoft também tem o problema com o asp classico, com a diferença que é extremamente facil, diferênte dos frameworks java…
Tipo, voce acha que desenvolvedores .NET nao se preocupam com design patterns, arquitetura “bem feita” e controle do codigo??
Quem desenvolve .NET sabe, se vc quiser criar um projeto MVC por exemplo, o Visual Studio ate tem um template que cria o projeto com algum codigo para voce (mesmo assim nao eh muito e nao eh porco de maneira alguma), tambem voce pode criar um projeto completamente branco. Mesma coisa com um projeto web com webforms, ou voce acha que soh porque o Visual Studio cria uma Default.aspx praticamente em branco e 3 folders eh muita coisa??
Na minha opiniao, desenvolver em .NET e mais produtivo que Java? Resposta, NAO. uhhhhh, descoberta do ano.
Eu nao acho que tem a ver com linguagens como alguns disseram, ate porque .NET suporta varias linguagens. E na minha opiniao isso faz a plataforma .NET se popularizar muito.
Ja trabalhei um bom tempo com Java e trabalho com .NET pouco mais de 4 anos e o que eu posso dizer eh, se alguem esta comecando a programar em Java profissionalmente, ok a pessoa tem que aprender Java (linguagem), leva um tempo para aprender, depois se for para programar pra web, tem que aprender outras coisas tipo, como funciona um servidor de aplicacao, como configurar e etc, depois tera que escolher dentre os milhares de frameworks disponiveis, aprender a usa-los e la se vai mais tempo, ai se ele quer aprender a otimizar processo de compilacao, packaging, deployment vai ter que aprender ANT, sem contar banco de dados, sistema de controle de versao e outras coisas mais “along the way”.
Ai quando a pessoa aprende tudo isso, faz um mabalarismo para fazer um hello world.
.NET por outro lado, voce tem o visual studio que eh uma otima IDE, tem alguns templates de projetos que mesmo sendo bem crus e algumas vezes vazios, ja servem como um ponto de partida pra quem esta comecando do zero. Fora isso existe o Cassini que eh um simples web server que hospeda ASP.NET entao, pra quem quer comecar um projeto seja webforms ou MVC, eh soh criar o projeto, teclar F5 e BAM!!! o browser abre com a pagina default ou default view para MVC e tudo funciona, vem ate com JQuery no folder scripts. Conexao com banco de dados eh muito simples, seja MSQL, MSQL Express, Oracle etc. Controle de acesso da sua aplicacao eh simples com Membership e Role providers.
A Microsoft tambem tem o TFS (Team Foundation Server) que eh usado para projetos em grupo, que tem controle de versao, tracking de projeto, controle de bugs e isso eh totalmente integrado com o Visual Studio, o que facilita muito, qualquer checkin eh associado a um projeto (story) ou um bug. A partir dai eu posso ver os bugs que foram reportados por projeto, criar queries para filtrar bugs do jeito que eu quiser, posso gerar um novo build e package da minha aplicacao, enfim, eh uma ferramente extremamente poderosa.
Pra quem reclama que .NET nao tem algo como o ANT, tem sim, tem o Windows PowerShell que da pra criar scripts para automizar compilacao, deployment, patch config files, mover ou copiar arquivos, funcoes administrativas no sistema, enfim, da pra fazer praticamente tudo.
Eu acho que a Microsoft fez um otimo trabalho em fazer todas essas ferramentas funcionarem de forma consistente, o que faz o aprendizado ser mais rapido. E isso na minha opiniao eh a maior vantagem em relacao ao Java hoje em dia. Voce consegue otimas resultados com Java, mas para isso voce tera que ter competencias em varias coisas que funcionam de maneira diferente e inconsistente. .NET esta tudo disponivel de maneira consistente e integrada.
Algumas pessoas podem argumentar, que isso eh o problema da microsoft que voce fica preso aos produtos que eles lancam, mas isso nao eh verdade, tem muitos projetos open source para projetos .NET . Outros argumentam com Microsoft nao eh transparente que os seus produtos sao uma “caixa-preta”, outra afirmacao que nao eh real, ano passado eu tive que implementar seguraca contra cross-site request forgery para projetos MVC na nossa framework e eu fiz o download do codigo do Microsoft MVC Framework que eh aberto para entender como funciona para ter inspiracao de como trabalhar na minha implementacao.
Sumarizando, pra mim nao depende de linguagem, nao depende de funcionalidades do .NET framework, como LINQ e outras framworks como Entity Framework e sim da uniformidade e integracao entre os produtos que fazem .NET ser uma otima plataforma para se trabalhar. Se isso faz as pessoas mais produtivas eu nao sei.
Produtividade eh muito subjetivo, um time pode ser super produtivo e entregar um projeto mal feito outro pode ser produtivo e ter um resultado de primeira. O que eh produtivo? Quem faz mais coisas em menos tempo ou quem faz menos mas com boa qualidade?
Os java fanboys costumam dizer que desenvolvedor .NET faz codigo mal-feito e alguns ate acham que design patterns eh uma coisa especifica para java. O que eu posso dizer eh que eu nunca vi tanto codigo mal feito quanto na epoca que eu trabalhei com Java, era um circo de horrores. Vi muita coisa boa, mas vi muita coisa ruim. Ate hoje soh vi codigo bom em .NET e eu acredito que eu melhorei 100% como desenvolvedor, aprendi nesses 4 anos. Pra mim, nao eh problema da plataforma e sim da peca em frente ao teclado.
PS: Essa foi a maior bosta que eu li nos ultimos anos.
A grande vantagem pregada pelo .NET sobre o java é o drag and drop. Esta pode ate ser em desktop, mas em projetos web ela é bem menor. .NET será mais produtiva se o cara não tem o menor conhecimento de HTML, css e javascritpt. Mas se ele não tem esse conhecimento, mesmo em .NET logo ele deixará de ser produtivo, porque vai se deparar com problemas que não vem com solução pronta.
E a diferença acaba ai. O que de fato aumenta/diminui a produtividade é a arquitetura da aplicação, a simplicidade com que o código foi feito, a clareza, o fácil entendimento do que está escrito e coisas do gênero. Coisas que independem completamente de linguagem/plataforma ou qualquer outra coisa.
Alguem citou ai que ninguem vai discutir que java 7 é mais produtivo que java 1. Pode ser, mas com certeza trabalhar numa base de código bem feita usando java 1 sera mais produtivo que numa base toda gambiarrada escrita em java 7.
As duas linguagens são tão parecidas, sempre uma copiando recursos uma da outra, que acho impossível ter alguma diferença de produtividade entre as duas linguagens.
Talvez um ou outro framework em uma área bem específica pode fazer uma pequena diferença. Mas no geral para mim a produtividade é a mesma.
Para termos uma produtividade perceptível teria que ter algum mudança de paradigma ou uma diferença grande entre as linguagens.
Vocês estão se esquecendo do principal…
A produtividade não está no Java nem no .Net, e sim nos frameworks aglomerados.
Vejam a exemplo:
Quem no mundo java dá mais produtividade?
Spring, Struts ou JSF?
No .Net, quem dá mais produtividade?
Spring, Asp.Net, Castle ou MVC3 Razor?
Entre Java e C#, escolho os dois… por incrível que pareça, o diferencial do C# durante muito tempo foi a api System.Linq.Expressions (Lambda Expressions), o que inclusive já existe pra Java. Opa, mas o Visual Studio tem Drag 'n Drop!
E o Netbeans tá pôdi?
As ferramentas Drag 'n Drop do Netbeans e do JDeveloper são idênticas ao Visual Studio.
Ah, mas no Visual Studio tá tudo integrado, F5 e a página já abre.
Meu irmão zé goiaba, o Visual Studio vem com o IIS Express assim como o Netbeans vem com o Tomcat, a tecla é a diferença, F6 FTW.
Ah mas no mundo Java tem uma infinidade de Frameworks, coisa que faz falta no .Net
Zé ruela, acho que 99% do que existe open source tanto em java como em .net é dispensável, você vivem sem eles. A propósito, a maioria dos frameworks open java possuem uma implementação .Net.
Vou citar alguns dentre os que utilizo, e que estão em ambas as plataformas de forma idêntica:
MVC
Java: Vraptor
.Net: MVC3 Razor
Manipulação de XML
Java: JAXB
.Net: System.Xml
Persistência
Java: Hibernate
.Net: nHibernate
Reconhecimento de Linguagem
Java: Antlr
.Net: Antlr (até o nome é igual ahahaha)
Agendamento de tarefas
Java: Quartz
.Net: Quartz.Net
Gerenciamento de Logs
Java: log4j
.Net: log4net
Para o XNA não tem equivalente, é extremamente produtivo
Zé ruela, já existe o jXNA que é a mesma porqueira.
Me digam, existe algum outro tipo de tarefa que você faça que não se utilize dessas ferramentas? Caso tenha, só falar que eu posto aqui.
Sendo assim, não é na linguagem que reside a facilidade de desenvolvimento, e sim no Framework e no profissional que o utiliza.
Spring e Spring.Net são beeeem iguais, JSF e Asp.Net são mais parecidos do que vocês imaginam. Porém o Razor está anos luz além, oops tá nada, no java tem Vraptor que é igualzinho, sem tirar nem as annotations e a injeção de dependências.
Amigos, essa disputa sobre quem é mais produtivo é mais religiosa do que prática.
Se você tem um profissional Java com Vraptor e Spring, ele vai ser mais produtivo que um profissional com Asp.Net Clássico. Em contrapartida, um profissional Razor vai ser mais ágil que um JSF.
Agora, se alguém aqui acha que a linguagem é que é ou não produtiva, refaça a faculdade, a lógica é igual para todas as linguagens, o que muda é o framework utilizado na aplicação.
Para finalizar minha participação no post, tirando a parte grosseira, concordo com o texto acima, publicado pelo windsofhell.
Só acho que o assunto não merece um artigo. Opnião é opnião e deve ser respeitada. Publica um artigo comparando duas plataformas é dar um tiro no pé e com certeza não vai chegar a conclusão nenhuma.
Tem algo errado na sua analise. Porque aquilo que eu disse é o mesmo que vc disse nos dois paragrafos acima. Talvez você não tenha entendido, mas é o mesmo.
Você está julgando pela sua experiencia de ter programados nos dois, eu estou julgando pela experiencia de várias equipes de uma e outra plataforma. Talvez vc use padrões e boas práticas (provavelmente porque começou pelo java onde vc aprender isso) , mas não é comum o pessoal de .net saber ou usar padrões da mesma forma que em java. Para o pessoal do .net usar isso o lider tecnico precisa ser forte e com muita experiencia e uma certa pitada de autoritarismo, porque se não, o pessoal não aceita. A gamba é sempre o primeiro recurso.
Engraçado como vc diz a mesma coisa com palavras diferentes e depois diz que é tudo errado. :lol: :lol:
[quote=sergiotaborda]
Tem algo errado na sua analise. Porque aquilo que eu disse é o mesmo que vc disse nos dois paragrafos acima. Talvez você não tenha entendido, mas é o mesmo.
Você está julgando pela sua experiencia de ter programados nos dois, eu estou julgando pela experiencia de várias equipes de uma e outra plataforma. Talvez vc use padrões e boas práticas (provavelmente porque começou pelo java onde vc aprender isso) , mas não é comum o pessoal de .net saber ou usar padrões da mesma forma que em java. Para o pessoal do .net usar isso o lider tecnico precisa ser forte e com muita experiencia e uma certa pitada de autoritarismo, porque se não, o pessoal não aceita. A gamba é sempre o primeiro recurso.
Engraçado como vc diz a mesma coisa com palavras diferentes e depois diz que é tudo errado. :lol: :lol: [/quote]
Nao mesmo. Pelo contrario, eu nao acredito que o pessoal que trabalha com .NET eh movido pelo “se funciona ou nao” como voce disse. Eu acho que os desenvolvedores .NET sao tao tecnicos, preocupados em obedecer os principios de orientacao a objetos, boas praticas, design patterns e etc, assim como eu acredito que tem gente assim desenvolvendo em Java.
Usando meu exemplo aqui na empresa, nos temos nosso proprio produto e varias frameworks, os nossos “usuarios” nao sao o usuario final e sim empresas parceiras que usam a nossa solucao e framework para desenvolvimento. Entao nos temos uma responsabilidade muito grande quanto ao codigo que nos lancamos. Primeiro que o produto tem que ser bem projetado ao ponto de ser flexivel o suficiente para atender as necessidades de outros desenvolvedores, segundo, tem que atender todos as boas praticas e padroes estabelecidos para .NET.
Nos temos o Resharper que eh uma extensao para Visual Studio que faz analise de codigo para assegurar que esta respeitando certos padroes. Fora isso, o nosso TFS (Team Foundation Server), a cada check-in roda todos os nossos unit tests, roda uma ferramenta que analisa client-server code (Javascript e CSS) caso tenha um problema check-in eh cancelado.
Fora isso antes de check-in o nosso codigo tem que ser revisado por pelo menos duas pessoas. Enfim, codigo tosco nao passa.
Nas empresas que eu trabalhei com Java, muitos lugares nao tinham unit tests, a maioria dos bugfixes eram gambis. Alguns projetos nao tinham nenhuma estrutura definida, check-ins a vontade, sem nenhuma qualidade, sem comentarios, sem reviews, sem nada.
Nao estou dizendo que eh regra. Ate porque eu tambem vi muito codigo bom e pessoas muito capacitadas trabalhando com Java, aqui no forum mesmo. Mas o que eu quero dizer eh que eh muito errada essa visao que o povo tem um projeto .NET eh tipo, ok, abro o meu Visual Studio, click e arrasto alguns controls para a minha pagina, ta rodando firmeza!
Talvez voce nao tenha entendido, mas o que eu quis dizer eh que eu nao acho que .NET eh mais produtivo que Java, mas pelo menos facilita um pouco a vida quando uma empresa disponibiliza tudo o que vc precisa, IDE, banco de dados, controle de versao, gerenciamento de projetos, frameworks diversos e tudo eh integrado e obedece um padrao, e o contrario que voce disse nao estamos “vendor locked in” porque tem muitos projetos open source disponiveis.
O mesmo eu nao sinto com Java, as vezes vc tem que confiar ate em projetos privados obscuros para desenvolvedor o seu projeto e pra fazer algo simples sao 4501 easy steps, configuracoes, erros, dor de cabeca, trocentas libs sem consistencia nenhuma, o que as vezes pode ser um impedimento para que o desenvolvimento ocorra de forma mais tranquila.
Preciso sair de onde estou hoje, pois o cenário que venho vivendo há uns 4 anos é completamente o oposto disso… O que vejo é sempre uma guerrinha entre “TI vs Cliente” onde a culpa sempre é do outro e ninguém está satisfeito.
Estou terminando um Post em meu blog sobre isso e gostaria de atualizar o status, pois até onde eu pensava, era a realidade do mercado
Nessas horas que vejo que estou no lugar errado.
Creio que a discussão está indo em um nível muito bom e cada opinião, achamos novidades…
Abs [][/quote]
Repare que falei o cliente está satisfeito, e não os desenvolvedores da consultoria. Isso eu imaginei porque as consultorias continuam atuando no mercado, então os clientes estão voltando?
Os desenvolvedores concordo com você, pelo menos aqueles que valorizam sua profissão, quase sempre estarão infelizes num ambiente de consultoria, mas acho que isso é assunto pra outro tópico.
No que diz a produtividade, acho que o sergiotaborda tocou na raiz da questão quando falou que falta uma plataforma de aplicação no Java. Para o típico cliente de consultoria, que é averso à risco, isso faz muita falta.
Até porque, no fim o mais produtivo é aquele que consegue criar algo funcionando com janela, botões e tudo mais, não aquele que fica discutindo combinações de arquitetura/frameworks/padrões que não leva a lugar nenhum.
Preciso sair de onde estou hoje, pois o cenário que venho vivendo há uns 4 anos é completamente o oposto disso… O que vejo é sempre uma guerrinha entre “TI vs Cliente” onde a culpa sempre é do outro e ninguém está satisfeito.
Estou terminando um Post em meu blog sobre isso e gostaria de atualizar o status, pois até onde eu pensava, era a realidade do mercado
Nessas horas que vejo que estou no lugar errado.
Creio que a discussão está indo em um nível muito bom e cada opinião, achamos novidades…
Abs [][/quote]
Repare que falei o cliente está satisfeito, e não os desenvolvedores da consultoria. Isso eu imaginei porque as consultorias continuam atuando no mercado, então os clientes estão voltando?
Os desenvolvedores concordo com você, pelo menos aqueles que valorizam sua profissão, quase sempre estarão infelizes num ambiente de consultoria, mas acho que isso é assunto pra outro tópico.
No que diz a produtividade, acho que o sergiotaborda tocou na raiz da questão quando falou que falta uma plataforma de aplicação no Java. Para o típico cliente de consultoria, que é averso à risco, isso faz muita falta.
Até porque, no fim o mais produtivo é aquele que consegue criar algo funcionando com janela, botões e tudo mais, não aquele que fica discutindo combinações de arquitetura/frameworks/padrões que não leva a lugar nenhum.[/quote]
Não vejo problemas se criar algo que funcione com janela e botões… acho isso até muito valido… o problema começa quando isso PARA DE FUNCIONAR…
Em muitos desses casos, esse para de funcionar não existe. São casos que ferramentas como Maker e Genexus podem ser ótimas alternativas. Até o Access é alternativa.
As vezes as pessoas acham que uma tecnologia é improdutiva, mas não enxergam que na verdade estão matando moscas com bazuca!
Em relação a cultura .NET eu concordo com o Sergio. Não que não há bons desenvolvedores que trabalham com .NET. Pelo contrário, há excelentes… mas muita gente usa .NET para criar solução de má qualidade, graças a essa maravilhosa integração… e não que isso seja uma coisa ruim. Imagine se todo sistema de padaria precisasse ser criado com uma arquitetura ferrada e tals… tem fatia do mercado para esses “sisteminhas” sim! Só não adianta o pogramador achar que vai ganhar 10K por mês dessa forma!
Pior ainda quando se fala de PHP… se pegar 100 sistemas desenvolvidos em PHP, se apenas 1 deles utilizar OO, Classes, Arquitetura, etc… é muito… A maioria será um monte de script tosco misturado no código html… isso é ruim ??? Eu não acho… para quem tem esses sistemas, ou tem isso ou não teria nada!
Discordo da maioria dos seus argumentos. Primeiro de tudo, o maven não vem integrado no Java. O desenvolvedor já tem que começar aprendendo a usar o maven.
Depois, ele tem que saber o que são os milhares de pequenos pacotes e as opções que o maven dá.
Mesmo que ele baixe uma pacotaiada integrada, como no meu caso que estou usando Hibernate+Spring+JPA+GraniteDS, tem que conhecer à fundo onde cada peça desse enorme tabuleiro se encaixa. Há dezenas de XMLs para configurar, vários pequenos detalhes, construções obsoletas e equivalentes (como no caso do Hibernate e JPA), entre outras coisas que irão aparecer junto com as primeiras classes do projeto. Aí, começa também a fase de aprendizado, onde você começa a descobrir que limitações de um framework fazem com que a promessa de outros vão por água abaixo (por exemplo, o GraniteDS não suporta atributos em lazy-loading, o que limita o uso desse recurso lá no JPA).
Acho que não vale o argumento de “a culpa é do arquiteto” ou de que é “culpa do programador”. Esse é um argumento irracional, pois no final das contas, a culpa será sempre do arquiteto ou do programador. Esse tipo de argumento me lembra muito os fóruns de C++, quando o pessoal fala que ponteiros não tornam o programador C++ menos produtivo, pois os erros que eles trazem são culpa do programador…
Se estamos falando de frameworks e de produtividade, temos que entender o quanto ele facilita ou dificulta a vida de quem os usa. Ou seja, o quanto eles evitam os erros do programador, o quanto eles livram de burocracias e permitem que ele se foque nos problemas que realmente tem que resolver. Se estamos falando de produtividade, o questionamento é justamente nessa “uma facilidade a mais ou outra devido a alguma integração mais fácil com banco de dados ou coisa similar” que os frameworks fornecem.
No caso do .Net, acho que é mais fácil configurar um ambiente.
Na minha opinião as principais razões são:
O .Net framework é mais novo, portanto há menos opções disponíveis. Isso tende a se reverter com o tempo. Por exemplo, hoje, você já pode escolher entre WebForms e MVC na camada de apresentação. Além disso, pode optar por usar ou não Razor. Amanhã ou depois, vão surgir ainda mais tecnologias e logo a sopa de letrinhas do .Net vai ficar tão complicada como a do Java;
Como consequencia do fato de ser mais novo, a MS teve a oportunidade de criar uma pilha inicial já corrigindo falhas do Java, e integrando pontos problemáticos;
A MS, ao realizar evolução tecnológica, pressiona os desenvolvedores a abandonarem as tecnologias antigas. As vezes até de forma um tanto agressiva (como o marcosalex gosta de ressaltar);
Os produtos da MS são realmente muitíssimo bem integrados, confiáveis e o suporte da MS é muito bom.
Recursos que o C# tem a mais que o Java:
Structs;
Delegates
Co-rotinas
Properties
Extension Methods
Lambda (só vem no Java 8)
Partial classes
Sobrecarga de operadores
Construtores implícitos
LINQ
Controle paralelo - que está entre os recursos mais espetaculares que já vi;
Variáveis unsigned e de ponto-fixo;
Visibilidade internal (publico no “.jar”, privado fora do .jar);
Alguns recursos no .C# também são melhores implementados:
Generics não são um truque de compilação, e podem ser usados inclusive com tipos primitivos;
Métodos unsafe, muito mais fáceis e seguros de usar que JNI;
API de XML integrada ao LINQ;
API de reflection com sintaxe muito mais simples e direta;
O .net não tem o recurso de Inner Class anônima, que é parcialmente suprido por lambdas e delegates.
Se você estiver no mercado de Desktop também vai notar que:
O Swing é muito antiquado;
Não há frameworks para aplicações gráficas como games;
Há pouca integração com o SO, e JNI/JNA são trabalhosos comparados com os metodos unsafe;
O Java delega ao usuário a responsabilidade de conhecer a VM;
Sobre o tema central da discussão.
.Net é mais produtivo que Java?
Creio que atualmente é, no mínimo, mais confortável programar em C# e .Net do que em Java.
Mas não ao ponto de isso significar uma vantagem decisória no projeto, ou uma redução muito significativa de custos.
O fato é que nunca é produtivo construir software robusto e de qualidade. Requisitos sempre mudam no meio do ciclo. Além disso, também compartilho da opinião do jmmenezes, onde não adianta tentar falar de produtividade “no geral”. Teríamos que especificar um tipo de situação e considerar algum tipo de know-how por parte das equipes sendo comparadas.
No caso de sistemas web, confesso que estou muito impressionado com a produtividade que tivemos com MVC + Razor. E, agora que estou programando lado-a-lado um sistema .Net e um Java, percebo que o Java se tornou muito burocrático durante os anos. Entretanto, no caso do .Net, sei que muita da integração veio do fato de termos praticamente toda infra Microsoft…
No mais, concordo muito com a opinião que o windsofhell colocou até agora. Esse história de programador MS ser programador Drag&Drop já foi verdade no passado, mas se torna menos verdade a cada ano. A MS tem estimulado muito os desenvolvedores a estudar padrões, os frameworks mais novos tem um novo grau de maturidade e há bons desenvolvedores na comunidade puxando o profissional para cima, como é o caso do Elemar Júnior.
Claro, ainda há mais desenvolvedores que abusam do Drag&Drop, assim como em Java tem o extremo oposto. Quem nunca parou aqui num projeto feito por um desenvolvedor que saiu encapsulando, generalizando e invertendo todas as dependências do projeto, criando centenas de camadas, só porque leu em algum lugar sobre IoC e MVC?
Quanta dessa burocracia se deve ao fato de não existir investimento em plataformas de aplicação nas empresas , sejam elas software houses ou que produzem in house ?
Para mim, a microsoft sempre teve esta filosofia de RAD (rapid application development) que vem desde do VB. E isso só se consegue com uma plataforma de aplicação.
A qual a MS integra no produto. Não N forma de acessar banco ou fazer telas. Ha 1 e pronto. No máxmo duas e vai-que-vai. Como vc falou a simplificação é grande. Não ao contrário do que falou, o .net não tem menos opções porque é novo, é porque design. Ele é feito para ter poucas opções que são usadas exaustivamente. novas coisas nascem quando o básico não dá conta ( o novo MVC é diferente de formas como o Spring MVC é diferente do JSF ou do Vaadin. Tratam nichos diferentes de aplicações. fazer e-comerce apenas com JSF é tão ruim quanto fazer com ASP.net não mvc)
O fato de ter sido verdade em algum momento é o ponto do argumento, porque demonstra que é possivel. É da escolha do profissional usar ou não, mas quando não é possivel, não se usa. Embora o netbeans tente seguir a filosofia RAD (afinal é o competidor do Visual Studio. O Eclipse não compete com o VS) o programador java não é ensinado dessa forma. A estrutrua mental do desenvolvedor java nasce longe do Drag&Drop, a do .net nasce perto e se afasta conforme a senioridade do dev. O junior que não faz drag&drop é porque tem um compreensão grande do que faz ou foi ensinado por alguém que sabia. Qantas pessoas saem assim dos cursos de formação ? vs quantas pessoas saem não usando drag&drop dos cursos de java ?
Sim, todo o mundo pode fazer asneiras. O ponto é que com menos facilidade, é menos provável fazer asneiras. Enão, java é mais seguro, nesse sentido, e por consequencia menos produtivo. Não dá para catar um cara aleatoriamente na rua e por para fazer tela swing (sem ide) mas dá para fazer isso com .NET e muitos fazem. Sim, sabemos que não são vocês que fazem, mas ha muitos que fazem.
Em java é mais dificil programar por coincidencia. É possivel, mas mais dificil. Em .net é mais fácil, e por isso a sensação que é mais produtivo, que é mais rápido, que se observam as telas funcionando em menos tempo.
Sim, a MS vem vindo a melhorar nesse aspeto (inclusive contratando pessoas da ex Sun, como o Joshua Bloch - não é por acaso que C#4 o LINQ existem). Mas esta melhoria é apenas uma tentativa de nivelar o mercado. Porque quando o cara faz gamb com o .net a MS leva por tabela porque o dev vai culpar a plataforma.
Não se nega que existam profissionais que sabem usar o .net como é suposto. O ponto é que é possivel que pessoas não preparadas também o usem -de formas alternativas - e mesmo assim produzam software funcional. O RAD atrai muita gente, inclusive as pessoas da gerencia e diretoria que não sabem pensar sem ver uma tela. O RAD existe em ferramentas como Rails (os varios sabores) mas isso é para web. (O Maker e outros da mesma laia prometem este mesmo RAD, ainda mais rápido às vezes. Os gerentes compram esta ideia ). O .net consegue o mesmo para desktop. Hoje existem algumas iniciativas para conseguir o RAD em java para desktop - aqui apenas acontece que o parque de aplicações desktop em java é ainda pequeno.
Sendo mais dificil em java começar do zero sem saber o que se está fazendo forçando a um setup de ambiente que no .net já vem integrado ( embora seja possivel conseguir o mesmo em java, é mais complexo e na prática ninguém cria um CD de instalação que monta eclipse, svn, sdk, etc… num golpe só) o java parece menos produtivo. E se vc tem um projeto para entregar em duas semans com 20 telas é muito provavel que não use java (a menos que já tenha um plataforma de aplicação pronta em java)
Esta facilidade inicial dá uma uma maior produtividade na fase inicial do projeto. A incepção é mais rápida e é possivel visualizar as coisas em menos tempos. Isto é uma forma de produtividade onde o .net ganha. Não porque apenas é possivel nele, mas porque já vem pronto nele. Em java tb é possivel, mas não vem pronto.
Dai para a frente a produtividade é a mesma. Ou seja, quando no projeto java as coisas estão encaixadas e vc simplesmente sai usando a “infra” (que é na realidade a plataforma de aplicação) ai vc está competindo de igual para igual. A produtividade neste nível é a mesma.
Depois vem a produtividade que é ganha pela suporte de deploy. Em java existem várias opções, todas semelhantes em conceito ao mundo .net (embora o .net não tenha um servidor de aplicação compativel com CORBA). À parte da diferença obvia de que java 'deploya" em muitos OS, os padrões EE também desacoplam a implementação do ambiente de execução. Por isto ha um overhead de configuração. Mas se vc usar produtos pagos vc terá a mesma facilidade que com o .net.
Neste nivel a produtividade é a mesma se compararmos produtos pagos. Se comparamos produtos free, acho que sempre haverá alguma configuração e alguma limitação, mas em geral, java tem uma ligeira vantagem por ser multiplataforma. Mas é muito pouca a diferença.
Portanto, olhando as 3 maiores fases de projeto (concepção, desenvolvimento e manutenção) em geral o .NET é realmente mais produtivo. Não pela linguagems, não pelos LINQ da vida , mas pelo empacotamento padrão que é dado à priori e pela IDE. Se em todas as aplicações java vc simplesmente importasse uma lib com tudo lá dentro seria tão ou mais rápido que o .net padrão. ( algums ambientes java fazem isto como o Spring Roo, o Grails e o Vaadin, mas não são padrão)
