BT

Sumário do Painel OOPSLA Retrospectiva sobre Não há Bala de Prata

Postado por Floyd Marinescu e Abel Avram , traduzido por Ricardo Almeida em 28 Nov 2008 |

Faz mais de 20 anos desde o Mythical Man-Month, do autor Fred Brooks, que publicou o artigo Não há Bala de Prata: Essência e Acidentes da Engenharia de Software. Em seu artigo original, Fred Brooks argumenta que não vai existir inovação no desenvolvimento de software que atingiria uma ordem de grandeza, do aumento da produtividade (a bala de prata), nos dez anos subsequentes. Brooks identifica duas categorias de complexidade no desenvolvimento de software: a essência e o acidente. A complexidade essencial do desenvolvimento de software é relacionado à especificação, a modelagem (mepeando a especificação para o software) e testes (que a modelagem atende as necessidades de negócio corretamente). A complexidade acidental se refere a dificuldades relacionadas a implementação (linguagens, tempo de execução, ferramentas, e técnicas de programação). No seu artigo, Brooks explica como as diversas inovações que tentou abordar a complexidade acidental (na época) não foram balas de prata, e concluiu que a única coisa que pode render perto de uma ordem de grandeza de melhora de produtividade são aqueles que resolvem a complexidade essencial, tais como melhoria na coleta de requisitos, prototipagem rápida, e o cultivo de boas habilidades de modelagem.

Na Conferência OOPSLA no último ano (2007), realizou um painel de discussão retrospectivo sobre No Silver Bullet incluindo o próprio Fred Brooks, Martin Fowler (que mais tarde surpreendeu a platéia aparecendo como um lobisomem), Ricardo Lopes, Aki Namioka, Linda Northrop, David Lorge Parnas, Dave Thomas, and Steven Fraser como palestrante empresário. O painel explorou as premissas de Brooks que não existe bala de prata no desenvolvimento de software. A InfoQ esteve presente no painel desde então para trazer fortemente essa importante discussão para a comunidade. A seguir tem um sumário editado, publicado com permissão, incluindo conceitos chaves do painel.

Steven Fraser abriu o painel perguntando aos presentes se eles leram o primeiro artigo quando saiu a 20 anos atrás. Três quartos dos presentes levantaram suas mãos. Steven disse à platéia que “Eu lembro que o artigo saiu no dia de minha defesa de Doutorado. Minha tese superior disse que era bom que eu não falasse nada que discordasse com Fred.” Steve continuou apresentando cada um dos palestrantes e expressando sua simpatia por Ricardo e sua família, que foram evacuados devido a um enorme incêndio florestal que atingiu a Califórnia naquela época. Em seguida Steven ofereceu para cada palestrante alguns minutos para introduzir suas visões sobre a bala de prata nos últimos 20 anos. Fred Brooks iniciou com uma recaptulação de sua idéia inicial:

Eu argumento que as dificuldades com a construção de software podem ser divididos seguindo Aristóteles, na essência, que é a estrutura conceitual do software em si, independente de qualquer realização, e os acidentes, (usando termos de Aristóteles - talvez você prefira incidências), as dificuldades que não são ocasionadas pela estrutura conceitual, mas são ocasionadas por um ou outro aspecto do processo de perceber a estrutura conceitual em sua forma executável.

Em seguida afirmo uma proposição matemática, o qual acho que é um desafio muito difícil. Ou seja, se em 1986 9 de 10 dos problemas eram acidentes, e depois diminuindo todos os acidentes a zero, não vai te dar uma melhora na ordem de grandeza. Portanto, se existe uma bala de prata - eu escolhi a palavra lobisomem, porque digo que muitos projetos começam aparentemente inocentes e simples, e depois no escuro da lua eles se transformam em monstros (e você poderia ter obtido um projeto como esse, eu tenho). Portanto, se existe algo que proporciona uma melhora na produtividade em 10 vezes, isso deve resolver a complexidade conceitual inerente e que pode significar lidar com os conceitos a um nível diferente.

