¿Cuáles son las barreras para adoptar las mejores prácticas? ¿Cómo pueden ser superados? [cerrado]

Todos hemos visto (y la mayoría de nosotros hemos escrito) mucho código mal escrito. ¿Por qué? ¿Qué nos hace adoptar malas prácticas en lugar de buenas?

La respuesta más obvia (para mí) es "ignorancia", pero estoy seguro de que esa no es la única razón. ¿Qué otros hay? ¿Qué podemos hacer para superar la tentación de escribir código incorrecto?

Resistencia al cambio.

Ese es el principal impulsor de la ignorancia, la mala gestión, etc.

El Capítulo 30 de Peopleware 2nd Edition está dedicado a este tema. Y cita un libro de otro consultor bastante conocido, escrito un poco antes:

Y debe considerarse que nada es más difícil de manejar, más dudoso del éxito, ni más peligroso de manejar, que ponerse a la cabeza de la introducción de nuevas órdenes. Porque el presentador tiene a todos los que se benefician de las viejas órdenes como enemigos, y tiene defensores tibios en todos los que podrían beneficiarse de las nuevas órdenes.

Nicolás Maquiavelo: El Príncipe (1513)

DeMarco y Lister continúan afirmando el mantra a tener en cuenta antes de pedirle a la gente que cambie:

La respuesta fundamental al cambio no es lógica, sino emocional.

El proceso de cambio rara vez es un impulso directo y suave de las condiciones subóptimas actuales al mundo nuevo y mejorado. Para cualquier cambio no trivial, siempre hay un período de confusión y caos antes de llegar al nuevo status quo . Aprender nuevas herramientas, procesos y formas de pensar es difícil y lleva tiempo. Durante este tiempo de transición, la productividad disminuye, la moral sufre, la gente puede quejarse y desear si solo fuera posible volver a las buenas formas de hacer las cosas. Muy a menudo lo hacen, incluso con todos los problemas, porque sienten que los problemas conocidos son mejores que los problemas nuevos, desconocidos, frustrantes y embarazosos. Esta es la resistencia que debe ser táctil y gentil, pero decididamente superada para tener éxito.

Con paciencia y perseverancia, finalmente el equipo llega del Caos a la siguiente etapa, Práctica e Integración. Las personas, aunque no están completamente cómodas con las nuevas herramientas / procesos, comienzan a acostumbrarse a ellas. Puede haber experiencias positivas de "Ajá". Y gradualmente, el equipo logra un nuevo status quo.

Es realmente importante darse cuenta de que el caos es una parte integral e inevitable del proceso de cambio . Sin este conocimiento, y preparación para ello, uno puede entrar en pánico al llegar a la fase del Caos y confundirlo con el nuevo status quo. Posteriormente, el proceso de cambio se abandona y el equipo vuelve a su estado miserable anterior, pero con aún menos esperanza de mejorar algo ...

Como referencia, las fases descritas anteriormente se definieron originalmente en el modelo de cambio Satir (llamado así por Virginia Satir ).

Péter Török tiene razón, pero omitió un punto importante y optimista:

• a las personas les puede gustar el cambio en el que están involucradas, pero casi nunca les gusta el cambio que simplemente "les sucede"

así que involúcrelos, déjelos contribuir ideas, déjelos crear una participación en él, y no será tan doloroso

Nota: esto es relevante para la programación porque muchos proyectos de software técnicamente exitosos fallan porque los usuarios los rechazan .

El tiempo parece ser grande donde trabajo.

Por ejemplo, ¿por qué adoptar pruebas unitarias cuando tiene que escribir más código y, por lo tanto, lleva más tiempo obtener un producto liberable? ¡El cliente x lo quiere ahora! ¡Código más rápido!

(Esto obviamente no termina bien)

Esto también es el resultado de una administración y una economía deficientes, que no cobran a los clientes lo suficiente como para permitirse el tiempo para hacerlo correctamente.

A pesar de la evidencia masiva de lo contrario, las personas suelen ser criaturas muy racionales. La razón por la que las personas no adoptan las mejores prácticas, como TDD, por ejemplo, es que no creen que valga la pena. O piensan que las prácticas no son, de hecho, las mejores; y que en realidad les costará más de lo que les ahorrará. O piensan que el beneficio es tan marginal que el costo del cambio será mayor que el pequeño beneficio. La conclusión es que el problema de las mejores prácticas es un problema de la conclusión.

Si desea ser un agente de cambio, su tarea es demostrar que su percepción del resultado final es defectuosa. Debe demostrar que la mejor práctica es realmente la mejor. Que los beneficios son inmediatos y significativos . Debe demostrar que la curva de aprendizaje es lo suficientemente pequeña como para resistir, y que al menos algunos de los beneficios comienzan de inmediato.

¿Cómo se muestra esto? Al adoptar la mejor práctica usted mismo! Nada sirve para convencer a otros mejor que tu propio comportamiento. Si usted sigue las mejores prácticas, y son vocales de ello, los demás verán que se hizo el análisis económico y tomado la decisión contraria. Eso los hará reconsiderar su decisión. Lo harán en privado, y nunca lo admitirán al principio. Pero todos los que lo vean usando esa mejor práctica, volverán a examinar su posición.

