Lamento decir esto pero,

No querrás escuchar esto, pero no está completamente equivocado .

  

Si está haciendo un trabajo de alquiler para empresas externas como consultor,   y están dispuestos a aceptar lo más abofeteado que puedas   hacer y no quejarse, y estamos dispuestos a volver una y otra vez   Una vez más, para que pueda hacer más trabajo, su jefe está 100% correcto cuando se trata de maximizar los beneficios para su empresa.

Luego está YAGNI : si los proyectos son proyectos únicos que no le costarán nada mantenerlos o reescribir y todo ese tiempo en mantenimiento y reescritura es facturable, hacerlo correcto la primera vez en realidad le está costando aún más dinero. Entonces, tu jefe es 100% correcto de nuevo.

Si sus clientes no se quejan de los costos y la falta de calidad, entonces la calidad no es en cuestión para hacer felices a sus clientes. Parece que los clientes están contentos con la basura, por lo que venderles más basura no es una decisión de negocios difícil.

Todo lo que haga por encima y más allá de lo que el cliente está contento se desperdicia en todas las partes: no lo apreciarán. Tu jefe es 100% correcto de nuevo.

Recuerde que la calidad está en el ojo del espectador. Si satisface las necesidades de los clientes, no les importa la cinta adhesiva ni los perchas que lo hacen funcionar.

Lo que usted valora en gran medida tiene poco o ningún valor directo para sus clientes, ya que no les importa cómo el software hace lo que hace, solo que hace lo que ellos quieren principalmente.

Cada pieza de software eventualmente se degenerará de la entropía a una Big Ball of Mud . Las aplicaciones GUI, especialmente aquellas para Windows escritas en cierto modo de entropía VB más rápido debido a la cultura del conjunto de herramientas.

Si te hace sentir mejor, estás empezando un poco más cerca de la máxima entropía que otras personas.

Personalmente, nunca establecería un precedente con resultados de tan baja calidad, pero tampoco volvería por el nivel hasta el final de clientes que su compañía aparentemente está tratando de atender.

Su administración ha decidido que estos son los clientes que quieren tener y no hay necesidad de tratar de vender al cliente en un software más caro y de mayor calidad si están de acuerdo con la situación.

No va a lograr que la administración cambie, solo sus clientes lo harán. Puedes obtener mejores clientes o conseguir un mejor trabajo.

Suena como mi antiguo trabajo

Esto solía suceder todo el tiempo en mi antiguo trabajo. Estoy de acuerdo en que las ventas impulsan todo. El gerente de la tienda (Conjunto de habilidades: 80% Ventas 20% Gráficos) subestimó constantemente las características que los clientes querían. Un trabajo de 20 horas se vendería a un precio de 10 horas porque el cliente no estaba dispuesto a pagar más o (tiendo a pensar) el gerente de ventas no hizo suficiente hincapié en El valor que el cliente estaba consiguiendo.

El gerente de ventas a menudo mostraba los prospectos de características y widgets que creamos para diferentes clientes. Y, por supuesto, subestimaría esta característica a la nueva perspectiva porque realmente no teníamos que volver a codificar la cosa ... todo lo que teníamos que hacer era copiar y pegar el código de un sitio web diferente y Plop en este sitio. Ya lo habíamos construido.

Después de varias sesiones de gritos de "¿Por qué no puedes hacer esto más rápido ... ya lo hiciste para el cliente x"? y "solo demoraron 10 horas para el cliente y por eso se tardan 16 horas para el cliente z".

Le preguntamos al vendedor, ¿cuál era el objetivo? Dijo que vendiera la mayor cantidad posible de estos widgets por el precio más barato posible.

Le dijimos que somos una tienda de calidad y que hacemos un trabajo de calidad. Le dijimos que al reducir el precio, en realidad estaba diluyendo el valor de nuestro trabajo y al hacerlo, cuando el cliente vuelve a buscar nuevas funciones que no se habían desarrollado anteriormente (es decir, la opción de copiar y pegar desde el sitio x no estaba no estaban) rechazaban los precios y el gerente de ventas se rendía ante la presión.