Então existe um argumento. Agora o argumento pode ser contestado por diversos motivos, um é - Você poderia discordar de que é possível dividir coisas que ordenadamente estão na estrutura conceitual ou outra coisa qualquer. Um deles é, você poderia dizer “Bem, eu acredito que mais de 9/10 dos problemas restantes são acidentes”. Eu nunca vi alguém afirmando isso. Mas eu vi que a opinião foi bastante contestada. E outro ponto é, pode-se dizer que a matemática está errada; Eu gostaria de dizer que na verdade é insensato; A matemática não está errada, e você sabe que tem-se visto em várias maneiras.

Em seguida, me comprometi a tratar com o resto do artigo das várias coisas que foram apresentadas como balas de prata para matar o lobisomem e tentar explicar por que esses parecem-me lidar com acidentes e não com a essência.

Eu também fiz uma afirmação ousada. Ou seja: nenhuma técnica irá aparecer nos próximos 10 anos, que é 86 a 96, que dá 10 vezes na melhoria da produtividade ou qualquer outra coisa boa.

Um estouro de artigos veio e disse “A sim, existe uma bala de prata, e está aqui, é minha!” Quando chegou 96 e eu estava escrevendo uma nova edição do The Mythical Man-Mont e fiz um capítulo que, ainda não houve uma melhora de 10 vezes na produtividade na engenharia de software. Gostaria de perguntar se houve alguma única técnica que tem feito desde então. Se existe, eu concordaria que é a programação orientada a objetos, por uma questão de fato.

O próximo palestrante foi Dave Parnas, o qual escreveu o primeiro trabalho na modelagem de sistemas com módulos baseado em critérios de “escondendo informação” e quem tem sido um forte defensor de uma engenharia de software a ser tratada (e acreditada) , como uma disciplina (semelhante a engenharia civil, engenharia mecânica, etc).

Dave rapidamente declarou que não existe bala de prata para software e examinou por que essa questão ainda é quente 20 anos depois. Dave forneceu três razões:

  1. Pessoas tem uma “tendência muito natural de olhar para respostas fáceis em questões difíceis, desenhar software é difícil e sempre será difícil”
  2. Novas tecnologias são muitas vezes sobre-sensacionalistas: “eles tem que se taxar como uma bala de prata porque senão as pessoas não irão ouvir”
  3. O desejo das pessoas de procurar melhores ferramentas em vez de “aprender a realidade do marcado.” Dave usou a metáfora: “existe um velho ditado: ‘o pobre operário culpa sua ferramenta’ - pessoas são pobre operárias , e creio que a maioria dos programadores são operários” Dave também disse que pessoas estão procurando a bala de prata para evitar a aprendizagem do marcado.

Dave contestou a noção de que muitos dos progressos foram feitos em engenharia de software, em vez de serem atribuídos grande parte ao nosso adiantamento ao hardware. Dave Parnas concluiu: “existe algumas coisas que eu chamo de “levar balas”, a velha, simples e ordinária bala normal. Para usar essas coisas precisa ser disciplinado, trabalhar duro e, de muito treino para usá-los. Minha questão é porque realmente nós não usamos o método de levar balas? ”

Linda Northrop elogiou o artigo de Fred e ela mencionou alguma de suas principais frases: “engenharia de software envolve mais do que programação...a coisa mais difícil sobre construir software é entender o que dizer, não como dizer.” Linda concorda que não existe bala de prata e que, quando sua equipe se focou na complexidade essencial, “os resultados foram espetaculares.”

Linda citou Kristen Nygaard (co-inventor da orientação a objeto) dizendo que Simula (a primeira linguagem OO) foi sobre modelagem. Em 2001 Nygaard disse (na interpretação de Linda) que nós tivemos “a assência perdida, nós não pensamos sobre modelagem, ficamos todos excitados sobre linguagens e ferramentas”. “Em sua mente”, Linda adicionou, “que não tem nada a ver com a essência da orientação a objeto.”

Linda concluiu:

