¿Cómo convencer al equipo de programación para que abandone las viejas costumbres?

Question

Esta es más una pregunta de programación orientada a los negocios que parece que no puedo entender cómo resolver. Trabajo con un equipo de programadores que han trabajado con BASIC durante más de 20 años. Fui contratado para ayudar a escribir el mismo software en .NET, solo con actualizaciones y prácticas modernas. El problema es que parece que no puedo conseguir que ninguno de los otros 3 miembros del equipo (todos los programadores de BASIC, aunque uno también lo hace ahora) también entienda cómo hacer correctamente una base de datos relacional. Esto es lo que no entenderán:

Básicamente tenemos una transacción que realiza un seguimiento de la información de etiqueta de un cliente. Necesitamos poder rastrear transacciones actuales y transacciones pasadas. En el sistema anterior, se usaba una base de datos de archivo plano que tenía una tabla que contenía registros con la transacción actual básica del cliente, y otra transacción que contenía todas las transacciones anteriores del cliente junto con información importante sobre el dinero. Para evitar la redundancia, sobrescribirían la transacción actual con las transacciones del historial (el archivo del historial se actualizó primero, luego el actual). Es totalmente innecesario ya que solo necesita una tabla de transacciones, pero mi supervisor o cualquiera de mis otros dos compañeros -los trabajadores parecen no poder entender esto. ¿Cómo exactamente puedo convencerlos de que vean la luz para que no tengamos que hacer cantidades ridículas de trabajo y terminar golpeando la base de datos demasiadas veces? ¡Gracias por el aporte!

Answer 1

En primer lugar, debo admitir que no está absolutamente claro para mí por su descripción cuáles son las estructuras de datos y los flujos lógicos en las estructuras existentes. Esto implica para mí que tal vez usted tampoco se aclare a sus compañeros de trabajo, por lo que una de sus prioridades debe ser poder explicar, verbalmente o preferiblemente por escrito y diagramas, la situación actual y el reemplazo propuesto. Tome esto como una observación en lugar de cualquier crítica a su pregunta.

En segundo lugar, me parece bastante notable que los programadores con 20 años de experiencia no entiendan las bases de datos relacionales y las transacciones. La codificación de archivos planos salió de la corriente principal hace mucho tiempo: manejé por primera vez las bases de datos relacionales en un entorno comercial en 1988 y eran bastante comunes a mediados de los 90. ¿En qué sector y tipo de producto está trabajando? A mí me parece posible que estés lidiando con algún tipo de sistema incrustado o `` inusual '', en cuyo caso debes asegurarte de que no tienes algún tipo de problema de comunicación y estás pasando por alto a un gran elefante eso no se te ha señalado: no serías el primer 'consultor' que se incorpora a un equipo que se ha creado de alguna manera al no recibir la información adecuada. Dicho esto, todavía existen tiendas arcaicas: una de las interfaces de sistemas de mis clientes actuales con un sistema basado en archivos planos codificado en COBOL, y sí, es un infierno administrar ;-)

Finalmente, si está completamente seguro de su terreno y se enfrenta a un equipo que no aceptará sus recomendaciones, y el código de demostración es una buena idea si puede perder el tiempo, entonces probablemente tendrá aceptar la decisión con gracia y mover una. En esta posición, trataría de resumir el problema: ¿pueden las actualizaciones de la base de datos moverse a los procedimientos almacenados, por ejemplo, para que el código para actualizar ambas tablas esté en el SP y pueda modificarse en una fecha posterior para pasar a su esquema sin un cambio de aplicación correspondiente? Asegúrese de que sus argumentos estén bien documentados y registrados para que pueda volver a visitarlos más tarde si surge la oportunidad.

No será el primer programador que haya tenido que implementar una solución subóptima debido a la política de la oficina: úsela como una experiencia de aprendizaje para su propio desarrollo personal sobre el manejo de tales situaciones y compadézcase con la idea de que le pagarán por el trabajo adicional. A menudo, el factor decisivo en tales argumentos no es la lógica, sino el 'peso de la reputación' que tú mismo traes a la mesa; parece que haber sido atraído no tienes mucho de ese tipo de influencia con tu equipo, por lo que puede que tenga que trabajar para ganar una reputación sobresaliendo en la implementación de lo que acuerdan hacer antes de que tenga suficiente reputación en casos posteriores: ¡debe ser modificado primero!

Answer 2

A veces no puedes.

Si lees algunos libros de XP, a menudo dicen que uno de tus mayores obstáculos será convencer a tu equipo de abandonar lo que siempre han hecho.

Generalmente recomendarán dejar que las personas que no pueden adaptarse vayan a otros proyectos (o simplemente dejarlos ir).

Las revisiones de código pueden ayudar en su caso. Las revisiones de código obligatorias de cada línea de código no son desconocidas.

Answer 3

En algún momento el mejor argumento es un ejemplo. Escribiría un prototipo (o un reemplazo si no es demasiado trabajo). Con un ejemplo para examinar, será más fácil ver los pros y los contras de una base de datos relacional.