Decidimos ponerle precio a nuestros widgets a un precio superior tal como está. Cualquier modificación sería extra. Convencimos a la gerencia de que si nos dieran el tiempo para desarrollar estos widgets para que pudiéramos extraerlos de nuestra " Biblioteca de códigos " en lugar de otros sitios web, podríamos construirlos de una manera más genérica para que literalmente podamos caer. en un sitio existente en 2 horas y reciba un pago por 10 horas de tiempo.

Comenzó a venderlos "como están" con cargos premium por modificaciones y pudimos introducirlos y hacer que funcionen en dos horas. También comenzamos a agregar estos widgets a " Nuestro sitio web " y dejamos de usar los sitios web de otros clientes como herramientas de ventas. Solo usaríamos los sitios web de otros clientes para mostrar cómo se podría personalizar el widget " por una pequeña tarifa " para que actúe de esta manera o de la otra.

Para probar nuestro concepto, nosotros (los desarrolladores) nos quedamos hasta tarde después del trabajo algunas noches para crear un widget genérico y ponerlo en nuestra biblioteca de códigos. La vida mejoró. Las discusiones cambiaron de por qué está tardando tanto en ... " Oye, ¿puedes revender este widget que el cliente x quiere? Si es así, ¿qué funciones quieres que agreguemos al modelo básico para ayudarte? vendelo. "

He visto a las empresas hacer esto. Terminan con clientes enojados. Los clientes tienen el hábito de regresar y solicitar nuevas funciones tan pronto como la aplicación comience a ganar dinero para ellos o se integre en su flujo de negocios. Pronto tendrá que decirles a esos clientes que no puede agregar nuevas funciones al desastre que creó, porque ya no puede manejar el código base. O te llevará mucho más tiempo.

Los clientes (incluso en una situación competitiva entre sí) tienden a hablar. Ya sea directamente, por parte de los empleados que cambian de empresa o por reuniones aleatorias en eventos típicos de su línea de negocios (conferencias, exposiciones). Muy pronto le resultará difícil adquirir nuevos clientes si su empresa tiene una mala reputación.

Además, la codificación de baja calidad funciona solo (si lo hace) si limita su empresa a proyectos muy pequeños. Cualquier cosa más grande o más compleja perderá tiempo (y eso por dinero) al instante, incluso dentro del primer ciclo en vivo del proyecto, simplemente gastando más tiempo en depurar que lo estimado.

Enséñale sobre la deuda técnica

Lo que tienes que hacer es hacer que se dé cuenta de las consecuencias de las decisiones que toma. Rápido y sucio puede estar bien a veces porque puedes hacer las cosas más rápido, pero tiene consecuencias a largo plazo.

Si, por ejemplo, el proyecto nunca tuvo la intención de tener una base de código grande, rápido y sucio podría ser la manera perfectamente correcta de tratar ese proyecto.

A Ward Cunningham se le ocurrió la brillante metáfora, "Deuda técnica". Al igual que podría tomar un préstamo en el banco para obtener algo más rápido (en lugar de ahorrar), tiene que pagar más a largo plazo porque tiene que pagar intereses. Esto puede ser bueno, si el valor de obtener su "cosa" más rápido supera el costo de los intereses.

Las soluciones rápidas y sucias son como un préstamo en el banco. Y nuevamente, si el valor de obtener una característica anterior supera el costo de la limpieza posterior, entonces tomar el préstamo podría ser el enfoque correcto.

Pero si tomas más y más préstamos en el banco, al final pagas todos tus ingresos en intereses. Igual con la deuda técnica. Si ha realizado demasiadas soluciones rápidas y sucias, su deuda técnica será tan alta que su progreso se detendrá.

He visto que esto suceda. En un proyecto en el que trabajé, la deuda técnica era tan severa que no tuvimos ningún progreso en serio durante 3 meses, solo intentamos corregir errores, lo que introdujo nuevos errores, etc.

Si puede hacerle entender completamente el concepto de deuda técnica, entonces debería poder tomar las decisiones correctas (buena suerte, es un problema). Tenga en cuenta que la solución correcta a veces también significa rápida y sucia.

Una última cosa que podría señalar es que los desarrolladores son más productivos si están muy motivados;)

El costo del mantenimiento es a menudo mucho más alto, y con frecuencia la mayoría del costo, de una pieza de software.

Si programa rápido y sucio, entonces el mantenimiento será un orden de magnitud más difícil, y el costo también lo es.

