¿Cómo lidiar con mentalidades ad-hoc?

Me uní a un equipo de desarrollo de seis hace dos meses. La gente es amable, todo está bien. Pero cada vez más observo una mentalidad ad-hoc. Las cosas se arreglan rápidamente, a costa de la usabilidad futura, hay pocas pruebas y dos personas felizmente admitieron que les gusta llevar el conocimiento a la cabeza, en lugar de escribirlo.

Como lidiar con esto? Me gustaría liderar con el ejemplo, pero el tiempo es limitado: me gusta diseñar e implementar las cosas. Pero me temo que la mentalidad ad-hoc me infecta y, en lugar de luchar por la claridad y la simplicidad en el diseño y el código, que no es fácil de establecer, me tiran por el desagüe de una espiral interminable de hacks en hacks, que no el extraño puede desacoplar, solo por el bien de la agenda y la administración.

Ya conoces parte de la respuesta: debes liderar con el ejemplo. También debe sentirse cómodo con el hecho de que su "liderazgo" puede ser ignorado, que sus colegas continuarán haciendo las cosas de la forma en que siempre lo han hecho, ya sea porque hace feliz al jefe o porque ellos mismos valoran la conveniencia sobre mantenibilidad a largo plazo.

Al final, debe dejar que sus resultados hablen por sí mismos. ¿Perdió una fecha límite por tres días pero ahorró al equipo de control de calidad al menos esa cantidad de días programados de prueba porque probó su desarrollo y funciona en gran medida según lo diseñado? Eso es una victoria.

Al final, sin embargo, si no tiene al menos algún grado de aceptación por parte de la gerencia para ese tipo de compensación, simplemente está en el entorno equivocado y necesita encontrar uno más que conduzca a las buenas prácticas. Las malas prácticas crean hábito, por lo que cuanto antes pueda encontrar una manera de mantenerse firme o cambiar a un entorno de trabajo con mejores prácticas, mejor.

¿Nada?

Quiero decir, existen limitaciones de tiempo de negocios. El suyo podría ser un escenario en el que el tiempo de comercialización es más valioso que la facilidad de uso futura.

Si usted es un programador de rango y archivo, entonces establecer estándares y preocuparse por la arquitectura del producto no es realmente su trabajo (especialmente 2 meses). Usted debe tratar de mejorar el producto sin embargo se puede (incluyendo el cambio de cultura), pero no a costa de alienar a su equipo y / o jefe. Ser el nuevo tipo que cree que conoce mejor es una manera rápida y fácil de hacerlo.

Me preguntaría por qué estás haciendo todas estas soluciones rápidas de pirateo. ¿Se debe a arreglos rápidos anteriores de hack? Es bastante fácil señalar que si las cosas se hicieron "bien" en primer lugar ...

Al final, las malas prácticas de programación conducen a un dolor concreto. Si las personas piensan que no lo harán, todo lo que necesita hacer es esperar.