Explicar por qué "Simplemente agregar otra columna a la base de datos" es una mala idea, a los no programadores [cerrado]

Les digo que puedo crear un sistema de tablas que permita a cada cliente definir su propio conjunto de campos personalizados, pero por supuesto eso toma más tiempo y dinero que "solo agregar unas pocas columnas".

Creo que deberías enviar esta opción a tus jefes ya que la personalización es obviamente una característica muy demandada. Hacer hincapié en que un sistema personalizado individualmente (en lugar de generalizado, personalización limitada) para cada cliente significa que los parches y actualizaciones tendrán que ser creado para cada cliente individual (lo que lleva a tiempos de despliegue más largos y costos más altos); que las instalaciones no estandarizadas significan que los tickets del servicio de asistencia tardarán mucho más en cerrarse (lo que lleva a clientes insatisfechos y costos más altos); etc.

En otras palabras, venda el dolor a corto plazo para obtener ganancias a largo plazo al mostrar que el costo de su solución supera con creces el costo de su solución.

Los vendedores se centran en hacer la venta. Eso es lo que les da su comisión. No preocúpate por lo que viene después. Los jefes, sin embargo, se centran en el costo. Vender a sus jefes y sus jefes pueden vender a los vendedores.

Ah.. un poco de conocimiento es algo peligroso.

Prueba este:

Usted: ¿A qué compañías no le vendimos?
Ventas: Acme Industries, OCP Corp, bla, bla, bla
Ti: Bien.... ¿por qué no puedes hacer un par de llamadas más?

La respuesta, por supuesto, es que las ventas no son tan simples. Tampoco lo es el desarrollo de software. A menos que realmente quieran horas de explicación con respecto a la arquitectura y el mantenimiento, les sugiero que confía en tu juicio como desarrollador de software.

Este es el problema aquí, confianza. Usted debe explicarles que están mostrando una falta de confianza en sus habilidades al hacer estas declaraciones.

Puede decirles que una base de datos mal diseñada significa que a largo plazo:

• Les tomará más tiempo recuperar sus datos-¿realmente quieren esperar y esperar?

• Será más difícil y llevará más tiempo diseñar consultas para generar informes; una vez más, si necesitan esa consulta mañana, ¿quieren que se les diga que todavía se está trabajando en ella?

• Será una pesadilla de mantener, con consultas propensas a errores más propensos a ser escribir.

Si son vendedores y contadores de frijoles, entonces definitivamente entenderán el dólar todopoderoso (libra, euro, etc.).). ¿Puede demostrar que el tiempo dedicado a mantener estas columnas adicionales no justifica las ventas agregadas?

Tenga mucho cuidado aquí y asegúrese de que su argumento tenga sentido. Me he encontrado resistente en el pasado a hacer personalizaciones más porque no quería estropear mi pequeño modelo de dominio que porque realmente sería tan difícil mantener. Un análisis decente te ayudará a determinar por qué te estás resistiendo a la personalización.

Recuerde - la conclusión es que usted necesita para mantener a los clientes felices con el fin de mantenerse en el negocio. Nosotros los desarrolladores reflexivos a veces podemos perder de vista eso en nuestra búsqueda de hacer las cosas fáciles de mantener y simples.

Busca en Google "deuda técnica"; Muéstrales los resultados.

Si estás en el negocio de vender un producto junto con personalizaciones, el producto necesita soportar personalizaciones sin tener que bifurcar la compilación cada vez que lo venden.

Parece que has intentado explicar eso, en vano. En su lugar, intente estimar el costo de agregar su "personalización de la manera correcta" para una tabla manteniendo, por ejemplo, media docena de versiones del producto con diferentes personalizaciones y corrigiendo un error en todas ellas. Mi apuesta es que verá que son bastante pronto el dinero por delante de tener un código base unificado y esquema. Y un desarrollador que no se vuelve loco.

Diles que cuando la gente hace un automóvil y luego quieren un modelo que vaya más rápido y haga más que el anterior, generalmente no agregan otro motor.