A camada entre os desenvolvedores e a que temos, chamado de usuários, inapropriadamente no meu modo de ver, e nossas inovações acidentais, ajuda pouco. Para lutar com futuros lobisomens nós ainda necessitamos de bons modeladores, e acho que nós ainda temos um número muito pequeno deles, e ainda necessitaremos cultivar a atmosfera de trabalho árduo mas também uma perspectiva de uma sub-disciplina que nos leva a estar desconfortavelmente fora do nosso mundo de codificação. Nosso mundo o qual, se eu pudesse apenas emprestar uma frase para a apresentação dessa manhã, “o empurrão da tecnologia”. Eu penso que a razão de termos o empurrão da tecnologia é porque não fazemos o trabalho difícil de entender as necessidades de quem estamos tentando resolver.

Aki Namioka da Cisco System foi o próximo e sugeriu que temos visto bons progressos nos últimos anos porque mais e mais pessoas são agora capazes de criar aplicações úteis (semelhante a websites) sem ser programadores, “nós temos na verdade criado as ferramentas que fazem da programação não apenas algo que engenharias sofisticadas estão produzindo mas muitas pessoas....”

Dave Tomas, uma figura chave por trás do IBM Visual Age para Smalltalk e Eclipse IDE, considerou o artigo do Brooks um desafio para nós continuarmos tentando resolver a produtividade; entretanto Dave nomeou o estado atual da arte no desenvolvimento de software (especialmente middleware) um desastre gratuito devido a uma catástrofe excessivamente rápida de mudanças na API e frameworks o qual criaram softwares imaturos e também muita dificuldade em criar equipes médias para monitorar e manter-se atualizados. Dave alegou que a maioria dos sistemas empresariais de hoje são apenas aplicações CRUD: “No final essas pessoas estão tentando fazer coisas que são bastante simples, e se eles estivessem trabalhando em um mainframe usando um 4GL, eles realmente terias as coisas feitas”

Dave Thomas quis expressar seu sentimento sobre as universidades de hoje sendo mais concentradas com certificação do que com a competência, “então nós temos certificados de incompetência”. Dave lamentou que novos graduados não são ensinados sobre um amplo espectro da diversidade computacional...então agora qualquer hora sai uma nova linguagem e, essas pessoas pobres acompanham a bateria porque eles não tem o básico de conceitos simples que permitam compreender essas coisas.”

Dave Thomas sugeriu que lições de engenharia e manufatura são coisas que ajudam grandes projetos a escalar, mais até do que práticas ágeis; entretanto, Dave chamou de “uma descoberta” o fato dos desenvolvedores de hoje pensarem que é importante testar.

Dave Thomas concluiu que ele tem visto “verdadeiros sucessos” em nichos, citando domínios específicos altamente especializados e linguagens especializadas de aplicações em reservas aéreas e fundos hedge; no entanto, Dave advertiu que a habilidades de desenvolvedores necessárias são “muito, muito altas” e não pode ser “propagado em massas”.

Ricardo Lopes foi o próximo e deu um lado espiritual de dissertação posicionando duas constantes na história da humanidade: medo e a necessidade de otimizar e melhorar. Ricardo posicionou o medo nesse contexto como o medo de lobisomem, o qual personifica falha em software. Ricardo reclamou que existe uma bala de prata e pode vir de dois lugares:

  1. “Vamos em frente abraçar a complexidade ao invés de fugir dela porque ela é a realidade. Na minha experiência, a tentativa de evitar a complexidade por medo de fracasso leva na verdade ao aumento na complexidade acidental o qual garante o fracasso.”
  2. “Toda vez que você procura se esforçar para a excelência que está dentro de você tanto profissional quanto pessoal, quando você compartilha com seus pares, você é a bala de prata. Você faz o que for preciso para obter essas melhorias da magnitude em qualquer coisa que você esteja fazendo.”

Ricardo continua sua mensagem:

Quando você pensa em se melhorar e puxar os outros ao seu redor, se preocupando sobre o crescimento deles tanto pessoal quanto profissional, você não vê o aumento na produtividade? A colaboração de toda a arte é sobre a personificação do compartilhamento da experiência que você está passando. Isso realmente lhe dará uma ordem de grandeza.

Ricardo concluiu que “a bala de prata que você está buscando está dentro de você.” Proporcionando um exemplo pessoal, Ricardo salientou que, em respeito do número de vidas que NÃO foram perdidas nos incêndios florestais na Califórnia, comparou a 100 anos atrás. Era a prova de que: “Nós, como uma civilização, temos feito várias melhorias de ordens de grandeza daquilo que somos capazes, porque somos balas de prata”.

