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

Recentemente, participei de uma palestra proferida por Greg Wilson (cientista-chefe de carpintaria de software). Do resumo:

A idéia de que reivindicações sobre práticas de desenvolvimento de software devem se basear em evidências ainda é estranha para os desenvolvedores de software, mas isso finalmente está começando a mudar: qualquer acadêmico que afirme que determinada ferramenta ou prática torna o desenvolvimento de software mais rápido, mais barato ou mais confiável agora espera apoiar essa afirmação com algum tipo de estudo empírico.

No geral, a palestra foi muito informativa e me deixou pensando profundamente sobre minha abordagem ao desenvolvimento. Em particular, agora me pego procurando 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 verificar mais tarde.

Em outras palavras, eu estava sendo ingênuo .

Aqui está um exemplo retirado da palestra:

"Se mais de 25% do código precisar de refatoração, é mais rápido reescrevê-lo".

Parece plausível, mas é verdade? Onde o estudo está 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 de ninguém, a menos que você o tenha derivado dos primeiros princípios. Dessa maneira está a loucura (ou talvez a matemática ;-)). Porém, se alguém lhe responder com uma afirmação do tipo "Ei, fazendo isso em [escolher linguagem do momento], poderemos aumentar a produtividade em [escolha múltipla de 10]%". aceite, ou você vai pedir evidências comprovadas?

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

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

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

O problema com esse tipo de afirmação é que, mesmo se você tivesse evidências empíricas apoiando a alegação, seria muito difícil determinar se o estudo que leva à evidência se aplica à sua situação atual.

Quase tudo na profissão tem uma ressalva, ou várias, de modo que toda melhoria em um local 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 recursos / 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 se dedicar a esses estudos e, portanto, têm grande probabilidade de vender algo para você, então eu diria que você deveria aplicar ainda mais rigorosamente sua própria experiência pessoal a qualquer coisa que pretenda apoiada por pesquisas empíricas.

Se alguém lhe disser "Se mais de 2% do código precisar ser refatorado, é mais rápido reescrevê-lo", você saberá que isso é falso tanto quanto se alguém lhe disser "Somente se mais de 98% do código precisar de refatoração, é mais rápido reescrevê-lo ". A localização do número real depende do que você está fazendo e a que distância do ideal está o código atual.

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

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

Não, eu publico aqui e vejo se há algum voto positivo. Prova social é melhor que nenhuma prova!

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

Quando uma classe ou método se torna tão fragmentado por correções de bugs e solicitações de mudança do cliente que se torna impossível de manter, 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 terá maior qualidade.

Esse tipo de experiência de inteligê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 ou mesmo 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 assim. Pelo contrário, a experiência é uma espécie de "sentido sentido". No mundo da refatoração, costumamos chamá-lo de "cheiro".

Por fim, uma declaração como "Se mais de 25% do código precisar ser refatorado, é mais rápido reescrevê-lo" não pode ser comprovada como funciona em todas as circunstâncias, portanto a declaração [necessária] é realmente uma maneira de informar o programador dogmático que procura forçar seus pontos de vista sobre os outros que nem sempre é "o caminho ou a estrada".

Eu acho que com qualquer coisa que você nunca sabe até tentar. Mesmo com provas para fazer backup de uma declaração, é sempre possível dobrar os fatos em benefício do seu argumento. Dito isto, você não deve tentar qualquer coisa nova que atinja 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 alguma coisa? O que você tem a ganhar? Faz sentido de um negócio em potencial? Nunca cego, exceto algo sobre fé.

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

As heurísticas são como qualquer outra coisa: elas estão sujeitas a um determinado contexto e dependem de qualquer número de suposições não declaradas, e sua utilidade pode ser muito não determinística. Tanto julgamento arbitrário entra em considerá-los úteis quanto em formulá-los em primeiro lugar.

Isso significa que eles não têm valor? Eu não diria isso.

As heurísticas são uma das abordagens que podemos adotar para resolver problemas de NP-completos e, em muitos aspectos, a engenharia de software é um problema de NP-completo.

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

Como exemplo, o livro "Code Complete" cita dezenas de estudos em cada capítulo para expressar suas opiniões, às vezes sobre assuntos aparentemente pequenos (como recuo e espaçamento ou comprimento de nome variável). Lembro-me de alguns desenvolvedores (mais jovens), a quem apresentei o livro, pensando que esse nível de detalhe e evidência era tolo. Mas, alguns meses depois, com mais experiência em codificação de produção e após algumas revisões de código, alguns desses mesmos desenvolvedores tiveram a honestidade de admitir que sim, mesmo o número de espaços no recuo importa. Bons comentários são importantes. O encapsulamento é importante. etc etc.

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

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

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. =)