Si alguien le ofrece una declaración no verificada sobre las prácticas de desarrollo de software, ¿responde con “cita requerida”? [cerrado]

Recientemente asistí a una conferencia dada por Greg Wilson (Jefe Científico de Carpintería de Software). Del resumen:

La idea de que las afirmaciones sobre las prácticas de desarrollo de software deben basarse en evidencia aún es ajena a los desarrolladores de software, pero esto finalmente está comenzando a cambiar: cualquier académico que afirme que una herramienta o práctica en particular hace que el desarrollo de software sea más rápido, más barato o más confiable es ahora esperaba respaldar esa afirmación con algún tipo de estudio empírico.

En general, la conferencia fue muy informativa y me dejó pensando bastante profundamente sobre mi enfoque del desarrollo. En particular, ahora me encuentro buscando citas para respaldar muchas declaraciones. Anteriormente, me había acostumbrado a repetir las verdades ofrecidas, tal vez con una nota mental para comprobarlo más tarde.

Dicho sin rodeos, estaba siendo crédulo .

Aquí hay un ejemplo tomado de la conferencia:

"Si más del 25% del código necesita refactorización, es más rápido reescribirlo".

Suena plausible, pero ¿es cierto? ¿Dónde está el estudio respaldando esto? ¿Es cierto para todos los idiomas? Y así.

OK, es bastante posible llevar esto al extremo y no creer nada por nadie a menos que lo haya derivado usted mismo de los primeros principios. De esa manera se encuentra la locura (o tal vez las matemáticas ;-)). Pero, si alguien se le acerca con una declaración en la línea de "Oye, al hacer esto en [elegir el idioma del momento] podremos aumentar la productividad en [elegir un múltiplo del 10]%", ¿estás dispuesto a simplemente aceptarlo, o vas a pedir pruebas comprobadas?

Si es lo último (y espero que lo sea) entonces

1. ¿A dónde irías para encontrar esta evidencia?
2. ¿Qué tan estricto serías?

En resumen, si alguien le ofrece una declaración no verificada, ¿responderá con "cita requerida"?

El problema con este tipo de declaraciones es que incluso si tuviera evidencia empírica que respalde la afirmación, sería muy difícil determinar si el estudio que condujo a la evidencia se aplica a su situación actual.

Casi todo en la profesión tiene una advertencia, o varias, por lo que cada mejora en un lugar tiene la probabilidad de ser perjudicial en otro lugar.

Las personas que viven en las trincheras conocen la diferencia a través de la experiencia y, en general, no tienen los fondos / tiempo / recursos para intentar demostrarlo a través de un estudio científico.

Las personas que intentan demostrarlo a través de un estudio científico obviamente tienen recursos para dedicar a tales estudios y, por lo tanto, es muy probable que le vendan algo, por lo que diría que debería aplicar aún más estrictamente su propia experiencia personal a cualquier cosa que afirme estar respaldado por investigaciones empíricas.

Si alguien le dijera "Si más del 2% del código necesita refactorización, es más rápido reescribirlo", sabría que es falso tanto como si alguien le dijera "Solo si más del 98% del código necesita refactorización, es más rápido reescribirlo ". El lugar donde se encuentra el número real depende de lo que esté haciendo y qué tan lejos de ideal sea el código actual.

La idea de que después de cierto punto es más fácil hacer un refactor nuclear es obviamente cierto en muchos casos, pero el porcentaje real es más un ejemplo que debe considerar a través de la lente de la experiencia y la situación actual de su (equipo).

Si alguien le ofrece una declaración no verificada sobre las prácticas de desarrollo de software, ¿responde con “cita requerida”?

No, lo publico aquí y veo si recibe votos positivos. ¡La prueba social es mejor que ninguna prueba!

Muchos desarrolladores basan sus decisiones momento a momento en la experiencia en las trincheras que trabajan con el código y los clientes a los que sirve ese código.

