¿Demostrar código incorrecto al cliente?


129

Un cliente me ha pedido que rediseñe su sitio web, una aplicación ASP.NET Webforms que fue desarrollada por otro consultor. Parecía un trabajo relativamente sencillo, pero después de mirar el código, está claro que ese no es el caso.

Esta aplicación no fue bien escrita. En absoluto. Es extremadamente vulnerable a los ataques de inyección SQL, la lógica de negocios se extiende por toda la aplicación, hay mucha duplicación y un código sin salida que no hace nada. Además de eso, sigue arrojando excepciones que se están sofocando, por lo que el sitio parece funcionar sin problemas.

Mi trabajo es simplemente actualizar el HTML y CSS, pero gran parte del HTML se está generando en la lógica empresarial y sería una pesadilla resolverlo. Mi estimación sobre el rediseño es más larga de lo que el cliente buscaba. Se preguntan por qué tanto tiempo.

¿Cómo puedo explicarle a mi cliente qué tan malo es este código? En su opinión, la aplicación se está ejecutando muy bien y el rediseño debería ser rápido. Es mi palabra contra el consultor anterior. ¿Cómo puedo dar ejemplos simples y concretos que un cliente no técnico entenderá?

Actualizar

Gracias por todas las respuestas. La demostración del ataque de inyección SQL tiene sentido y la demostraré en un entorno de prueba. Esa es solo una parte de muchos problemas en esta aplicación. Estaba buscando formas de explicar por qué otras partes (como la generación de html en la capa de datos) tendrían que ser reemplazadas por mejores prácticas para que la actualización html y css tenga lugar. Aquí hay muchas buenas sugerencias que reuniré cuando hable con mi cliente.


97
¿Demostrar un ataque de inyección SQL?
Austin Henley

30
This application was not written well. At all.Casi nunca lo son. :)
haylem

15
Además de demostrar los problemas como dice Austin. no subestimes el poder de una pizarra y un rotulador. La mayoría de las personas responden bien a un mal diseño explicado cuando está en forma de imagen.
Sirex

3
si no es grande, vuelva a escribirlo, si es grande, no lo tome
ren

44
El cliente dice rediseño y piensan HTML / CSS. Usaría los términos "falta de modularidad" y destacaría el "diseño lógico" frente a la "presentación". Las metáforas de la construcción de edificios son útiles. To make a change in the look of the living room, I had to go into the air-conditioning system.En un buen diseño modular, tales cosas no suceden.
Fuhrmanator

Respuestas:


144

Los no expertos en tecnología no son idiotas (en su mayor parte). Pueden entender un argumento técnico si lo mantienes lo suficientemente alto. Elija una tarea que creía que debería ser simple y explíqueles por qué no lo es.

Esperaba que este cambio fuera una palabra en un archivo. El lugar más probable para cambiarlo parecía estar aquí, pero cuando lo cambié allí, solo funcionó en un lugar, y rompió estos otros 7 lugares. Cuando arreglé uno, rompió dos lugares más, causando un efecto dominó, por lo que un cambio que pensé que debería haber tomado 10 minutos terminó tomando 2 horas. Ese es solo un ejemplo. Hay muchas más tareas inesperadas de 2 horas allí.


10
Dado el contenido de tantos informes de errores, "se rompió __ más lugares" parece ser la mejor manera de describir el efecto dominó ...
Izkata

44
Bien, haría más una conexión entre tiempo y costo. Muéstreles cuánto había esperado que costara un cambio frente a cuánto costó un cambio. En mi experiencia, los clientes rara vez prestan atención a menos que usted pueda argumentar que están gastando el doble, el triple o más de lo que pagarían de lo contrario.
Tim O'Brien el

87

La estructura del código, el estilo, la deuda técnica son una cosa con la que, al menos inicialmente, hasta que el cliente confíe en usted, tendrá que vivir.

Las vulnerabilidades de seguridad son otro asunto.

Personalmente, haría una estimación basada en el trabajo requerido utilizando la estructura y el estilo existentes al mismo tiempo que aclararía que hay problemas importantes con la base de código. Plantearía las implicaciones de seguridad por separado: haga una demostración de un hack en la base de datos para llevar el punto a casa durante una reunión.