Martin Fowler foi o último dos palestrantes, e começou a discutindo o quanto foi importante e influente o artigo de Brooks em sua vida. De repente, Martin começou a gritar incontroladamente enquanto agarrava seu pescoço até que caiu fora da área de visão por trás da mesa. Eu lancei meu notebook para o lado e pulei, pretendendo ir e tentar ajudar quando de repende Martin reapareceu vestindo um máscara de lobisomem muito assustadora. O lobisomem é a personificação da falha nos projetos de software, como Brooks descreveu no começo do artigo. O trecho seguinte não pode ser apreciado, portanto, está abaixo o discurso introdutório completo de Martin:

Eu gostaria de fazer algumas considerações sobre a razão por eu ter sobrevivido tão eficientemente. Eu concordo com o Sr. Brooks que a orientação a objetos é muito perigoso e uma má idéia, mas eu tenho conseguido superar isso sem muita dificuldade. Certamente existe muitas boas idéias na orientação a objetos, mas a coisa boa é, ninguém realmente usa isso.

Na OOPSLA, sim, tem se falado muito sobre objetos, mas se sair para o resto do mundo - ninguém realmente usa isso! Eles usam a linguagem, mas não tem idéia sobre as idéias. Você pode pensar que tem sucedido com os objetos, mas tem um longo caminho para me derrotar nessa linha.

E tenho outras armas à minha disposição! Eu amo sistemas de concorrência multicore. Vocês vão sofrer muito com problemas de threads e condições de corrida. Vou ter muita diversão nos próximos anos.

Aqueles são obviamente parte dos acidentes, eles não são realmente perigosos para mim. As verdadeiras questões são aqueles que atacam a essência, e mesmo assim eu tenho conseguido sobreviver.

Uma das coisas mais perigosas sem dúvida é comprar mais do que construir: o uso da pre-construção de componentes e estruturas. Essa é uma grande teoria, mas tem um ponto fraco - somente vai ajudar se as bibliotecas forem todas boas, e eu tenho sido muito bom em ver pessoas que constroem bibliotecas bastante ruins.

Outro ataque chave na essência conceitual foi o crescimento de bons modeladores. Concordo com meu amigo antigo aqui, que esse é um dos ataques mais promissores e preocupantes, muitos de vocês compreenderam isso. Mas felizmente lá fora ninguém entendeu realmente isso.

Pessoas querem que software sejam fáceis de fazer, eles querem que software seja trivial e existe muitas pessoas que estão preparadas para encorajar isso, e como resultado eles não levam a sério o desenvolvimento de software, e a invisibilidade do desenvolvimento de software ajuda ainda mais, porque pessoas não entenderam como isso é difícil realmente, e o erro de julgamento significa que as pessoas não tem dado valor o suficiente em grandes modelagens.

O desafio não é convencer vocês mesmos que necesita-se de bons modeladores porque vocês já sabe disso. O desafio é tornar mais visível para a população mais vasta, e até agora vocês tem sido completamente patéticos nisso.

Depois, o ponto final, com as duas partes restantes dos ataques contra a essência conceitual de Fred Brooks, o qual eu as agrupo, e tem tudo a ver com pessoas vão sobre construção de software: o processo e o incentivo rumo à prototipagem rápida e desenvolvimento incremental.

Uma das grandes surpresas para mim nos últimos 30 anos é o quanto eu tenho adorado processos em cascatas. É notável, vocês humanos, verem e pensarem que com praticamente nenhuma informação no início do projeto vocês podem mapear exatamente o que vai acontecer, estimar custos baixos, comprometer-se a todos os tipos de planos irrealistas. E depois você admira porque é que eu sempre apareço. Essa ilusão de controle, a idéia que em praticamente qualquer dado vocês pode permitir fazer essas grandes predições, essa loucura é uma das minhas maiores forças. É por isso claro, o porque de levar balas não me machuca.

