Se alguém lhe oferece uma declaração não verificada sobre as práticas de desenvolvimento de software, você responde com “citação necessária”? [fechadas]

14

Recentemente, assisti a uma palestra dada por Greg Wilson (Cientista Chefe de Carpintaria de Software). Do resumo:

The idea that claims about software development practices should be based on evidence is still foreign to software developers, but this is finally starting to change: any academic who claims that a particular tool or practice makes software development faster, cheaper, or more reliable is now expected to back up that claim with some sort of empirical study.

No geral, a palestra foi muito informativa e me deixou pensando profundamente sobre a minha abordagem ao desenvolvimento. Em particular, agora me vejo procurando por citações para fazer backup de muitas declarações. Anteriormente, eu tinha adquirido o hábito de simplesmente repetir as verdades oferecidas, talvez com uma nota mental para ir verificar isso mais tarde.

Falando francamente, eu estava sendo ingênuo .

Aqui está um exemplo da palestra:

"If more than 25% of the code needs refactoring, it's quicker to rewrite it".

Parece plausível, mas é verdade? Onde está o estudo apoiando isso? É verdade para todos os idiomas? E assim por diante.

OK, é bem possível levar isso ao extremo e não acreditar em nada por ninguém, a menos que você o tenha tirado de primeiros princípios. Esse caminho é uma loucura (ou talvez matemática ;-)). Mas, se alguém chega até você com uma declaração ao longo do linhas de "Ei, fazendo isso em [escolha a linguagem do momento], poderemos aumentar a produtividade [escolha vários de 10]%" você está inclinado a apenas aceitá-lo, ou você vai pedir provas comprovadas?

Se é o último (e espero que seja) então

  1. aonde você iria para encontrar essa evidência?
  2. quão rigoroso você seria?

Em suma, se alguém lhe oferecer uma declaração não confirmada, você responderá com "citação necessária"?

    
por Gary Rowe 13.12.2010 / 19:11
fonte

7 respostas

3

O problema com este tipo de declarações é que, mesmo se você tivesse evidência empírica apoiando a afirmação, seria muito difícil determinar se o estudo que levou à evidência se aplicava à sua situação atual.

Quase tudo na profissão tem uma ressalva, ou várias, de modo que cada melhoria em um lugar tem a probabilidade de ser um desserviço em outro lugar.

As pessoas nas trincheiras sabem a diferença através da experiência e geralmente não têm financiamento / tempo / recursos para tentar provar isso através de um estudo científico.

As pessoas que tentam provar isso através de um estudo científico, obviamente, têm recursos para dedicar a tais estudos e, portanto, são altamente propensos a vender algo para você, então eu diria que você deveria aplicar sua experiência pessoal de forma ainda mais rigorosa a qualquer coisa. que alega ser apoiado por pesquisas empíricas.

Se alguém lhe disser "Se mais de 2% do código precisar de refatoração, é mais rápido reescrevê-lo" você saberia que isso é falso, como se alguém lhe dissesse "Somente se mais de 98% do código precisar refatoração, é mais rápido reescrevê-lo ". Onde o número real é depende do que você está fazendo e quão longe do ideal é o código atual.

A ideia de que, depois de um certo ponto, é mais fácil fazer um refatorador nuclear é obviamente verdadeira em muitos casos, mas a porcentagem real é mais um exemplo que você precisa considerar através das lentes da sua (equipe) experiência e situação atual.

    
por 13.12.2010 / 19:38
fonte
8
If someone offers you an unverified statement regarding software development practices, do you respond with “citation needed”?

Não, eu coloco aqui e vejo se há algum upvotes. A prova social é melhor que nenhuma prova!

    
por 13.12.2010 / 19:52
fonte
4

Muitos desenvolvedores baseiam suas decisões momento a momento na experiência nas trincheiras que trabalham com código e nos clientes que esse código serve.