Si construyes todo tu software rápido y sucio, será un desastre y tus clientes lo notarán. A largo plazo, si sus productos siguen siendo malos y con muchos errores, los perderá. Los clientes querrán pagar a su competidor un poco más por un producto de buena calidad que sufrir sus errores.

¿Tu jefe no entiende esto?

En todos los casos, excepto en los más raros, no puede convencer a alguien que es increíblemente miope de que más tiempo es casi siempre mejor en nuestra profesión. Lo siento, pero esa es la verdad; las personas miopes sacrificarán todo en el camino para cosechar los beneficios ahora, y casi siempre sufrirán al final.

A veces, la solución correcta es para cambiar las posiciones a un lugar donde las personas sean lo suficientemente inteligentes como para comprender los beneficios de la calidad y no sean miopes.

Nota: esta respuesta toma una estrategia de comunicación empresarial que intenta utilizar la razón para asegurarse de que todos obtengan lo que desean. Si el problema es simplemente que hacer ingeniería de baja calidad está minando tu voluntad de vida o que tu jefe es un conductor esclavo y parece que no hay un final a la vista, de hecho puede ser el momento para un cambio de escenario.

No estás hablando el idioma de tu jefe. Parte de su trabajo es darle información a su jefe para que pueda tomar decisiones, y usted necesita cambiar su estrategia de dar información. Habla en lenguaje de ingeniería, y lo que él necesita escuchar es sobre riesgo, costo, inversión y rendimiento. También debe estar un poco a la defensiva y asegurarse de que haya un buen registro de lo que le informas de.

Hay dos partes en esto:

La primera es la comunicación de su estimación y de la idea de que no es una meta o un plan. Podría escribir volúmenes aquí, pero básicamente sería una copia de todo lo que aparece en " Estimación del software de McConnell: Desmitificando el Arte Negro ", un libro por el cual debes correr, no caminar, a tu librería. ¡Tenga cuidado de distinguir entre estimaciones, objetivos y compromisos, y asegúrese de hacer una estimación real antes de comprometerse con cualquier cosa!

La segunda es la comunicación de los riesgos reales en los que su jefe estaría interesado. En pocas palabras, esto significa que debe decirle a su jefe que la implementación que podría completarse en 1,5 días cumplirá los requisitos básicos, pero aumente significativamente el riesgo de que los cambios y características futuros requerirán mucho más tiempo del que parece que necesitan. Si pregunta por qué, utilice la analogía de la construcción de la casa: si su software es una casa, cada cambio es una nueva pieza de mobiliario y cada característica es un piso nuevo. Si no tiene una base sólida y remodela / restaure un poco cada vez que haga algo, eventualmente estará en una situación en la que se necesitará una remodelación importante solo para soportar el peso y el tamaño de un nuevo tratamiento para ventanas. y toda la casa tendrá que ser reconstruida si quiere soportar cuatro pisos nuevos y una cubierta.

Esto vuelve a poner el balón en la cancha de su jefe: usted le ha dado información y él tiene que decidir. Tendrá que pensar si habrá o no cambios futuros y si quiere o no ignorar la posibilidad. A partir de ahí, si se decide que el camino a seguir es rápido y de baja calidad, asegúrese de (con mucho tacto) recordatorios sobre esa decisión en prácticamente cada pieza de comunicación y documentación que pueda. Envíe un correo electrónico de seguimiento que confirme la decisión y los riesgos que comunicó, comprometiéndolos a escribir. Tome nota de la estrategia de ingeniería y los riesgos en su especificación.

Cuando llegue el día en que el cliente quiera que se coloque una piscina en el piso 50, y verá que los últimos 20 pisos fueron construidos con palos y arena, asegúrese de que la gran estimación de grasa que produce para ello sea técnicamente justificable y prepárese para desplegar el rastro de papel de las facturas de licitadores para ilustrar por qué va a costar tanto.

Si realmente ha presentado todos esos argumentos y todavía los elimina, entonces es su deber como profesional elevar esta preocupación a una instancia superior. Sí, eso significa pasar por encima de su cabeza. La razón de ello es simplemente que su jefe es un peligro para la empresa.

Mi experiencia con estos chicos es que eventualmente llevarán a su organización al fracaso o al menos a la mediocridad. Su producto apestará y sus clientes lo dejarán.

Para el registro: asumo que el negocio principal de la organización es el desarrollo de software y el producto es importante y no algo desechable.