Umas das coisas que mais me ajudam é o grande desejo da bala de prata. As pessoas tem gastado tanto tempo tentando criar a bala de prata, e tanto tempo tentando vender a bala de prata, que eles criam muito mais trabalho para eles mesmos. A bala de prata em si, é a grande aliada da mina. Obrigado.

Foto de Amir Kirsh

O palestrante empresário, Steven Fraser, abriu a palavra para perguntas da platéia.

O primeiro a falar na platéia foi Bertrand Meyer o qual mencionou o fato que, de acordo com sua experiência, muitas pessoas, especialmente gerentes, rejeitam novas idéias dos anos 80 e 90 como OOP, o qual na verdade são antigas, porquê eles não acreditam que novas tecnologias que lhes é proposto teria um sério impacto sobre o desenvolvimento, e eles usam como argumento o artigo Não Existe Bala de Prata.

Fred respondeu reafirmando que qualquer melhora tecnológica que lida com dificuldades acidentais não vão resolver o problema real, mesmo que isso traga um aumento de 2/3 na produtividade.

Linda disse que ela não é interessada em marqueteiros o qual querem vender sua bala de prata, a menos que eles ofereçam a solução da necessidade atual que nós temos. Em seguida ela descordou parcialmente com o que Ricardo disse anteriormente:

Quando ele falou sobre as razões para a bala de prata, ele pareceu ter dado todas as nobre razões pelas quais temos balas de prata, que nós temos medo de complexidade e que nós queremos aumentar a produtividade e essa natureza perigosa de complexidade nos direciona a ter esse medo. Eu diria que existe uma razão pela qual estamos procurando balas de prata, e isso é uma ignorância.

John Roberts (Qualcomm) perguntou se uma equipe formada pelos maiores desenvolvedores de todas organizações se tornaria a bala de prata ou uma receita para o desastre.

Ricardo apoiou a idéia de ter uma equipe com grandes pessoas sem prometer a bala de prata:

É muito importante ter o melhor de vocês juntos, porque eles não são as únicas pessoas que levam vocês pra frente e a enfrentar mais complexidade essencial, e não ser presa do medo. Você também está provendo oportunidade para outros aprenderem e isso é como nós nos potencializarmos mutuamente, e é como a civilização se transforma e eu sei disso hoje.

No mesmo tópico, Dave Thomas adicionou:

Então se você é jovem e você quer descobrir como ser bom, encontre a pessoa boa realmente o qual você possa trabalhar, porque você aprende com pessoas que são melhores.

Dave Parnas falou sobre o assunto das questões anteriores dizendo que alguém que quer vender-lhe alguns dias em um curso está na verdade vendendo a bala de prata, e eles encontrarão compradores interessados, inferindo que ele não estava interessado. Uma verdade é, levar bala é educação, e isso leva um tempo de aprendizagem e treino.

O lobisomem não teria como se ajudar, mas rosnou:

Sim, sempre é muito útil pra mim essa idéia que boas pessoas não podem colaborarem juntas em equipes. Eu sempre pude ver algumas dúvidas dizendo que nunca pode ter boas pessoas juntas, porque não existe o suficiente deles. Por isso, é claro, parou de ter boas pessoas trabalhando juntas. Se vocês não tentarem ter boas pessoas trabalhando juntas, vocês nunca terão sucesso - de modo que será muito fácil ter caminho para eu voltar.

Então falo sobre a dificuldade de ter boas pessoas colaborando efetivamente e dificuldade de trabalhar bem porque as pessoas não tentam ajudar o suficiente as pessoas que trabalham juntas a elas. Eles não entendem o quanto nós humanos necessitamos uns dos outros, o quão trabalhoso é ter uma equipe de pessoas que colaboram juntas. Novamente pessoas querem coisas fáceis e simples de seguir, em seguida, é claro, eu posso sempre usar o processo mais peso pesado, que é uma técnica muito boa e novamente surgir vínculo sobre criar coisas novas.

Pegue a comunidade ágil, por exemplo, eu vejo eles tão bonitos, eles falam sobre como se livrar do processo peso pesado, então eles esquecem que existe um grupo inteiro de pessoas agora que não entendem realmente do que se trata agilidade. Eles focam em sintaxe e não em semântica, e eles estão minando completamente tudo que a comunidade está fazendo, e isso é muito satisfatório para mim.

