meh… agora a culpa é minha se nenhum sênior que ser o seu digitador de luxo?
Off topic:
Você deveria atualizar sua assinatura visto que “aquecimento global” já foi provado por cientistas que não passa de uma fraude (existe mais gelo se formando nas calotas polares do que 35 anos atrás).
O termo usado por quem defende socialismo e intervenção estatal agora é “mudança climática”. 
[quote=Impossivel]meh… agora a culpa é minha se nenhum sênior que ser o seu digitador de luxo?
Off topic:
Você deveria atualizar sua assinatura visto que “aquecimento global” já foi provado por cientistas que não passa de uma fraude (existe mais gelo se formando nas calotas polares do que 35 anos atrás).
O termo usado por quem defende socialismo e intervenção estatal agora é “mudança climática”. ;)[/quote]
Hum… Boa ideia:
[youtube]http://www.youtube.com/watch?v=mwQc3DnG7xc&list=UUdGpd0gNn38UKwoncZd9rmA[/youtube]
[quote=Clu]
Sério, todos esses sênior, júnior e equilíbrio… por um momento achei que estivesse falando de uma reunião de família na yoga.[/quote]
fonte do balão:
Uma coisa é concordar que precisa ter equilíbrio no design, outra coisa é dizer que o conhecimento do produto e do design da solução é responsabilidade do analista e afirmar que isso é quanto mais conhecimento melhor.
Enfim, continue postando imagens engraçadinhas, eu não ligo, mas o que eu gostaria é que você explicasse as contradições no seu argumento ao invés de usar minhas frases fora de contexto no seu exercício de comédia.
Lembrando que não existe meio-termo, ou você defende que esse conhecimento é responsabilidade do analista ou da equipe portanto, portanto a desculpa do equilíbrio não funciona aqui.
Engraçado você se referir a essa frase porque o autor dessa frase no livro No Silver Bullet - Essence and Accidents of Software Engineering, Fred Brooks, diz que programadores devem focar na solução, ou seja, o que o produto deve faz (complexidade essencial) ao invés de frameworks e patterns (complexidade acidental).
E aqui estamos ouvindo você dizer a frase dele pra fazer o argumento contrário.
[quote=adriano_si]
O amigão aí tentou, porque tentou dizer que o “foco no produto” é tudo o que importa e não concordou com o equilíbrio que propomos à conversa. Pra corroborar sua tese, ele disse que trabalha com Games e que isso era suficiente pra provar que o que ele dizia era a verdade absoluta. Pedí o portfólio de games dele, ou da empresa onde ele trabalha… É pedir muito? Você acha que isso é pedir muito? Não tô enchendo o saco, tô querendo validar uma opinião de alguém que a colocou como verdade absoluta. Nada mais justo do que ele mostrar o resultado do foco no produto.
EU não defendi processos, eu defendi equilíbrio, pois código lixo não te ajuda a responder a mudanças e não interessa onde você está, se no mundo corporativo ou montando sua empresa, se seu software não é adaptável (garantido pela sua arquitetura), não existe o tal “foco no produto”.
Então sim, ainda estou esperando o portfólio, pois ele estufou o peito e gritou aos 4 cantos do fórum que ele trabalha com games e que isso era prova cabal de que estava certo. Quero ver. Posso?[/quote]
ZZZzzz…zzzZZZzzz…
[quote=Luiz Augusto Prado][quote=Luiz Augusto Prado]
Quanto mais saber… melhor. Pra qualquer caso. Com isso também concordo.
É claro que a forma como o produto ou serviço oferecido deve funcionar vai refletir no software desenvolvido. A abstração do produto ou serviço deve corresponder com as abstrações do funcionamento dos softwares. O arquiteto de software é quem deve estar capacitado à fazer estas correlações e é o responsável por decidir como e o que seria melhor utilizar. Muitas vezes, quem desenvolve, não tem a visão do todo (negócio), mas é capaz de executar as tarefas que lhe foram delegadas. Por que o desgosto com isso? Isso vai ocorrer sempre porque as empresas visam economia. Então, por que contratar Analista Sênior pra fazer o trabalho de Júnior sendo que podemos alocar a concentração dos sêniores por um preço maior em gargalos mais genéricos e impactantes e alocar vários júniores por preços menores para trabalhos mais localizados e de menores riscos?
Os motivos de existir cargos como por exemplo de analista de requisitos, desenvolvedores de softwares… é para que a transferência das demandas sejam filtradas e delegadas à pessoas capacitadas da empresa (toda a engrenagem pode ser encaixada). Juniores só viram seniores com tempo de experiência. Erros vão ocorrer. Se o resultado não foi o esperado, a culpa não é das técnicas ou frameworks e sim de quem as escolheu.
Se vc passa uma tarefa para um pedreiro construir sua casa, vc iria à construção somente de 4 em 4 meses pra ver como tá ficando a obra?
Atenção deve ser constante. Não existe bala de prata.
Frameworks e até técnicas vc mesmo pode criar.
[/quote]
[quote=Clu]
Sério, todos esses sênior, júnior e equilíbrio… por um momento achei que estivesse falando de uma reunião de família na yoga.[/quote]
fonte do balão:
KKKKKK! ri muito desse Darth Vader! Não podia deixar essa passar. Up!