El problema es que "Estamos tratando de mantener la base de datos bien normalizada" es casi seguro que la respuesta incorrecta - devuelve la pelota al campo de la desconfianza y los propósitos cruzados.

Tienes que volver a centrarte en el objetivo final, la mejor manera de cumplir ese objetivo final (tal vez en varias versiones) y lo que costará a corto y largo plazo. He visto mención de la deuda técnica en las respuestas y las estimaciones de costos deben tener en cuenta esos factores.

It podría no ser una mala idea "simplemente agregar otra columna?". Realmente no has dado todo el caso de negocios. Por otro lado, han desafiado su respuesta negativa con una pregunta técnica ignorante. Eso no llega al corazón de ayudarle a entender el requisito porque no les gustó escuchar "no". (Me gustaría saber cuál fue la declaración original del problema.)

Normalizar la base de datos es un problema técnico y no tiene relación con el requisitos que el sistema debe satisfacer: es un principio de diseño del sistema que se utiliza para entregar sistemas con ciertas propiedades como la capacidad de mantenimiento. Pero los sistemas mantenibles que no satisfacen las necesidades del usuario tienen valor cero, mientras que los sistemas no mantenibles que sí satisfacen las necesidades del usuario tienen valor distinto de cero (que podría ser superado por el costo de mantenimiento, que es un problema comercial). Si se requiere EAV o algún otro mecanismo no es realmente el punto tampoco - que solo causa complejidad del sistema o costo para aumentar.

Si los requisitos son demasiado caros para implementarlos, entonces eso es parte del caso de negocio. No nos has dicho lo suficiente sobre la arquitectura o el tipo de entidades que modelan estas tablas. Digamos que tienes 100 clientes. Puede haber superposición en las columnas de una entidad en particular. Hasta el 95% de los clientes nunca usarán la dirección de facturación opcional o una columna de Segundo nombre, eso no significa que esas columnas se queden fuera, no solo eso, sino que a menudo están en un diseño original! Alternativamente, si se trata de una tabla de Productos y cada cliente quiere muchas columnas especiales y no hay superposición, es posible que necesite un sistema de campos definido por el usuario (EAV/XML/tag-el diseño tendrá que coincidir con los requisitos) en su lugar con el fin de mantener un diseño de sistema cohesivo.

Rara vez he encontrado que las empresas ignoren un argumento de deuda técnica, especialmente si se puede demostrar que una solución propuesta satisface las necesidades del usuario y la flexibilidad puede convertirse en un punto de venta. Lo que yo han encontrado es que el negocio a menudo preferirá si presenta opciones de solución tan rápido y a fondo como sea posible sin pasar más tiempo explicando por qué algo no se puede hacer o cuánto va a costar de lo que tomaría para abrocharse el cinturón en un par de tardes y realmente hacer el trabajo.

Yo nunca he intentado esto, pero he pensado en ello: dibujar una analogía con el sistema legal. Existen lagunas legales porque los legisladores tratan de parchear el sistema con perezosos kludges. El equivalente del software es bugs, agujeros de seguridad, etc. La única manera de evitar estos problemas es la planificación cuidadosa y el trabajo duro.

Hágales entender cuánto cuesta en tiempo de desarrollo, ¿este cambio requerirá 1 o dos desarrolladores de tiempo? ¿qué hay de las pruebas? si las solicitudes complejas cuestan más, entonces la empresa en su conjunto está ganando menos en el trabajo. El gerente de cuenta / proyecto debe ser el intermediario que es el trabajo de buffer este tipo de solicitudes.

No llegarás a ninguna parte explicándoselo en términos técnicos. Necesitas una metáfora. Adáptalo a la persona con la que estás hablando, si puedes. Si él/ella es un coche impresionante, pensar en términos de modificaciones del motor. ¿Cuánto le costaría a Ford ofrecer tres motores diferentes en el Taurus, o mods personalizados bajo demanda?