Me alegró mucho hacer esto con un cliente anterior con un sistema de tarjeta de regalo de lealtad cuando puse £ 5000 en "mi" tarjeta y le pedí que revisara la tarjeta en su caja.


38
Demostración de +1 cuán grave podría ser el ataque de inyección SQL. Hazlo delante de ellos. Si es posible, grabe en video sus reacciones.
Philip

40
@Philip: ... la demostración debería estar preferiblemente en un entorno de desarrollo aislado para la aplicación. Eliminar su base de datos de producción probaría el punto, pero podría perder su contrato (y ganar una demanda).
FrustratedWithFormsDesigner

19
@FrustratedWithFormsDesigner si incluso tienen un entorno de desarrollo disponible ...
Ratchet Freak

3
@FrustratedWithFormsDesigner: por supuesto, no se recomienda limpiar la base de datos, no importa cuán fácil y dramático sea. Pero podría ser igual de sorprendente (para ellos) extraer datos privados y luego (cuidadosamente) cambiar algunas cantidades (como el saldo de una tarjeta de regalo como lo hizo @Michael). Para obtener puntos adicionales, haga obvio que realmente no necesita ver el código; comience volcando una lista de tablas, elija algunos nombres interesantes, descargue el contenido. No debería tomar demasiado para perforar el punto que es tan vulnerable.
Javier

76

Aquí hay algunas sugerencias excelentes sobre cómo transmitir y comunicar esto al cliente. Esperemos que paguen por ti.

¡Bandera roja importante aquí!

Si el cliente le pide que no realice ningún cambio que no sea el acordado (HTML y CSS), transmitiría este proyecto y retiraría mi oferta.

Incluso con una visión general escrita y bien comunicada de todos los defectos y problemas de seguridad, la responsabilidad potencial es demasiado grande para que me sienta cómodo. Incluso si el cliente nunca tomó ninguna acción legal o exigió soluciones después de un hack o violación; ¡Su nombre y reputación todavía están unidos al trabajo!

Puede perder mucho más de lo que puede ganar.


14
+1 para ver la imagen más amplia. Si trabaja en ello y dice que ya terminó, puede incurrir en alguna responsabilidad por los errores y problemas de seguridad, incluso si solo los heredó. Si alguien manipuló los frenos, y un mecánico repara mi bicicleta y se encogió de hombros fuera el problema, también podría considerar demandarlos ...
sleske

2
+1 esta es una lección que el consultor toma demasiado tiempo para aprender (y, sin duda, es un concepto difícil de seguir durante una economía difícil). El valor de su experiencia es tanto una función del trabajo que realiza como una función del trabajo que rechaza.
Tim O'Brien el

2
+1 Esta es una lección que aprendí por las malas y mi primer negocio estuvo a punto de fallar por eso. A menudo, en estos casos, el costo de enumerar todos los "defectos" y cotizar para solucionarlos requiere más esfuerzo del que el cliente está dispuesto a pagar.
Catharz

30

Explica y posiblemente demuestre la falla
Cuando es tu palabra contra la suya, todo lo que dices podría ser solo aire caliente en lo que a ellos respecta. Una vez que les muestres cómo se puede abusar de su aplicación a través de la inyección SQL, de repente eres una persona de confianza. Necesitarás credibilidad para renegociar. Y esto es suficiente para cambiar el juego para dártelo.

Sea caritativo con respecto a su predecesor
Eso no significa que simule que los errores no están ahí, pero si se encuentra condescendiente, entonces pierde credibilidad. No diga una palabra sobre el programador, excepto tal vez para darle el beneficio de la duda. Concéntrese en el código, no en el codificador. Hacerles sentir que eres el "buen chico" te dará mucho más margen de maniobra en las negociaciones. Y los "buenos" nunca dicen cosas malas. Al explicar los errores de seguridad existentes (como las vulnerabilidades de inyección SQL) al cliente, prefiero decir algo como esto:

