¿Demostrar código incorrecto al cliente?

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.

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í.

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.

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.

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.

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.

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.

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.

¿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.

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.

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 ".

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.

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'

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. ;-)

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.