Joe Yoder, o palestrante do OOPSLA sobre “A cadeira do refactoring”, adicionou que pessoas boas, bons modeladores, colaboração, requisitos, tudo colocado junto, não poderia ser a bala de prata desejada, mas talvez ajude a lutar contra o lobisomem, e entregar software no prazo.

Dave Thomas concordou com Joe sobre ter a mistura certa de pessoas e técnicas, mas adicionou, baseado em sua experiência, que nós encontramos uma boa mistura acidentalmente, que nós não sabemos na verdade como fazer isso repentinamente para criar essa equipe a qualquer hora, em qualquer lugar que desejarmos.

Fred recomendou a leituda dos livros Peopleware e The Carolina Way para aqueles interessados em conhecimento e crescimento de bons times.

Linda falou sobre a diferença entre gerenciar e liderar. Ela também insistiu na liderança de coaches em fazer isso, construindo carater e liderança.

O lobisomem fez a platéia cair na risada:

Peopleware é um dos livros mais e mais perigosos lá fora. Felizmente, é difícil de trabalhar para gerenciar um time e focar na iteração das pessoas. É muito mais fácil brincar com Microsoft Project. Toda vez que alguém cria um PERT chart em um Gant Chart, eu como um gatinho extra.

Os palestrantes foram então perguntados como a produtividade pode ser medida para verificar se houve um aumento de 10 vezes. O lobisomem foi rápido em responder:

Essa é evidentemente uma das melhores coisas que tenho à minha disposição. Você não pode avaliar seu resultado, não é possível medir a produtividade, de maneira nenhuma você pode executar experimentos sensatos para descobrir se uma técnica é melhor do que outra... As vezes é simplesmente muito fácil pra mim.

Ricardo concordou com o lobisomem e abrangeu alguns dos métodos utilitários para medir a produtividade, concluindo que é difícil de fazer isso.

Dace Parnas também sustentou a mesma opinião sobre a medição de produtividade, e deu o seguinte exemplo: “Se você der o mesmo problema para duas pessoas, uma delas em dois dias produz 2000 linhas de código que resolve o trabalho e outra em 3 dias produz 500 linhas de código que resolve o trabalho. Qual trabalho você quer, especialmente se você precisar dar manutenção no código?”

Alguém da platéia perguntou quando é que podemos esperar um ambiente de desenvolvimento apropriado que permita desenvolvedores focar na essência e não nos acidentes?

O lobisomem foi claro no que está fazendo para impedir que isso aconteça:

A maior dificuldade no desenvolvimento de software é a comunicação entre pessoas que escrevem software e pessoas que querem que o software sejam escritos. O ataque conceitual, a essência dos problemas, concentra-se em um grande volume para tentar melhorar essa comunicação. O problema de fazer isso , é claro, é que é difícil que essa comunicação flua. Alguns das pessoas de negócio não querem falar com pessoas de software, e felizmente as pessoas de software estão sem esperança quando se trata de iteração social, eles não podem conversar com pessoas de negócio.

A principal coisa que faço é criar muitas barreiras possíveis entre pessoas de negócio e pessoas de software: tentar sufocar a comunicação, fazer eles conversarem por documentos, colocar eles em diferentes departamentos. Então o que acontece (acho que um dos sintomas desta situação é muito confortável para mim) é que pessoas de software ficam frustrados pois primeiramente perdem o interesse no problema do negócio, e nesse caso eu tenho realmente ganho. E eles tornam ainda pior porque sentem que não podem focar no problema do negócio, então eles começam focando no que eles sabem a respeito - que é material de infra-estrutura. E eles constroem infra-estrutura porque não podem pensar em mais nada.

Brian Foote (Industrial Logic) afirmou que o mundo está correndo em maus códigos, e perguntou por que nós tentamos ser mais eficientes em escrever maus códigos do que focar em fazer maus códigos melhores.