La seguridad de las aplicaciones web es un campo en rápida evolución. Muchas de las herramientas y técnicas de desarrollo que las personas aprenden incluso hoy evolucionaron antes de que la mayoría de estos exploits fueran bien entendidos. Para mantenerse a la vanguardia de los desarrollos de seguridad, debe seguir el campo muy de cerca y ocasionalmente incluso cambiar su estilo de desarrollo completo. La mayoría de los programadores no hacen esto.

Aquí vamos. Ni una palabra de maldad hablada sobre el desarrollador; él es "la mayoría de los programadores", lo que significa que está en muy buena compañía. Y ahora has demostrado que eres no "la mayoría de los programadores" que le dan un poco más de credibilidad y tal vez una razón para que se le pagan más dinero.

Negocie un nuevo acuerdo
Una vez que el cliente comprenda que su aplicación está abierta al abuso por parte del público, querrá que se repare. Probablemente seas la persona a la que le va a pedir que lo arregle. Es posible que desee o no ese trabajo, así que piénselo detenidamente antes de hablar con ellos.

Por lo menos, quieres más tiempo para terminar el trabajo que ya te han dado. Los ha puesto lo suficientemente desprevenidos con la vulnerabilidad como para que probablemente no lo mantengan en su estimación original. Pero asegúrese de que el cliente sepa lo que es y no va a arreglar como parte de este acuerdo.

Por lo general, el desarrollador (usted) preferiría rehacer todo desde cero. Y en casos como este, incluso podría ser una opción. Pero incluso entonces, el cliente querrá algo que pueda mantener su negocio en funcionamiento hasta que se cree la nueva aplicación. Esto significa que a pesar de que está empezando otra vez, es probable que todavía va a tener que actualizar la aplicación de edad un poco.


8
+1 por nunca ser condescendiente. Dejar que los hechos hablan por sí solos ...
sleske

44
+1 para "Sea caritativo con respecto a su predecesor".
msanford

19

Comencé esto como un comentario, porque al principio pensé que era un aparte, pero probablemente en realidad no lo es.

Documentaría completamente todo lo que cree que debería rediseñarse, y por qué (qué sucede si no realizan el cambio), y una estimación sobre cómo solucionar el problema. Sería particularmente meticuloso con cualquier cosa que percibas como un riesgo de seguridad.

Haría esto antes de tocar cualquier código y asegurarme de que su cliente tenga una copia de este informe, preferiblemente con algún tipo de marca de tiempo. Puede llevar algún tiempo, pero también lo cubrirá si uno de estos riesgos de seguridad llega a buen término. Aún mejor si puede obtener algo firmado que diga que recibieron el documento.

Claro, puede señalar el control de origen del código original que heredó si alguna vez sucede, pero será mucho más fácil señalar este documento y decir, de una manera más profesional, "¿Ves? Te lo dije".

Este documento puede ser el punto de partida de nuevas discusiones, e incluso puede ser utilizado por su cliente para obtener las "personas adecuadas" para dar permiso para realizar algunos o todos los cambios.

Dicho esto, una vez que el cliente entiende los riesgos, sonríe y aguanta si te dicen que hagas el trabajo de todos modos, o aléjate.


Esperemos que realmente estén usando el control de fuente.
Bernard

66
Gran respuesta. Pero como alguien que ha estado en el tribunal por una situación similar que incluía documentación completa y la firma de un cliente, todavía me costó mucho dinero y dolor de cabeza.
Steve

55
Buena idea en principio, sin embargo, tenga en cuenta que esto puede ser mucho trabajo. Esto probablemente solo sea práctico para trabajos grandes, de lo contrario, pasará 50 horas documentando problemas para un trabajo donde solo puede facturar 20.
sleske

@sleske: acordó que será mucho trabajo, pero espero que también te ayude si ocurre el peor de los casos y hay una violación de seguridad. Como mínimo, necesita algo que diga que ve riesgos de seguridad y que no quiere que se le haga responsable de esos riesgos preexistentes.
Wonko el sano

2
@WonkotheSane: Cierto, pero solo si tomas el proyecto . Si los problemas son tan grandes y su trabajo planificado tan pequeño, puede ser mejor simplemente rechazar el proyecto. Por supuesto, aún debe documentar sus inquietudes (seguridad y otros), pero si nunca trabajó en el proyecto, no debería haber riesgo de responsabilidad. En última instancia, tendrá que evaluar si su cliente está dispuesto a pagar el costo de la limpieza.
sleske