Tu jefe podría tener razón. Puedo pensar en escenarios donde este tipo de codificación es suficiente. Digamos que escribes guiones desechables para algún tipo de análisis de datos o sitios web poco atractivos donde puedes ver algunas páginas y tener una idea de lo que está sucediendo. Este tipo de cosas no tienen que ser overengineered, ya que es poco probable que se mantengan. Si eso es lo que los clientes quieren, eso es lo que obtendrán los clientes.

Ahora bien, también podría ser que su jefe esté equivocado y que los clientes no aprecien los productos que funcionan mal. Este es el caso más frecuente.

También podría ser una opción para llegar a algún tipo de medio feliz. Lo principal es que si algo no funciona, entonces necesita cambiar. Claramente, su jefe no está satisfecho con la forma en que el proceso de desarrollo está afectando el negocio tal como está. El tiempo de comercialización es tan importante como la calidad del producto. Lo que debe hacer es asegurarse de que su equipo pueda producir un producto de calidad en un plazo que no destruya la comercialización del producto. Si los principios de ingeniería se usan correctamente, no debería destruir la productividad de un equipo. En todo caso, el uso de prácticas sanas debería acelerar el proceso de desarrollo Y aumentar la calidad.

Sí, podemos hackear eso juntos hoy.

Si lo hacemos de esa manera, tendrá más errores que el promedio y retrasará seriamente el desarrollo futuro. Hackear esto juntos es algo que podemos hacer una o dos veces. Piense en ello como un rascacielos, ya podríamos tener una buena base, y tenemos 10 pisos que también son muy buenos. Si lo desea, podemos juntar rápidamente algunas carpas y cajas en el piso 11, tal vez incluso construir una 12 ° piso de tiendas y cajas, pero estás jodido por ir más allá de eso. Tenemos que sacar a todos de esos dos pisos, configurarlos, volver a entrenar todo, y construirlo de nuevo solo para obtener el piso 13.

Si intentamos construir un piso 13 con cajas y carpas, podríamos derrumbar tres pisos en cualquier momento aleatorio, y nos puede llevar meses solo obtener los bloques de jenga y el duplo super-pegado en los lugares correctos.

¿Esto es aceptable para ti?

W. Edwards Deming es mejor conocido por su trabajo en la reconstrucción de la fabricación japonesa después de la Segunda Guerra Mundial. A menudo se pasa por alto el hecho de que su trabajo es más sobre administración que sobre manufactura. De hecho, una sección importante de su libro Out of the Crisis trata sobre la mejora de la calidad en las organizaciones de servicio. Sus ejemplos de organizaciones de servicio incluyen software, banca, seguros e iglesias.

Deming sostiene, con una gran cantidad de evidencia del mundo real que lo respalda, que el aumento de la calidad aumenta las ganancias.

Puede analizar el desarrollo de software como procesos de negocio. Al igual que la fabricación, produce productos intencionales, no intencionales, directos e indirectos.

Los productos directos intencionales de fabricación y programación incluyen grifos y código fuente. Los productos indirectos intencionales incluyen deuda e ingresos.

Los productos no intencionales de los procesos de fabricación incluyen llaves que tienen defectos de fabricación, incendios accidentales, lesiones, alta rotación de personal y robo de empleados. Los productos no intencionales de los procesos de programación incluyen errores, dificultades de mantenimiento, dificultades de escalabilidad, problemas de seguridad, alta rotación de personal y robo de empleados.

Cada uno de esos "productos" está sujeto a variación, análisis estadístico y mejora de procesos.

En su caso, probablemente necesite enumerar y cuantificar los productos no intencionales de sus procesos de desarrollo de software y gestión de proyectos.

Deming es una de las principales razones por las que Japón es una potencia mundial en la fabricación. El Premio Deming lleva su nombre.

Esto puede parecer obvio, pero creo que necesitas encontrar un camino intermedio. No descuente la actitud de su jefe de las manos. Su opinión sobre él es probablemente tan extraña para él como la suya para usted.

Obviamente, cualquiera de los dos extremos no es bueno para nadie, así que trata de negociar un término medio.

No creo que sea posible. Las diferentes compañías tienen diferentes culturas y si la cultura de su empresa actual (rápida y sucia) no le conviene, entonces creo que debería seguir adelante. Algunas otras compañías tienen una opinión opuesta y allí trabajarás con personas que piensan lo mismo que tú.