Eso es lo mejor que puedes esperar. Si la mejor práctica es una mejor práctica, el resto seguirá automáticamente. Oh, no será rápido, y habrá muchos retrasos. La transición será lenta e irregular; y experimentarás muchas decepciones. Pero la transición también será inexorable e inevitable. Puede ser que tome una generación, pero la mejor práctica será ganar.

Como prueba de eso, pregúntate cuándo fue la última vez que viste a alguien usar goto.

Es el resultado de no saber o pensar que uno conoce el método ideal. La gente no elige escribir mal el código; Es más un caso de no saber mejor. " Ingenuidad ", en oposición a " ignorancia ", sería una palabra mejor.

La forma más sencilla de ajustarse a las buenas prácticas es reconocer que existe (muy probablemente) una mejor manera de escribir el código que acaba de escribir, y luego aspirar a aprender cuál es esa "mejor manera".

Dos causas

• Ignorancia.

• Arrogancia.

¿Cómo pueden ser superados?

• Incentivos

Hasta que los gerentes (es decir, las personas que compran la habilidad del desarrollador) requieran mejores prácticas como parte de la entrega del software, nada puede cambiar. Muchas organizaciones son claramente esquizofrénicas: educan a los desarrolladores en diversas tecnologías y luego exigen software no probado o un diseño no comprobable. O peor.

La mejor práctica para mí es un software que escribió un equipo de 8 personas. No teníamos requisitos escritos, revisiones de códigos, pruebas de unidad, documentos de lanzamiento de formato. No hay pruebas de usuario final, nada de lo que todos los libros dicen que deberíamos haber hecho. El código fue apresurado, con errores y simplemente imposible de mantener. Fue descartado 3 años después del lanzamiento, fue tan malo. Entonces, ¿qué tenía de bueno? Dos años después del primer lanzamiento, el propietario de la compañía (que había financiado el desarrollo con una hipoteca en su propia casa) se fue con $ 30- $ 40 millones en su bolsillo trasero.

A menudo perdemos de vista el hecho de que estamos (la mayoría de las veces) aquí para hacer software que genere dinero para el negocio. Las empresas no existen para brindarnos la oportunidad de desarrollar software utilizando "Best Practice", existen para ganar dinero.

La mayoría de las prácticas de "mejores prácticas" no mejoran las ganancias. Los que hacen, deberían y son, ampliamente adoptados. Es por eso que no se practica la "mejor práctica".

Riesgo aceptable

¿Nunca te has arriesgado y apostado por algo? Hay una escasez de tiempo, por lo que puede hacer que funcione con la intención de refactorizarlo más tarde (en lugar de refactorizarlo antes). Eso en realidad se considera una buena práctica para algunas personas.

Eventualmente, te quemas suficientes veces y cambias tus formas. Piense en todas las 'mejores prácticas' que existen. ¿Puedes seguirlos a todos todo el tiempo? ¿Se contradicen unos a otros? No querrá perder el tiempo manejando todos los valores atípicos.

Si escribo un código incorrecto que funciona y nadie lo vuelve a ver, ¿se considera malo? (Por favor, no arruinemos el debate filosófico discutiendo sobre qué es el "código malo").

IME es una combinación de lo que otros han dicho. Ignorancia ("Solo he usado DataSets, ¿por qué molestarme con estas cosas de LINQ?", Falta de tiempo ("El Jefe quiere que se haga lo antes posible, no podemos dedicarle mucho tiempo"), falta de comprensión ("¿Qué tiene de malo escribir todo mi código en el código subyacente?") todos contribuyen.

La ironía que veo es que una vez que comienzas por ese camino, te obsesionas más profundamente. Si corta las esquinas ahora y arroja todo el código para una aplicación en los archivos ASPX, nunca podrá arreglarlo más adelante; Se te lanzarán cosas nuevas, lo que significa que tienes que hacerlo rápido, lo que significa que solo tienes que tirar todo el código en el archivo ASPX (jurando que lo arreglarás algún día), etc., etc. espiral final porque ya no puede detener el desarrollo y decir que las cosas deben arreglarse primero.

A menudo, a los desarrolladores simplemente no se les ha mostrado la mejor práctica o, lo que es más importante, los beneficios de usar una mejor práctica (estoy empezando a dejar de usar el término 'Mejores prácticas' por varias razones).

Existe la teoría de que los desarrolladores son "deliberadamente perezosos". En otras palabras, tenderán a elegir el camino de menor resistencia.

Una vez que les muestra rápidamente los beneficios de una mejor práctica (como TDD, o digamos, siguiendo los principios SÓLIDOS) y que en realidad les permite ser un desarrollador mejor (pero aún 'flojo'), entonces tienden a encontrar que la resistencia se derrite lejos.

Es una cuestión de educación :)