Una vez que aceptan esa comparación, incluso si no la entienden completamente, puedes comenzar a entrar en por qué se aplica la metáfora.

Hay otra gran manera de ayudarlos a verlo a su manera: tómese un tiempo para verlo a su manera también. Cuando su cheque de pago depende de darle al cliente lo que quiere, no le importa lo que le diga el propulsor en Ingeniería. Si recibe muchas solicitudes de personalización, debe considerar los enfoques arquitectónicos y estratégicos para entregar esas personalizaciones, siempre que sea posible.

Para ampliar la sugerencia de tuinstoel (evitar estructuras genéricas de entidad-atributo-valor): Aunque generalmente me gusta esta estructura para uso ligero, el uso excesivo (lo que sea que eso signifique) degradará el rendimiento como se ha señalado. Estas estructuras no pueden estar bien indexadas. Escribí y apoyé uno de esos sistemas. Para cuando teníamos 50,000 "entidades" cada una con 10-100 teclas, era LENTO incluso en hardware de rango medio).

Sin embargo, son muy útiles y bastante fáciles de implementar. Así que si hay una necesidad de muchos "campos adicionales" arbitrarios que se agregarán por cliente, entonces puede tener más sentido.

Otra opción posible podría ser agregar un número de columnas genéricas no utilizadas en las tablas apropiadas para ser utilizadas por los clientes para sus propios fines. Algunas aplicaciones emprendedoras hacen precisamente esto. Una tabla de ventas puede tener diez o veinte columnas CUSTCODE01 a CUSTCODE10 que cada implementación de la aplicación puede usar de manera diferente y totalmente personalizada.

Esto puede a primera vista horrible, también puede ser un medio feliz. Hay una buena cantidad de espacio para personalizar por cliente sin a) "solo agregar una columna" e interrumpir la aplicación o el proceso de desarrollo, o b) implementar un sistema genérico potencialmente lento. Sin embargo, solo obtiene una cantidad limitada de felxablity, y hay una falta de nombres de columna que se documenten automáticamente (pero las descripciones de las columnas se pueden personalizar según sea necesario).

...Les digo que puedo crear un sistema de tablas que permita a cada cliente definir su propio conjunto de campos personalizados, pero por supuesto eso lleva más tiempo y dinero....

Parece que desea construir algún tipo de modelo de datos genérico? Entity-attribute-value...?

Esos modelos genéricos a menudo son muy lentos, no pueden indexarse correctamente y confunden al optimizador de consultas. A menudo es mejor simplemente agregar algunas columnas.

Hacer un análisis comparativo muy minucioso antes ir por el camino genérico.

Tal vez sea dependiente del proveedor de la base de datos, pero si usa Oracle, preferiría la ruta 'solo agregue algunas columnas' por encima de la ruta entity-attribute-value.

Puede explicar este problema dibujando una comparación con una biblioteca. Hay muchos libros. Uno pequeño y uno grande, uno delgado y uno grueso-todo el mundo puede imaginar eso. Ahora bien, si desea almacenar más información en algún lugar, sería bastante más simple agregar algunas páginas nuevas a un libro que ampliar algunas páginas individuales, si hay varias páginas de un libro más grandes que las demás, esto no es muy robusto y cómo se encuentra esta información si no tiene ninguna entrada en el índice de contenidos? Tal vez sea mejor para almacenar la nueva información adicional en otro libro, uno nuevo con una estructura particular. Imagínese cómo uno puede obtener una información si todo el contenido de una biblioteca se escribiría en un gran libro grueso? Nadie más podría encontrar nada hasta que encuentre lo que quiere y coloque el libro en su lugar...si eres capaz de llevar este enorme libro. ¿Por qué recuperar todo el Livestory si solo quieres saber la fecha de nacimiento de una persona?

Las personas mencionadas no tienen que entender la arquitectura de una base de datos, pero deben confiar en usted. Y lo organizas para que puedan lanzar su información en este gran agujero de la base de datos y recuperarla cuando la quieran - rápido y confiable.