Realmente no quiero entrar en la discusión sobre qué tipo de cultura es mejor (vea las otras publicaciones si está interesado), todo lo que digo es que será beneficioso para su salud mental si trabaja en una empresa con el mismo enfoque.

He revisado todas las preguntas y veo que nadie ha tomado la perspectiva de la seguridad ...

Sí, otros mencionaron el tiempo de depuración, pero en este caso, la depuración solo se realiza al nivel 'hey que finalmente funciona'

En mis proyectos (pequeños y / o grandes) mantengo un alto nivel de atención a los ataques y posibles agujeros de seguridad.

Tomar esto en cuenta y probarlos toma una cantidad de tiempo considerable, pero al menos de esta forma no me acusarán de no hacer lo mejor que puedo cuando sucede algo malo.

Apuesto a que cuando vayas rápido y sucio, olvídate de sanear algunas variables, olvídate de hacer algunas comprobaciones en las funciones y, por lo tanto, haz que tu proyecto sea un buen punto de partida para los piratas informáticos.

Cuando mi jefe me pregunta por qué algo me demoró tanto, le muestro todas las comprobaciones de seguridad y funciones que he incorporado para prevenir cosas como la inyección, la inclusión, los bucles infinitos e incluso las medidas de seguridad para cuando algo se hackea. hace un daño mínimo

Hacer las cosas rápido y sucio puede hacerte más lento incluso antes del almuerzo. Muy a menudo empezará a doler incluso antes de que esté lo suficientemente completo para intentar que un cliente lo acepte.

Quizás pueda probar la metáfora técnica de la deuda, la carga de los pagos de intereses será mayor que el ingreso después de algún punto.

Dirigirse hacia una reescritura también es una oportunidad para que sus clientes prueben una empresa de desarrollo diferente (si queremos comenzar desde cero, también podrían hacerlo).

Si no tiene empleadores alternativos en su área, es posible que haya más clientes que gastar también. Básicamente, tu jefe puede seguir haciendo lo que está haciendo, no hay competencia que lo haga mejor. Tal vez comience su propio negocio? ;-)

Alternativamente, puedes decirle que siempre haces las cosas "rápido y sucio" y que haces lo tuyo.

Lánzale las matemáticas. Desafortunadamente, no tengo los libros disponibles para proporcionar citas (espero que alguien pueda ayudarme), pero uno o ambos de The Pragmatic Programmer y Code Complete 2 tienen una sección que hace referencia a estudios que muestran el impacto en los costos de hacer las cosas rápidamente. 'n' sucia, en lugar de tomarse el tiempo para arreglarlo más tarde. Otros carteles han proporcionado un montón de argumentos de puntos, pero dependiendo de la actitud de su jefe, puede responder mucho mejor al apoyo de los estudios existentes. Puede que piense que solo estás haciendo el alboroto para amortiguar tu tiempo y facilitar tu propia carga de trabajo. Mostrarle que es un hecho aceptado por la industria, en lugar de solo tu opinión, podría ser el boleto.

De alguna manera estoy en una situación similar a la tuya. Trabajo para una empresa de servicios, por lo que escribo aplicaciones personalizadas para diferentes clientes. Las personas que están a cargo de entregar la aplicación (como los gerentes de proyecto, los ejecutivos de proyecto, etc.) realmente no se preocupan por la calidad del código (aunque dicen que lo hacen), todo lo que les importa es entregar las cosas a tiempo para poder maximizar la lucro. Constantemente me piden que escriba características en poco tiempo.

Una técnica que utilicé para mantener la calidad del código mientras cumplía con el plazo es la refactorización continua. Si me piden que escriba la característica A en 1 día, lo que en realidad tomará de 3 a 5 días para escribir con alta calidad, haré la entrega rápida y sucia. Pero mientras hago la manera rápida y sucia, tomo notas sobre el área que se puede / debe mejorar. Luego, más adelante en el ciclo de desarrollo, encontraré fragmentos de tiempo aquí y allá para refactorizar mi código en la característica A.