14

Recuerde que el cliente le pedirá ayuda para mantener su aplicación. Es su trabajo como profesional señalar cualquier problema que encuentre con su aplicación. Es probable que el cliente no tenga idea de que estos problemas existen y se los debe informar. Explique estos problemas de manera que puedan entenderlos y déjelos decidir cómo quieren proceder.

Use ejemplos del mundo real para ilustrar estos problemas, como un auto averiado o una lavadora que necesita reparación. Señalar es usar ejemplos con los que ya están familiarizados. Para explicar la inyección SQL, simplemente demostraría qué es eso y por qué es un problema.

Al final, quiere transmitir que le importa el éxito de la aplicación en la que se le pide que trabaje.


3
Esto no se parece en nada a un automóvil averiado, a menos que el automóvil haya sido construido a partir de partes aleatorias por un mecánico aficionado. Es como un garaje construido por un contratista incompetente, y el propietario quiere que el OP ponga un abrepuertas automático. El OP descubre que el garaje no es seguro y que necesita una revisión importante de inmediato.
Kevin Cline

2
Imagine un automóvil averiado que utiliza cinta adhesiva para unir las piezas y evita que el tablero muestre alertas o advertencias al conductor, mientras que el volante puede caerse en cualquier momento. Se necesita algo de creatividad, pero es posible usar diferentes analogías para ilustrar un problema.
Bernard

O tenga en cuenta el cable del acelerador de hilo de amarre 'personalizado' que puede atar a la consola para la aceleración manual ... tecnología 'volar por cable' a bajo precio. Casi cualquier cosa que hayan hecho en el Red Green Show podría aplicarse. Lo que tienen "funciona", pero no es bonito, y parece, tras una inspección superficial, que es frágil y aumenta el riesgo de cualquier cambio.
JustinC

1
Si pudiera agregar votos adicionales a esto, me limitaría a 'Recordar que el cliente va a pedirle ayuda para mantener su aplicación'.
Daniel Hollinrake

7

Me gusta usar analogías con las que el cliente pueda relacionarse. La cantidad de trabajo que puse por adelantado para ganar el trabajo dependería de la cantidad de dinero que el cliente tenía la intención de gastar ($ 100 es muy diferente de $ 20,000). Observe que dije "con la intención". Su estimación personal del valor involucrado no significa mucho si no obtiene lo que está pidiendo.

En su situación, de nuevo dependiendo del dinero, podría dibujar un cuadro con una línea que salga de cada lado y decirle al cliente "Así es como visualiza el software ahora. Los datos van por un extremo y salen por el otro, todos se ve bien, limpio y simple ". "Así es como se ve el software en el interior" y luego dibuja una tercera línea que conecta las dos líneas dentro de la caja.

Luego dibujaría otro cuadro como el primero con las líneas de entrada y salida en el exterior, excepto que esta vez diría "Así es como se ve realmente el software dentro del cuadro en este momento". y luego para conectar las dos líneas esta vez, dibujaría una pila aleatoria de espagueti, posiblemente con saltos, uniones y garabatos.

Finalmente, diría: "Ahora lo que me estás pidiendo que haga es esto ..." y dibuje una forma simple dentro del primer cuadro, tal vez un pequeño semicírculo tocando la línea y luego diga "pero para hacer eso, yo ' tendría que hacer esto ... "y dibujar un tornado en forma de espiral alrededor de la línea y continuar ..." para evitar todo esto ..... "y señalar los espaguetis en la otra caja.

Creo que eso llevaría el punto a casa en aproximadamente 2 minutos. Si insisten en que lo haga de todos modos, documente como lo mencionan otros.


6

¿Cómo puedo explicarle a mi cliente qué tan malo es este código?

Tal vez pueda usar una analogía como la plomería en una casa que con el tiempo, después de arreglos y remodelaciones, se vuelve tan voluble y acoplada que al arreglar una cosa, afecta y posiblemente rompe otra cosa que luego necesita reparación y simplemente no hay forma de que sepa todos los lugares donde esto ocurrirá.