Quando uma classe ou método se tornou tão fragmentado por correções de bugs e solicitações de mudança do cliente que se tornou inatingível, um desenvolvedor às vezes toma a decisão de reescrevê-lo em vez de refatorar, sob a teoria de que ele economizará tempo e esforço a longo prazo, porque o código resultante será de maior qualidade.

Esse tipo de inteligência de experiência é o que os departamentos de RH chamam de "capital humano". É uma das coisas que torna os desenvolvedores experientes valiosos e uma das razões pelas quais as boas empresas fazem coisas para tentar preservar a longevidade de seu pessoal.

Não parece justo nem prático pedir a desenvolvedores experientes que apresentem um estudo e dados empíricos como prova de que suas técnicas são válidas. A experiência não funciona dessa maneira. Pelo contrário, a experiência é algo como um "sentido sentido". No mundo da refatoração, muitas vezes chamamos de "cheiro".

Em última análise, uma declaração como "Se mais de 25% do código precisar de refatoração, é mais rápido reescrevê-lo" não pode ser comprovado que funciona em todas as circunstâncias, por isso a declaração é realmente uma maneira de informar o programador dogmático que procura forçar seus pontos de vista sobre os outros que nem sempre é "o seu caminho ou a estrada".

    
por 13.12.2010 / 19:28
fonte
4

Eu penso com qualquer coisa que você nunca sabe até que você tente. Mesmo com a prova para fazer backup de uma declaração, é sempre possível dobrar os fatos para o benefício do seu ponto. Dito isto, você não deve tentar cada coisa nova que atinge as interwebs. Faça o seu melhor julgamento. Lembre-se, se algo parece bom demais para ser verdade, provavelmente é. Sempre se pergunte por que você precisa adotar algo? O que você tem a ganhar? Faz sentido a partir de uma empresa prospectiva? Nunca cegado, exceto algo sobre fé.

    
por 13.12.2010 / 19:58
fonte
3

O exemplo da palestra é uma heurística, uma regra geral e nada mais. Isso deveria ser implicitamente óbvio.

Heurísticas são como qualquer outra coisa: elas estão sujeitas a um certo contexto e dependem de qualquer número de suposições não declaradas, e sua utilidade pode ser muito não-determinística. Tanto juízo arbitrário vai para achá-los úteis como é para formulá-los em primeiro lugar.

Isso significa que eles não valem nada? Eu não diria nada.

A heurística é uma das abordagens que podemos adotar para abordar problemas NP-completos e, em muitos aspectos, a engenharia de software é em si um problema NP-completo.

    
por 13.12.2010 / 20:21
fonte
1

Depende. :) Quando a declaração de alguém contradiz a experiência repetida, refletida e verificada pessoalmente, então sim, eu gostaria de ver algum tipo de referência de um estudo. Por outro lado, se alguém ecoa uma ideia que você viu e viveu muitas vezes, não há muita reação provocada (não significa que a idéia seja infalível).

Como exemplo, o livro "Código Completo" cita dezenas de estudos em cada capítulo para apresentar seus pontos, às vezes sobre assuntos aparentemente pequenos (como recuo e espaçamento, ou tamanho de nome de variável). Lembro-me de alguns desenvolvedores (mais jovens) que eu apresentei para pensar que esse nível de detalhe e evidência era bobo. Mas alguns meses depois, com mais experiência em codificação de produção e depois de algumas revisões de código, alguns desses desenvolvedores tiveram a honestidade de admitir que sim, até mesmo o número de espaços em recuo é importante. Bons comentários são importantes. Questões de encapsulamento. etc etc.

Por outro lado, quando um fornecedor afirma que um novo IDE é 50% mais produtivo, minha primeira reação é touro $% ^ &!

    
por 13.12.2010 / 19:38
fonte
1

Isso não é algo que depende de muitas variáveis intangíveis (variáveis que não têm como ser medido cientificamente)?

Na minha opinião, eles estão falando sobre um método empírico para medir emoções. Algo que nem mesmo Spock poderia realizar. =)

    
por 13.12.2010 / 19:58
fonte