Al principio, fue una experiencia dolorosa refactorizando mi código rápido y sucio; Recuerdo algunos casos en los que reescribí casi por completo una característica durante la refactorización. Pero a medida que hago más y más refactorización, mi código rápido y sucio comenzó a no ser tan sucio. Comencé a desarrollar un mejor sentido natural del diseño modular, de modo que los códigos que escribo se vuelven cada vez más modulares incluso si estoy en el modo rápido y sucio.

No está mal pensar que la calidad del código no importa, porque a mucha gente en realidad no le importa. ¿Realmente te importa la calidad de diseño del circuito dentro de tu televisor SONY siempre que muestre una buena imagen de alta definición y funcione bien entre 5 y 10 años?

Sin embargo, como desarrollador, deberías preocuparte realmente por la calidad del código porque sabes el beneficio que tiene. Es poco probable que su jefe cambie de opinión acerca de la calidad del código, a menos que experimente algunas crisis en las que la calidad del código salve su día o cuando vea personalmente la correlación entre el beneficio y la calidad del código.

Debido a la falta de conocimiento de su jefe sobre la calidad del código, no significa que deba comprometer la calidad del código (sin embargo, es una buena idea mantener abierto el canal de comunicación con su jefe sobre la calidad del código). Esfuércese por encontrar el punto de equilibrio entre la calidad del código y el programa de desarrollo. No puede escribir un código de buena calidad para el calendario actual dado que no significa que no pueda mejorar la calidad en los horarios futuros, ¿verdad?

Tengo la fuerte sensación de que no hay nada que puedas decir en este caso. Pero algunos puntos que menciono:

Solucionar problemas lleva más tiempo

Cuando copia y pega el código en todo el lugar, cuando encuentra un error en ese código, demorará más en solucionarse y demorará más en probarlo. Por lo tanto, perderá horas adicionales en la fase de soporte (como supongo que no tiene una fase de prueba integrada con la mentalidad de 'salga de la puerta') .

Añadir una nueva función lleva más tiempo

Agregar una nueva característica en el código de espagueti toma mucho más tiempo. Y como es un lío de copiar y pegar, tienes que modificar el código en muchos lugares. Esto a su vez creará errores, o una funcionalidad inesperada en varios lugares. Por lo tanto, tendrás que perder horas extra en la fase de soporte.

Aumentar la duración de los elementos y la terminología de la IU para nuevos clientes se demora

Empresa en la que estoy trabajando ahora mismo, su cliente web comenzó siendo un código de espagueti para copiar y pegar. Antes de comenzar, tardé 2 semanas en personalizar el cliente web para un nuevo cliente.

Después de más de unas cuantas tardes, ahora toma una tarde. Todavía estoy trabajando y ajustándolo para que tome menos tiempo.

Si su jefe quiere que un producto que sea fácil de vender sea para diferentes clientes, necesita invertir el tiempo para asegurarse de que no perderá tiempo en desollar su producto cuando podría venderles nuevas funciones.

Va a ser difícil, pero necesita hacer que su jefe entienda que a menos que pase un tiempo ahora para asegurarse de que se haga bien, perderá muchas más horas en errores en el futuro, y en realidad le llevará más tiempo Prepare el producto para un nuevo cliente en el futuro.

Todo lo que le importa es el resultado final, por lo que debe hacerle entender que la codificación de esta manera no lo ayudará y solo lo obstaculizará.

La mejor respuesta posible sería desde el enfoque ágil:

lanzar temprano, lanzar a menudo

Liberar temprano es bueno para su compañía porque comienza a recibir el pago temprano. El primer punto de lanzamiento es cuando su producto tiene suficiente funcionalidad para que pueda usarse al menos en algún aspecto. Así que agrega valor de la empresa cliente. Por eso es inteligente desarrollar módulo por módulo.

Liberar a menudo es bueno para su cliente porque pronto obtendrán lo que necesitan . Intencionalmente no escribí desea, porque el resultado final a menudo difiere de la idea al principio.

Si nada más, esto satisfará más a sus clientes, ya que se sentirán más involucrados y usted estará iterando su producto paso a paso.

Una cosa que descubrí fue que una base de código limpia puede soportar una piel de cruft sin demasiados problemas. Si tiene un CMS central que personaliza para diferentes personas, cualquier problema en el núcleo lo perseguirá. Pero un plugin específico para el cliente mal probado y mal hecho puede funcionar sin muchos problemas.