(Falta de) conocimiento y habilidades + tiempo para invertir

Me sorprende que nadie más lo haya publicado, pero tal vez sea obvio para mí porque gran parte de mi trabajo ha sido como programador único, sin nadie (aparte de la pila) al que recurrir cuando lucho por algo. Sé 'de' mejores técnicas, como TDD, pero a menudo no las entiendo lo suficientemente bien como para usarlas y me resulta difícil encontrar buena información para ayudarme a comenzar a usarlas. Una vez más, usando TDD como ejemplo, entiendo el significado básico de esto: compilar pruebas que afirman que su código genera un resultado específico, pero ¿realmente implementarlo?

Aparte del hecho de que XCode ha incorporado pruebas unitarias en estos días, no tengo ni idea de por dónde empezar. ¿Debo afirmar que la vista tiene botones X después de ejecutar una rutina para hacerlos? ¿Qué tal afirmar que mis UIViews se han reorganizado adecuadamente después de llamar a la etiqueta rotar?

Diablos, ¿cómo escribo una prueba unitaria en XCode? Es algo más que necesito pasar tiempo aprendiendo.

@Zues y @Joshua Smith

Sí, estoy de acuerdo en que a veces el tiempo y el presupuesto son algunas limitaciones que no le permiten poner todos los principios de "mejor programación" que conoce en un programa.

Sabes que la tarea actual se puede hacer de una manera mucho más sólida si solo tuvieras más tiempo. Pero muy pocos clientes (especialmente si están haciendo su primera aplicación para iPhone o su primer software de inteligencia empresarial personalizado) entienden cuando dice que está re-implementando algo ya hecho porque ha encontrado una mejor manera de hacerlo.

Lo mismo para las pruebas unitarias. Lamentablemente, aún no he conocido a un cliente que esté listo para asignarles un presupuesto. La respuesta típica es como “Pruebas de regresión automatizadas OK, entiendo pero ¿pruebas unitarias? ¡No tenemos tiempo para eso! ¡Tenemos que llegar rápidamente al mercado! ”

Dos partes en la mayor parte de mi experiencia:

• hora
• conseguir que suficientes personas acuerden qué prácticas son mejores para la situación actual

Las "mejores prácticas" son MUY subjetivas en muchas situaciones del mundo real. Si la mitad del equipo está tratando de hacer un montón de SÓLIDOS y TDD, mientras que la otra mitad está trabajando 60 horas a la semana para reducir segundos de las duraciones de carrera aquí y allá por cualquier medio necesario porque ya pasó el punto donde es demasiado tarde para Al rediseñar algo que no funciona a tiempo para su próximo lanzamiento, no llegará muy lejos.

Incluso si no está experimentando demasiado desacuerdo en todo el equipo, es un gran esfuerzo obtener un acuerdo formal, documentación y capacitación sobre cualquier política que decida seguir. Es un gran bloque de tiempo no productivo desde el punto de vista comercial que tendrá que justificar cuidadosamente.

A veces, encontrará que el hábito también es un contribuyente importante para escribir código horrible.

Puede ser un programador muy experimentado y puede saber todo sobre las mejores prácticas actuales de la industria. Demonios, incluso podrías ser el experto en tales cosas. La experiencia me dice que esas personas a menudo no escriben códigos horribles y, sin embargo, puede ser fácil recurrir a viejos hábitos y hacer algo que usted sepa que romperá las reglas, simplemente porque se siente seguro y conveniente. En tales casos, la ignorancia y la arrogancia y todos los demás adjetivos que señalan con el dedo que podría pensar realmente no importan. No es necesariamente que tales programadores sean específicamente malos en lo que hacen (aunque este es el caso con mayor frecuencia), o incluso que quieran crear un desastre horrible.

Es desafortunado que haya presenciado personalmente que esto suceda más veces de las que me gustaría contar, donde algunas personas verdaderamente talentosas han producido basura pura porque sus dedos y cerebros estuvieron funcionando en automóvil durante un par de meses. Muy a menudo, aquí es donde se acumula evidencia de agotamiento, dolor y estrés. A veces es solo un hábito ciego llevarlos a través de los movimientos diarios. Es algo que he aprendido a vigilar para evitar arriesgar el etiquetado innecesario de personas vulnerables.

Solo un poco de pensamiento para aquellos de nosotros que nos resulta más fácil simplemente llegar a la conclusión negativa ... aunque, lamentablemente, tendrá razón la mayoría de las veces.

Nadie muestra interés en pagar por un proyecto titulado algo a lo largo de la refactorización. Tiene que tener algunas palabras que sean atractivas para los intereses 'comerciales'. Palabras como renovar, revitalizar, rehacer total, actualizar el ciclo de vida, etc., funcionan en mi lugar de trabajo. Casi todos tienen una refactorización como parte principal del proyecto.

Lamentablemente, gracias al asesino económico, el trabajo solo ocurre cuando hay paga. Incluso si el trabajo es solo para salvar la fortuna empresarial a largo plazo.