Además, las bases de datos de archivos planos tienen su lugar, ya que son mucho más fáciles de & "; administrar &"; que una verdadera base de datos relacional. Manten una mente abierta. ;-)

Answer 4

Creo que es posible que tenga que liderar con el ejemplo, cuando las personas ven que " new " lo que es menos trabajo lo adoptarán (siempre y cuando no se frote la nariz).

También me preguntaría si el diseño anterior realmente está causando un problema o si es estéticamente molesto. Es importante elegir sus batallas: si el diseño anterior no está causando un problema de rendimiento o dificultando el mantenimiento del sistema, es posible que desee dejar el diseño anterior solo.

Finalmente, si deja el diseño anterior en su lugar, intente abstraer la interfaz entre su nuevo código y la base de datos anterior, de modo que si persuade a sus compañeros de trabajo para que mejoren el diseño más adelante, puede colocar el nuevo esquema sin tener que cambiar cualquier otra cosa.

Answer 5

Es difícil extraer mucho, excepto la frustración general de la pregunta original.

Sí, hay muchas técnicas y hábitos que los veteranos recogen con el tiempo que pueden ser inútiles e incluso costosos a la luz de los cambios tecnológicos. Algunas cosas que tenían sentido cuando el poder de procesamiento, la memoria e incluso el disco eran caros pueden ser intentos tontos de optimización ahora. También es muy cierto que las personas acumulan malos hábitos y malos patrones de programación con el tiempo.

Sin embargo, debes tener cuidado.

A veces hay buenas razones para las cosas que hacen los veteranos. Lamentablemente, es posible que ni siquiera puedan verbalizar el & Quot; por qué & Quot; - si ya saben por qué.

Veo mucho de este tipo de frustración cuando los novatos entran en una tienda de desarrollo de software empresarial. Puede ser malo incluso cuando el entorno es una tecnología y herramientas bastante modernas. Si la mayor parte de su experiencia está en escribir aplicaciones web y de escritorio para pequeñas comunidades, mucho de lo que & "; Sabe &"; puede estar equivocado.

A menudo hay requisitos para el registro de transacciones en un nivel superior al que puede hacer su DBMS. Muy a menudo puede ser necesario ir más allá de la semántica de transacciones DB para garantizar la corrección de la secuencia de tiempo, una y solo una vez la actualización, la resistencia y el no repudio.

Y esto ni siquiera comienza a abordar los problemas relacionados con la escalabilidad empresarial o entre empresas. Cuando comience a acercarse a medio millón de transacciones complejas al día, encontrará que la tecnología RDBMS le falla. Debido a que las bases de datos relacionales no están diseñadas para manejar grandes volúmenes de transacciones, a menudo debe romper con los paradigmas estándar para la normalización y actualización. Las técnicas de bloqueo RDBMS convencionales pueden destruir la escalabilidad sin importar la cantidad de hardware que arroje al problema.

Es fácil descartarlo todo como pesadez o desorientación general, incluso incompetencia. Pero tenga cuidado porque este no es siempre el caso.

Y por cierto: hay otros modelos además del RDBMS, y la alternativa a un RDBMS no es necesariamente " archivos planos " - Contrariamente a la experiencia de la mayoría de los codificadores de hoy. Hay DBMS jerárquicos transaccionales que pueden manejar un rendimiento mucho mayor que un RDBMS. IMS todavía está muy vivo en las grandes tiendas de IBM, por ejemplo. Otros proveedores ofrecen software similar para diferentes plataformas.

Por supuesto, en una tienda de 4 hombres tal vez nada de esto se aplique.

Answer 6

Inscríbalos en algunos entrenamientos decentes y luego depende de usted convencerlos de que con las nuevas tecnologías es posible mucho más (¡o al menos más fácil!).

Pero creo que lo más importante aquí es que los entrenadores profesionales y certificados les enseñen lo básico primero. Estarán más impresionados por eso en lugar de que solo uno de sus colegas les diga: & "; Oye, ¿por qué no usar esto? &";

Publicación relacionada aquí .

Answer 7

Lo siguiente puede no aplicarse en su situación de año, pero usted menciona muy poco los detalles técnicos, así que pensé en mencionarlo ...

A veces, si los patrones de acceso son muy diferentes para los datos actuales que para los datos históricos (estoy inventando este ejemplo, pero digo que se accede a los datos actuales 1000 veces por segundo, y accede a un pequeño subconjunto de columnas, y todos los datos actuales se ajustan en menos de 1 GB, mientras que, digamos, los datos históricos usan miles de GB, se accede solo 100 veces al día y el acceso es a todas las columnas),

entonces, lo que están haciendo sus compañeros de trabajo tendría mucho sentido, para la optimización del rendimiento. Al separar los datos actuales (albiet redundantemente) puede optimizar los índices y las estructuras de datos en esa tabla, para los patrones de acceso de mayor frecuencia que no podría hacer en la tabla histórica.

No todo lo que es " académicamente " ;, o " técnicamente " correcto desde una perspectiva puramente relacional tiene sentido cuando se aplica en una situación práctica real.