En tu caso, parece que no has creado el núcleo limpio, así que estás bastante jodido. Sin embargo, debería preferir pedir tiempo para mejorar su base de código central, lo que debería beneficiar a sus clientes existentes y acelerar el desarrollo futuro.

Dígale que puede ahorrar dinero. Roger Pressman escribió que usted gasta el 20% de su dinero en la creación del software y el 80% en mantenerlo.

Si necesita construir rápidamente para no perder un contrato, hágalo, pero en una sucursal alternativa. Después de eso, hazlo de nuevo de la manera correcta.

Quiero cortarlo en corto.

• Si el código se mantendrá durante mucho tiempo, la calidad del código es un problema.
• Para el código de creación de prototipos, no es realmente un gran problema. Por lo general, la gente tira ese código.
• La calidad del código escrito por un programador se logra a través de la práctica. A medida que obtengamos experiencia, lograremos una buena velocidad vs. Relación de calidad. He visto programadores que solían preguntar: "Dame 3 días para actualizar con el estándar de codificación". Esto es una mierda completa. ¿Por qué están cuidando mientras escriben el código? Una vez que se realiza la prueba, y el ir hacia las actualizaciones estándar podría dar lugar a problemas.
• Incluso si no diseñamos algo oficialmente, tendremos algún tipo de diseño en mente antes de escribir el código. En estas situaciones, la calidad depende de los pensamientos del desarrollador.
• Los gerentes son conocidos por sus horarios, esfuerzo y presupuesto. Si puedes hacer algo en un límite dado, acéptalo. De lo contrario, dile lo que puedes hacer dentro del período dado. O haga sugerencias sobre las personas que podrían contribuir bien para el problema en particular

¿Cómo obtener lo mejor de ambos mundos? Utilice las fábricas de software. Invierta su capacidad mental en la creación de herramientas que puedan hacer lo que se puede repetir. Por ejemplo, eche un vistazo a Ruby on Rails o si es una persona de .NET, consulte ASP.NET MVC combinado con un paquete nuget llamado MVCScaffolding . Actualmente estoy investigando esta herramienta y personalizándola para generar lo que necesito para mi flujo de trabajo. La generación de un sitio web CRUD simple y respaldado por una base de datos es tan sencillo como el controlador Scaffold. Ahora puedo pasar mi tiempo personalizando la interfaz de usuario y refinando la lógica de negocios que impulsa la aplicación.

Como mencioné, puede personalizar la herramienta (por ejemplo, cambié la plantilla de controlador predeterminada para usar mis utilidades internas de IRepository / IUnitOfWork que me permiten cambiar fácilmente entre los almacenes de datos de EF e InMemory para las pruebas). En su mayor parte, la mayor parte de mi desarrollo se dedica a refinar el modelo de objetos para admitir los escenarios de uso empresarial.

Presentaré a tu jefe a LulzSec. Es posible que suplicen que la calidad del código en las aplicaciones web no importa ...

MENTIRA : cuando su jefe pregunta qué tan rápido es "rápido y sucio", dígale "que fue la estimación rápida y sucia".

Muchas de las respuestas en este hilo se basan en el razonamiento. La última falla en este enfoque es que estás hablando con un hombre de negocios .

El problema es que su jefe, al igual que la mayoría de los líderes empresariales en entornos de PYME, no está realmente preocupado por la visión a largo plazo. No importa el razonamiento que aportes, si incluso sugieres que hay una opción más rápida, tomará esa opción el 99% del tiempo. A los jefes les gusta sacar del aire figuras arbitrarias que apoyan el lanzamiento de ventas, y luego los equipos de desarrollo absorben el daño en horas extras y bajos salarios. Los clientes tienen expectativas irracionales basadas en la ignorancia, y los malos jefes están muy dispuestos a complacerlos.

¿Quién está obteniendo el beneficio? ¿Qué está haciendo este proceso para su carrera a largo plazo? Devalúa el trabajo y, en última instancia, el valor de su habilidad. Incluso si es un contratista a corto plazo, piense en el efecto a largo plazo en la industria de reducir el costo del trabajo razonable.

Por supuesto, corta tu prenda de acuerdo con tu tela, pero "rápida y sucia" no es una opción . Si el cliente solicita una característica, esa característica necesita un nivel de tiempo base para completar un estándar razonable . No proporcionar tiempos para nada menos que una implementación razonable.