Ricardo, em seu estilo habitual, mencionou que a humanidade nunca fez algo perfeito e aprendeu a aceitar deficiências, e será igual com software. Só precisamos nos livrar de códigos cataclísmicos, e tentar evitar escrever códigos ruins, muito bons sendo aceitáveis.

Dave Parnas teve uma abordagem diferente para essa questão:

O que é bom para os desenvolvedores não é provavelmente bom para o mundo. Tenho conhecido muitas pessoas que fizeram seus nomes como gênios em sua empresa ou departamento por ter escrito algo tão complexo que ninguém mais poderá consertá-lo.

Outro ouvinte da audiência perguntou se existe algo que podemos fazer para terminar a revolução OOP.

Dave Parnas respondeu rapidamente que ele dará uma apresentação mais tarde que vai resolver a questão específica, mas complementou “você não vai gostar da resposta”

Fred disse que “a melhor maneira de fazer um sistema ser útil para a maioria das aplicações é fazer realmente útil para um, e depois generalizá-lo”

Dave Thomas falou sobre frameworks de software:

A melhor maneira de ter componentes de software é as pessoas pararem de construir frameworks que violam a emcapsulação e criam complexidades. Um dos maiores erros, creio, é incentivar as pessoas na construção de frameworks e usar eles. Frameworks são a melhor maneira de fazer uso de algo inacabado e ainda não polido profissionalmente.

Aproximando do final da sessão, Steven convidou os palestrantes a concluir, em ordem reversa, sendo o lobisomem o primeiro a falar:

É verdade que o desenvolvimento de software teve grande progresso nos últimos 20 anos, mas para ser honesto, não estou prejudicado pelo grande avanço, porque minha essência reside da minha aparência inesperada...Porque humanos tem essa maravilhosa otimização quando se trata de software. Eles pensam que sempre vai ser fácil. E mesmo que você seja mais produtivo, você ainda vai superestimar suas capacidades e é onde vem a minha força. É sua incapacidade de ver o mundo real, que é minha maior força.

Ricardo foi otimista sobre nossa habilidade de enfrentar a complexidade:

Nós temos abraçado uma complexidade crescente de década a década, de geração a geração, e iremos continuar a fazê-lo, e os lobisomens vão ficar maiores e mais famintos, mas isso vai passar.

Dave Thomas agradeceu Fred pelo “grande desafio” oferecido, e concluiu: “É importante ter meta, é importante ter a visão, não conseguir realmente não interessa se você fazer a jornada.”

Aki apontou para que nossa busca pela bala de prata nos levou a criar sistemas de software que são usados por pessoas todos os dias.

Linda expressou sua apreciação por estar no mesmo painél com Dr. Brooks e Dr. Parnas, e compartilhou uma importante lição aprendida em sua vida: “foco na essência e não no acidente”.

Dave Parnas tomou uma posição e defendeu o processo de desenvolvimento de software em cascata considerado que o processo foi criticado injustamente. Ele também defendeu sistemas mais simples pois os complexos não são as melhores soluções de nossos problemas. Ele finalizou dizendo que nós não deveríamos procurar respostas fáceis para questões complexas.

Fred fez a seguinte observação: “Eu não conheço nenhum campo da engenharia onde as pessoas fazem menos estudos de outros trabalhos, onde eles fazer menos estudos de precedentes, onde eles fazem menos estudos de modelos clássicos. Eu penso que é algo muito perigoso.”

Steven Fraser fechou a sessão declarando: “Não existe bala de prata”

Sobre OOPSLA

OOPSLA, a conferência original dedicada à programação orientada a objetos, tem englobado paradigmas e práticas abordando desafios atuais de software, tais como produtividade de programadores, segurança e confiabilidade, sistemas ultra-grandes e envolvendo plataformas de hardware. Na OOPSLA, você pode encontrar informações sobre os últimos desenvolvimentos de pesquisas e da indústria, participar de workshop, melhorar suas habilidades em tutoriais hands-on, ou juntar outras sessões que irão alimentar sua mente de maneira criativa e divertida.

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão
Comentários da comunidade

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

Dê sua opinião

Conteúdo educacional

Feedback geral
Bugs
Publicidade
Editorial
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2014 C4Media Inc.
Política de privacidade
BT