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]


14

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"?


2
Em quantos campos, fora da ciência, as pessoas exigem evidências empíricas? Na minha observação, não tanto quanto eu gostaria.
David Thornley

1
Que tal alguns comentários sobre os votos próximos? "Muito localizado" e "Não é uma pergunta real" não são realmente auto-explicativos neste contexto.
Inaimathi

1
Sim, eu também gostaria de saber o raciocínio por trás das votações próximas.
Robert Harvey

@ Robert Obrigado pela edição. Muito menos inflamatório na reflexão.
Gary Rowe

1
Ótima pergunta. Eu vi o Prof. Wilson falar na CUSEC no ano passado e também foi muito influenciado pelo que ele tinha a dizer. A melhor parte foi quando um aluno o desafiou a citar sua alegação de que as reivindicações deveriam ser citadas, e ele o fez sem perder o ritmo.
Matthew Leia

Respostas:


3

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.


+1 para uma análise completa da instrução de exemplo. Você realmente acha que todas as pesquisas científicas têm um ângulo comercial que precisa ser explorado? (Perdoe minha ingenuidade, mas eu estou realmente curioso sobre este)
Gary Rowe

@ Gary: Todas as coisas sendo perfeitas não, mas é muito difícil, se não impossível, determinar o viés de um estudo a partir do exterior. Duplamente assim quando não há acordado métricas que cobrem toda a situação
Bill

8
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!


2
Você pode chegar a algum lugar com esse modelo, mas estremeço ao pensar em um artigo citando programmers.SE como fonte.
Inaimathi

@Inaimathi: é pelo menos tão confiável quanto a Wikipedia, se não mais!
Steven A. Lowe

+1 para procurar provas - sempre bons conselhos. Quantas votações antes de você acreditar? ;-)
Gary Rowe

1
@ Gary: em SO, dez. neste site, vinte. na meta, uma centena - a menos que envolva unicórnios e waffles, caso em que deve ser verdade
Steven A. Lowe

Amo a referência de unicórnios - deve me dar um deles #
Gary Rowe

4

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".


Ahh, boa antiga capital humano e de recursos humanos, essas frases maravilhosas individuais que promovem a desumanização em curso de trabalhadores em todos os lugares ...
Aaronaught

@Aaronaught: A execução de um conceito às vezes pode ficar aquém do elevado vocabulário usado para descrevê-lo. É por isso que as pessoas céticas às vezes pedem provas.
Robert Harvey

Não seria bom que a execução desses conceitos em particular não fosse alcançada?
Aaronaught 13/12/10

+1 para um bom uso do "carece de fontes?" Defesa contra um programador dogmática - muito útil
Gary Rowe

4

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é.


+1 para perguntar "por que você precisa adotar algo". Às vezes, afastar-se da vanguarda é uma coisa boa.
Gary Rowe

Acho que com muita freqüência os desenvolvedores são apanhados na próxima melhor coisa sem analisá-la e entender como isso poderia beneficiá-los e impedi-los. Vi situações em que as organizações adotam algo como Asp.Net MVC sobre Asp.Net Webforms, mas não adotam TDD.
Carlosfocker

3

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.


Bons pontos. =)
Pablo

1

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 $% ^ &!


1
Depende, mas mesmo os exemplos completos de código dependem da sua situação. Por exemplo: Se você tem um formatador de análise e sua ferramenta diff ignora os espaços em branco, o argumento de indentação se torna bastante trivial
Bill

1
+1 no exemplo de código completo (também válido para o Rapid Development do mesmo autor, Steve McConnell).
Gary Rowe

@ Bill É interessante que, à medida que a tecnologia melhora, os problemas que as provas exigidas anteriormente desaparecem. Gostaria de saber se isso é um efeito que reduz nossa necessidade de pedir provas.
Gary Rowe

1
@gary Não acho que isso (no sentido geral) seja um caso de melhoria tanto quanto de variação. Os exemplos de código completo estão definitivamente se referindo a um conjunto de ferramentas específico em um momento específico, portanto são os dois, mas o tipo "quando refatorar" tem muito mais a ver com a situação do que com a tecnologia. Pense em um software crítico de segurança em um veículo versus uma solução de processamento de dados. Os requisitos de teste serão muito mais altos no sistema de segurança; portanto, o ponto de refatoração sempre será muito maior antes que haja um ganho líquido.
Bill

1

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


1
+1 para uma visão interessante. Colocando o exemplo (intencionalmente) de lado, se alguém lhe dissesse que o Rails é uma estrutura melhor que o SpringMVC, como você determinaria sua validade?
Gary Rowe

Como Benjamin Graham afirma em seu livro clássico sobre investimento ("Análise de segurança"), essas ferramentas (de investimento) deveriam ser medidas em dois aspectos diferentes, mas solitários: O qualitativo (intangível, sentimentos) e o quantitativo (números reais, matemática) , computação, lógica).
Pablo

O Quantitativo é o que você está medindo através de um método científico. O Qualitativo é o que você mede através do seu próprio instinto. Não é possível julgar emoção versus emoção sem ter emoções sobre a análise.
Pablo

Para dizer o mínimo, quando falamos de opiniões e diferenças nelas, simplesmente não podemos concordar com um método razoável, científico e tangível para medir o resumo.
1313 Pablo Pablo

Minha resposta é que só podemos medir aspectos técnicos, não pensamentos / opiniões abstratas. Além disso, não quero parecer um idiota. Esses posts não foram concebidos como algum tipo de resposta tola.
Pablo
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.