Es mi palabra contra el consultor anterior, entonces, ¿cómo puedo dar ejemplos simples y concretos que un cliente no técnico entendería?

Tienes razón, es una palabra en contra de lo visual que el consultor anterior ha creado en sus cabezas. Mi sugerencia es hacer lo que está pidiendo, dar ejemplos simples y concretos. Como se trata de un rediseño, muestre cómo se muestra un fragmento HTML definido en el código compilado con el resto de una página HTML y cómo los cambios que afectan o no afectan al resto de la página. Quizás ese mismo código compilado representa el marcado después de aplicar alguna regla de "negocios". Muestra la diferencia.

Este es un problema difícil y MUY común. Suerte con ello.


6

Sé honesto y directo.

Pero lo más importante es que no acepte un trabajo que no cumpla con sus expectativas. La mayoría de las personas no se dan cuenta de que un contratista puede despedir a un cliente, pueden y deberían hacerlo si el trabajo es más problemático de lo que vale.


3

Aquí hay una analogía que he usado (aunque no garantizo su efectividad): imagine que su sitio web es una máquina física, como una imprenta mecánica que de alguna manera acepta entradas.

Probablemente piensan que la máquina tiene un componente que hace X y otro que hace Y. En realidad, son 20 máquinas más o menos similares. Algunos de ellos ya no hacen nada, todos intentan preformar las funciones que los otros ya hacen y nadie más que el consultor anterior ha visto algo exactamente como ellos antes.

"¿Ves este artilugio aquí que analiza las variables de publicación y luego envía este componente por un agujero de conejo de if-elses? No hay solo uno de estos, hay uno de estos en cada página (o lo que sea), algunos de ellos desinfectar la entrada y algunos no (o todos no) y sin leer todo no puedo saber cuál ".


"Imagine que su sitio web es una máquina física, como una imprenta mecánica", ¡y está imprimiendo dinero! Pero, debido a que está roto, no está imprimiendo tanto dinero como podría ... eso debería engancharlos, -)
Mawg

2

Un punto que aún no se menciona realmente es que simplemente podría estar sobrepasando lo que su cliente realmente quiere de usted en este caso. Exceder los logros es excelente y puede brindarle mucha satisfacción laboral. Pero si al cliente simplemente no le importa, piensa que el rendimiento actual es "lo suficientemente bueno" y solo quiere algunas actualizaciones menores, puede ser imposible convencerlo de que haga una gran inversión en usted para revisar la base de código.

En ese punto, probablemente tendrá que decidir si se apoya en los principios y se niega a aceptar un trabajo que lo obligaría a poner su buen nombre en un desorden de código embarazoso o si puede taparse la nariz, entrar, hacer el trabajo con cinta adhesiva y salga con su pago.

Sin embargo, si decide continuar con el trabajo de cinta adhesiva, asegúrese de documentar, documentar, documentar y ser lo más transparente posible. Lo último que desea es que se le culpe por algo que sale mal en el futuro que es el resultado de una falla en la aplicación de la que advirtió al cliente, pero que el cliente decidió que no era lo suficientemente importante como para tratar en ese momento.

En lo que respecta a los riesgos de inyección SQL, como otros han dicho, debería ser capaz de demostrarles los peligros de eso de una manera que muestre los riesgos sin realmente hacer nada destructivo en la producción. Pero, de nuevo, si lo ven y no les importa lo suficiente como para pagarle para arreglarlo, ha hecho su diligencia de buena fe en este caso.


0

Es una salsa novata entrar en un proyecto y sugerir una reescritura en primer lugar, realizar un pequeño subconjunto de las modificaciones y usarlas para ilustrar cuánto más simple y barato pudo haber sido. Entonces tiene un caso demostrable de por qué el mayor costo del desarrollo más limpio conducirá a menores costos de mantenimiento y un desarrollo más rápido a largo plazo dado un pequeño costo adicional de fuentes.

