A minha visão do desenvolvimento de software existir é para resolver o problema de algum usuário.
Se não há problema, não há necessidade de fazer software.
Se arrastar 3 componentes resolvesse meu problema sem me gerar uma imensa dor de cabeça no futuro (ex.: código impossível de dar manutenção), a resposta é sim, gostaria de arrastar os 3 componentes, pois resolveria o problema do meu usuário em menos tempo e eu conseguiria uma margem de lucro maior.
Se por outro lado, a sua questão não é desenvolvimento de software para usuário. Se você faz isso por amor a arte. Se você faz isso porque gosta de estudar tecnologias e quer se aprofundar. Aí estamos falando de um mundo completamente diferente, onde uma ferramenta que facilita as coisas (arrastar 3 componentes) estaria “impedindo” você de estudar, de conhecer, etc, etc, etc, etc.
A maior parte do tempo eu me encaixo no segundo perfil e é por isso que participo do forum, apesar de não trabalhar mais com desenvolvimento de software, simplesmente gosto de ler discussões religiosas sobre tecnologia!
Outra estratégia que eu sempre adotei quando ainda trabalhava com desenvolvimento de software, era fugir das áreas onde uma ferramenta drag’n’drop poderia resolver todos os meus problemas. Assim, a única maneira de ser produtivo era estudando tecnologia a fundo e ficar escovando bits!
[quote=campello] A minha visão do desenvolvimento de software existir é para resolver o problema de algum usuário.
Se não há problema, não há necessidade de fazer software. [/quote]
Concordo! E Ainda bém que eles dependem da gente para resolver os problemas deles!
Para um gerente esta visão é maravilhosa! (Talvez o Marketing da Microsoft queira extamente atingir este alvo!) Os programadores de um jeito ou de outro terão de se moldar para a vontade de seu gerente!
Esse é um assunto meio embaçado de debater. Tem milhões de coisas passando na minha cabeça! O que deveriamos entrar em debate é quais será a realidade e o cotidiano do dia a dia do profissional diante dessa nova realidade. Imagine que você também passaria a depender da empresa que lhe fornece a solução que lhe permite arrastar os 3 benditos componentes. Como as mudanças são frequentes, alem de vc ser ágil, a empresa que fornece a solução deverá ser ainda mais ágil. Talvez se vc manter uma equipe e não depender de uma empresa fornecedora seja mais interessante.
Observação: Isso é uma especulação.
Exatamente. Me encaixo nesta situação. Por isso se deve minhas respostas secas e diretas ao criticar tenologias que facilitam demais a vida do programador. Talvez por que eu ainda seja manezin.
Mas campello, se for ter uma visão mais por cima do assunto, acredito que não será uma ferramenta quem vai facilitar a vida dos desenvolvedores ou é quem vai facilitar o desenvolvimento de software e resolver o problema do cliente. Acho que ao invés de uma tecnologia, surgirá uma nova forma de organização. OU seja, a solução não será tecnológica, e sim organizacional! Vide por exemplo o surgimento das metodologias ágeis e aquela qualidade que as empresas exigem em seus profissionais que é a abilidade de se trabalhar em grupo! Apesar das empresas não facilitarem o trabalho em grupo, em minha opinião esse sera o diferencial!
[quote=campello] A maior parte do tempo eu me encaixo no segundo perfil e é por isso que participo do forum, apesar de não trabalhar mais com desenvolvimento de software, simplesmente gosto de ler discussões religiosas sobre tecnologia!
Outra estratégia que eu sempre adotei quando ainda trabalhava com desenvolvimento de software, era fugir das áreas onde uma ferramenta drag’n’drop poderia resolver todos os meus problemas. Assim, a única maneira de ser produtivo era estudando tecnologia a fundo e ficar escovando bits! [/quote]
hehehe!! boa! Então vamos aproveitar e fazer isso enquanto pudermos!
Caraco… pelo que to vendo o java só presta pq é complicado desenvolver os objetos… ah para né ! Curto o Java, mas não é muito produtivo em fazer sistemas desktops… isso todos tem de concordar, agora falarem que o .NET é ruim… meu, não é essas maravilhas, mas assim como o Java ele é uma ótima linguagem OO… com a vantagem de ser muito mais produtiva…
Quem trabalha em cima de produtividade, tem que fugir do Java, nem sempre podemos fazer projetos elaborados… temos que entregar coisas em uma semana… ou menos, com prazos apertadissimos…
Não to defendendo o .NET e desmerecendo o Java… mas o mercado exige dinamismo… e nem sempre dá para ficar 3, 4 meees desenvolvendo um projeto… clientes não gostam de esperar…
O problema não está na tecnologia ser ágil ou não! Se você não tiver uma boa equipe de desenvolvimento e o prazo foi muito curto, independente de se você está usando java ou dotNet o sistema sairá uma porcaria!
Daí eu te pergunto! O que seria ser produtivo para você? Entregar um sistema rapidamente dentro do prazo que é execivamente curto? Ou ser ágil é desenvolver um sistema que seja tranquilo para se manutenir e de fazer updates?
Esse negócio de arrastar-aqui e arrastar-ali não é garantia de produtividade.
Concordo com o Thiago.
O que importa é a qualidade e o padrão de desenvolvimento da equipe.
Ter uma boa especificação e planejamento ajuda muito, mesmo que hoje isso não tenha muita importancia para as empresas.
Já houvi uma frase (Acho que foi do Abraao Lincoln):
“Prefiro ficar uma dia inteiro afiando o serrote e cortar a arvore em poucas horas doque afiar o serrote em poucas horas e ficar o dia inteiro para derrubar a árvore”.
Ambiente: Fábrica de Software
Todo programador precisa de pelo menos 1 PC para produzir código fonte (a fábrica de software do meu exemplo não usa XP ).
É melhor ter um fornecedor de PC?
Ou ter uma equipe de desenvolvimento de hardware e não depender de uma empresa fornecedora pode ser mais interessante?
Não consegui acompanhar o seu nível de abstração! IMHO, problemas computacionais continuarão sendo resolvidos por computadores. Não vejo como mudanças organizacionais podem ajudar a fazer o relatório de vendas do mês passado ser produzido, por exemplo!
Arfa: Computers, singing, reading, painting and gardening are my hobbies. I have won a singing competition at the national level. I keep my self updated by reading different books and encyclopedias.
Se foi ela mesmo que respondeu a entrevista por email, ela tem um nível de vocabulário surpreendente - acho que estudar para a certificação da Microsoft foi um “passeio” para ela. Daqui a alguns anos ela vai estar nas páginas do noticiário econômico, preparem-se.
Ser produtivo, é levar menos tempo com coisas bobas, tipo, conexão com bd, criação de telas, enfim, vc se engajar somente no negócio, na regra, ah, tenho que calcular tal imposto de tal maneira, não se preocupar em criar uma conexão com o BD, uma tela, etc para enfim chegar no cálculo…
O que eu quis deixar aqui, é que todo mundo mete o pau na facilidade de uma x linguagem… e fala bem da outra pq ela é mais complicada, cara, adoro o .NET, mas vc´s tem que convir que antes de fazer um cadastrinho básico vc precisa criar todo um projeto… eqto em algumas linguagens vc faria isso em minutos… se depois é mais dificil ou não de dar manutenção são outros quinhentos…
Vejo isso aqui na empresa, na agilidade que temos em resolver pequenos problemas e nos novos projetos… se fizessemos em Java, levariamos tempo demais em coisas que fazemos em minutos hj.
Mesmo assim pretendo trabalhar com Java num futuro muito próximo… em uma empresa que tenha projetos organizados, que tenha tempo para desenvolver de uma maneira boa e de qualidade… UTOPIA… mas isso deve existir em algum lugar…
Você é programador né? Asssim como eu, acredito que vc não tem a inteção de ser programador a vida inteira. Uma hora vc vai ser gerente ou coordenador de projeto, naum é? OU um diretor de fábrica de software. Naum é? Então por que UTOPIA?
Acredito que este um dia poderemos fazer este cenário se reverter, apesar das dificuldades!
Você é programador né? Asssim como eu, acredito que vc não tem a inteção de ser programador a vida inteira. Uma hora vc vai ser gerente ou coordenador de projeto, naum é? OU um diretor de fábrica de software. Naum é? Então por que UTOPIA?
Acredito que este um dia poderemos fazer este cenário se reverter, apesar das dificuldades![/quote]
Maldade nenhuma… acho que ser um gerente ou coordenador de projeto é uma boa… mesmo assim, não sou eu quem faz o tempo… mas sim o cliente… não se ganha um projeto se vc demorar anos ou meses para se entregue… a concorrência hj em dia é forte…
Mas o que eu gosto mesmo é de programar… nunca me vi como um gerente ou coordenador… eu sou líder do meu módulo aqui na empresa, tomo conta da parte de entradas de estoque, compras, valorização do estoque, cadastro de produtos e matérias prima… e sei bem como é um cara chegar para vc e falar, quero para agora esse projeto de refazer a valorização do estoque… sem projeto, apenas com um case (que muitas vezes vem furado)… cara, foi 2 semanas de stress para reescrever toda a parte de valorização, criar telas, procedures no banco, gerenciar tabelas, nossa… acho que ficariam doidos se eu fizesse um projetinho, montasse diagramas etc…
Mas enfim, quem sabe um dia tudo isso deixe de acontecer…
Fabiano Banin, concordo quando você fala que não podemos ficar “perdendo” tempo em coisas como telas, conexao, etc etc etc… Eu mesmo não sou fã de Java para desktop e muito menos de ficar criando JFrames, JButtons, etc etc etc na mão, mas não é pq vc desenvolve um cadastro mais rápido que o meu, que significa que voce foi mais produtivo. E as manutenções? isso entra em consideração sim, pois as manutenções sempre ocorrem, e hoje uma empresa para se dar bem, além de ter um produto bom, tem que ser muito ágil em suas manutenções (digo manutenção de regras de negócios e não telas e etc).
Vejamos o caso de delphi por exemplo, pelo menos de 99% dos programadores de delphi, inclusive eu. A tela é feita de uma forma rápida, existem vários componentes prontos, drag and drop e pronto… mas e as regras de negócios? ficam geralmente tudo nos eventos dos botões…
E se vc quiser reaproveitar isso? e se for dar manutenção em uma parte que uma pessoa da sua equipe que mora na China fez, como vc vai fazer?
Então nao podemos falar que “produtividade” é apenas a entrega rápida do sistema.
Eu não gosto de Java porque é mais “dificil” que as outras, se fosse assim eu voltaria para o Assembly. A questão é o que o Java pode me oferecer (além de emprego ), é divertido, é sim muito produtivo (pelo menos no que eu trabalho) e é muito poderoso. Mas concordo com você que não devemos desmerecer a tecnologia .NET, inclusive é bom ter rivalidade, assim as duas crescem :lol:
Fico fudido quando alguém me diz que tem coisas muito boas no dotNet que devem ser aproveitas no java. Eu não fico fudido pelo fato de achar a tenologia dotNet uma merda. Eu fico fudido porque sou obrigado em concordar com vocês!!
Eu falo que é uma merda, mas é da boca pra fora. É uma espécie de rivalidade natural. Mais ou menos como o Campello comentou, onde a gente programa por fazer e gosta dos desafios. O meu defeito, mas de certa forma também é uma qualidade, é de vestir a camisa de uma tecnologia.
Uma colocação muito interessante do manchester foi o fato de que a produtividade não está nas pequenas coisas como tela, mas está na verdade em coisas menores.
Eu hoje perdi 4 horas para encontrar um BUG, no qual sua solução era apenas substituir uma palavrinha besta! É ai que acontece em minha opinião a maior perca de tempo! Sem contar que eu sou ruim para resolver bugs!
Cara não necessáriamente…
Esse é o problema do pessoal. Pensar que se vc tem RAD deve ter a lógica de negócios na tela.
É o que o pessoal geralmente faz. Mas não é a meneira melhor.
Podemos ter RAD com uma arquitetura decente por trás…
Ótima comparação que vc fez. Acho que preciso dar uma satisfação, né!
Concordo com você. A área de hardware não precisa de uma equipe exclusiva para manutenir 100 micros de uma fábrica de software.
Mas imagine que esta fábrica de software depende por exemplo da Borland para fazer uma alteração urgente no seu servidor de aplicação para seja possível satisfazer seu cliente.
Este é um assunto que eu estou meio que indo no chute. Este assunto é digno de um tópico so para ele!
Claro, da visão que vc está vendo vc está correto. O problema do cliente será resolvido computacionalmente!
Mas a questão que estou me referindo é quanto a equipe que irá se mobilizar para desenvolver a solução computacional para o cliente!