Cuando una clase o método se ha fragmentado tanto por correcciones de errores y solicitudes de cambio de clientes que se ha vuelto imposible de mantener, un desarrollador a veces tomará la decisión de reescribirlo en lugar de refactorizarlo, bajo la teoría de que ahorrará tiempo y esfuerzo a largo plazo , porque el código resultante será de mayor calidad.

Este tipo de experiencia de inteligencia es lo que los departamentos de recursos humanos llaman "capital humano". Es una de las cosas que hace que los desarrolladores experimentados sean valiosos, y una de las razones por las que las buenas empresas hacen cosas para tratar de preservar la longevidad de sus empleados.

No parece justo ni práctico pedir a los desarrolladores experimentados que presenten un estudio y datos empíricos como prueba de que sus técnicas son válidas. La experiencia no funciona de esa manera. Por el contrario, la experiencia es algo así como un "sentido sentido". En el mundo de la refactorización, a menudo lo llamamos "olor".

En última instancia, una declaración como "Si más del 25% del código necesita ser refactorizado, es más rápido reescribirlo" no puede probarse que funcione en todas las circunstancias, por lo que la declaración [cita requerida] es realmente una forma de informar al programador dogmático que busca forzar sus puntos de vista sobre los demás de que no siempre es "Su camino o la autopista".

Creo que con cualquier cosa que nunca sepas hasta que lo pruebes. Incluso con pruebas para respaldar una declaración, siempre es posible doblegar los hechos en beneficio de su punto. Dicho esto, no deberías probar todas las cosas nuevas que afectan a las redes. Haz tu mejor juicio. Recuerde, si algo es demasiado bueno para ser verdad, probablemente lo sea. Pregúntese siempre por qué necesita adoptar algo. ¿Qué tienes que ganar? ¿Tiene sentido desde una perspectiva comercial? Nunca cegado excepto algo en la fe.

El ejemplo de la conferencia es una heurística, una regla general y nada más. Eso debería ser implícitamente obvio.

Las heurísticas son como cualquier otra cosa: están sujetas a un determinado contexto y dependen de cualquier cantidad de suposiciones no declaradas, y su utilidad puede ser muy no determinista. Tanto juicio arbitrario entra en encontrarlos útiles como en formularlos en primer lugar.

¿Eso significa que no tienen valor? Yo no diría eso en absoluto.

La heurística es uno de los enfoques que podemos adoptar para abordar los problemas de NP completo y, en muchos aspectos, la ingeniería de software es en sí misma un problema de NP completo.

Depende. :) Cuando la declaración de alguien contradice la experiencia repetida, reflexionada y verificada personalmente, entonces sí, me gustaría ver algún tipo de referencia de un estudio. Por otro lado, si alguien se hace eco de una idea que has visto y vivido muchas veces, no hay mucha reacción provocada (aunque eso no significa que la idea sea infalible).

Como ejemplo, el libro "Code Complete" cita decenas de estudios en cada capítulo para exponer sus puntos, a veces sobre asuntos aparentemente pequeños (como sangría y espaciado, o longitud de nombre variable). Recuerdo a algunos desarrolladores (más jóvenes) a quienes les presenté el libro que pensaban que ese nivel de detalle y evidencia era una tontería. Pero unos meses más tarde con más experiencia en codificación de producción y después de algunas revisiones de código, algunos de esos mismos desarrolladores tuvieron la honestidad de admitir que sí, incluso el número de espacios en sangría sí importa. Los buenos comentarios importan. La encapsulación importa. etcétera etcétera.

Por otro lado, cuando un vendedor afirma que un nuevo IDE es 50% más productivo, mi primera reacción es bull $% ^ &!

¿No es algo que depende de muchas variables intangibles (variables que no tienen forma de ser medidas científicamente)?

En mi opinión, están hablando de un método empírico para medir las emociones. Algo que ni siquiera Spock podría lograr. =)