Nunca olvides que fundamentalmente estás pidiéndoles que te paguen para hacerte la vida más fácil, en su opinión, la simple necesidad de encontrar 'el tipo' que puede contar con X a un costo Y y aumentar la complejidad de tu proyecto puede eliminar la oportunidad para ti. Es un camino difícil cuando llevas un mes de reescritura y te encuentras con el desarrollador original solo para darte cuenta de que toda la aplicación fue escrita en una ventana extremadamente contratada por un desarrollador que entendió completamente todos los compromisos que se hicieron. Si la aplicación internamente se ve horrible pero externamente funciona bien, como usted dice, es muy probable que este sea el caso. A menudo, la deuda técnica dentro de una base de código es producto de las limitaciones de recursos en las que se desarrolló el código y si no están formando un equipo y en cambio están contratando ...

Sólo digo'


0

Voy a jugar al abogado del diablo aquí (algo así como lo que dice @khrome: "no estás pagando a los clientes para que tu vida sea más fácil"). Incluso iría tan lejos como para afirmar que el caso que presentó es demasiado unilateral porque describió el caso de manera general. La mayoría de los consultores entrantes a un nuevo proyecto arrojarían una mala luz al anterior ... No estoy diciendo que eso es lo que está haciendo aquí, pero hasta que veamos ejemplos, no puedo simplemente tomar su palabra.

Dicho esto, voy a tratar de abordar los problemas punto por punto:

  • Inyecciones SQL . Bien, supongo que el programador estaba usando concatenaciones de cadenas en lugar de consultas parametrizadas y / o procedimientos almacenados. Esto es muy fácil de solucionar, especialmente en ADO.NET ... Personalmente, se lo mencionaría al cliente, pero no le daría demasiada importancia.
  • El HTML se está generando en la lógica empresarial y sería una pesadilla resolverlo . Bien, amigo, este es uno de esos en los que me das más detalles. A menos que esté usando MVC, esta es una tendencia a suceder ... pero no es necesariamente algo malo ... es una de esas cosas en las que la mayoría de los programadores dirían " goto es malo; nunca lo use" pero ¿sabe qué? ¡He usado goto donde tenía sentido! Entonces, ¿estás seguro de que no están usando clases auxiliares que comparten el mismo espacio de nombres que el código de negocio DLL? De nuevo, no es tan difícil de aislar.
  • La lógica de negocios se extiende por toda la aplicación, hay mucha duplicación y un código sin salida que no hace nada. . ¿Y? El cliente solo le pide que cambie HTML / CSS. ¿Por qué te importarían estos problemas?
  • sigue lanzando excepciones que se están sofocando, por lo que el sitio parece funcionar sin problemas . De nuevo, muy vago. Las excepciones son normales en cualquier aplicación, es por eso que tenemos cláusulas try / catch en nuestro código. A menos que surjan en la interfaz de usuario y arruinen la experiencia del usuario (como mostrar HTTP 500 innecesariamente), tampoco creo que esto sea algo que deba interesarle.

En resumen, te aconsejaría que tomes el camino más alto. Si cree que no vale la pena su tiempo y desea reescribirlo a expensas de su cliente, aléjese del trabajo. En serio, al final, el cliente paga por su tiempo para que todo funcione con la menor cantidad de $$$.

En mis muchos años de experiencia en el campo, siempre digo que los mejores programadores que he encontrado son los que pueden hacer que un sistema sea estable escribiendo la menor cantidad de código , no reescribiendo todo .

Editar: Ya veo que mi respuesta no es la más popular (ya esperaba esto) pero mantengo mi respuesta. Edité esto para hacerlo menos sarcástico. ;-)


-1

Ciertamente, los ataques de inyección SQL y otras fallas funcionales en la aplicación tuvieron prioridad, pero también puede "demostrar" la mala calidad del código y las prácticas. Con las herramientas de métricas de código, puede demostrar claramente qué tan malo es el código y mostrarle cuánto aumentará en costo para cualquier cambio futuro y corrección de errores. No estoy familiarizado con el entorno .net, pero estoy seguro de que hay varios para elegir.


¿Por qué el voto negativo en esto? Claro, el cliente puede no ser técnico, pero las métricas de código producen números y todos pueden entenderlos. Especialmente si hay una explicación bien documentada, no demasiado técnica, de lo que significan esos números
Mawg
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.