¿Cuándo está bien sacrificar la "pulcritud" del diseño para realizar un proyecto?

Cuando se trabaja en un producto que debe hacerse pronto y funciona bien, ¿cuándo está bien sacrificar la facilidad de mantenimiento y la "pulcritud" del diseño para poder hacer la cosa y salir rápidamente por la puerta? ¿Y en qué medida está bien, especialmente cuando las técnicas utilizadas para hacerlo "ordenado" son nuevas para mí?

Recuerde que está empleado para mantener un negocio. De alguna manera, su software está afectando el resultado final del negocio. Debe lograr un equilibrio entre una solución técnicamente perfecta y el tiempo de comercialización de su producto y cuánto beneficio obtendrá el negocio de él.

En mi experiencia, los desarrolladores a menudo se preocupan por la perfección técnica. Pero hay razones muy válidas para sacrificar atributos de calidad, como la capacidad de mantenimiento o el rendimiento, para que un producto salga más rápido. Depende del negocio y del producto. Pero "luchar siempre por un diseño perfecto" es un enfoque demasiado simplista.

Al final del día, lo único que importa es el valor para el negocio. Descubra cómo maximizarlo a corto y largo plazo y apunte a ese objetivo.

El término "deuda técnica" es muy útil para ayudar a informar decisiones comerciales como esta. Cualquier trabajo que no haga ahora causará cierta cantidad de trabajo más adelante. Al igual que con las finanzas, asumir deudas es arriesgado, pero puede valer la pena apalancarlo si va a poder pagar la deuda más tarde.

Dicho esto, la deuda técnica no es una proporción de 1: 1 en el momento del reembolso. Los errores son más caros de reparar después del lanzamiento, y el impacto en la productividad futura cuando se desarrolla desde un sistema heredado desordenado puede ser indignante. Podría estar buscando pasar el doble del tiempo arreglando sus errores, o quizás 1,000 veces más horas-hombre y recursos.

Su trabajo en esta decisión es comprender las ramificaciones de las piezas particulares de las esquinas que está considerando y luego comunicar esas ramificaciones a las personas que toman la decisión comercial. Esta habilidad de estimación particular puede requerir mucha investigación y trabajo de su parte para desarrollarse bien en este momento, pero será invaluable durante su carrera.

Cuando se acepta y el propietario / cliente / usuario entiende las consecuencias.

Un plomero tiene que sacar un triturador de basura para su reparación. Mientras tanto, quiero usar el fregadero, pero él tendría que facturarme el tiempo y los materiales para colocar tuberías temporales con cinta adhesiva que podría romperse. Esto también retrasará la devolución al taller de reparación. Si acepto la facturación adicional con el entendimiento de que corro el riesgo de una obstrucción. Hará falta un día más para reparar el desecho y un retraso aún mayor antes de que pueda volver a colocarlo, eso es aceptable.

Puede llegar a tiempo y presupuesto ahora, pero sacrificar / arriesgar una carga aún mayor a largo plazo. Esto puede ser difícil de hacer entender a personas no técnicas, pero para eso está el personal de ventas.

Mucha gente se da por vencida rápidamente cuando aprende algo nuevo y lo hace de la forma en que siempre lo ha hecho. Si este es un patrón, no solo sufrirá su código, sino que sus propias habilidades como programador seguirán siendo limitadas.

Aún así, al final del día, el único software exitoso es el que se envía.

Después de la fecha límite suave pasa. Y aun así, es un grado muy bajo de "OK". Una vez que pasa la fecha límite, es, por supuesto, discutible. Porque esa es la naturaleza de los plazos estrictos.

Además, esto incurre en deuda técnica. Por cada hora / día que pasa cortando esquinas en la mentalidad de git er-done, le costará aproximadamente el doble de tiempo la próxima vez que tenga que tocar este proyecto. Si debe hacerlo, lo mejor es apresurarse, enviar e inmediatamente comenzar a arreglar toda su cinta de pato. Volver a un proyecto hack-eyed años después es una pesadilla. Si nunca lo volverás a tocar, que así sea, a nadie le importará. Pero la única vez que dejé un proyecto para siempre es cuando cambié de trabajo.

Sin embargo, recuerde que cronometrar estas cosas es el trabajo del gerente del proyecto. Si tiene prisa para cumplir con una fecha límite, es culpa del primer ministro. Hazlo bien, hazlo una vez y hazlo con calma y correctamente. La vida es demasiado corta para cualquier otra cosa.

Todas las otras respuestas publicadas aquí son buenas. Sin embargo, me gustaría agregar que, como desarrollador del proyecto, usted es el administrador (protector) del diseño.

Si no defiende la solución técnica adecuada, nadie más se lo prometo. Siempre debe argumentar por hacer las cosas de la manera correcta a su jefe y el primer ministro siempre debe argumentar a favor de la fecha límite.

Con suerte, si se encuentra en una organización razonable, se alcanzará un compromiso que ayude a cumplir con los plazos y al mismo tiempo no se aleje demasiado del diseño.

Dicho esto, no asuma que si no se cumple el plazo del primer ministro, el mundo terminará y el proyecto fracasará. Por lo general, no es tan blanco y negro y la mayoría de las veces la fecha límite del primer ministro es blanda y tiene margen de ajuste.

Casi todas las fechas límite en las que tenía un horario de PM eran en su mayoría artificiales. Sin embargo, lo defenderán con uñas y dientes y fingirán lo contrario porque si el primer ministro presiona la fecha límite, ¡el primer ministro parece MALO!

El hecho de que el primer ministro se vea mal no significa que el proyecto haya fallado. Si comprende esto, se sorprenderá de cuánto puede hacer que un PM se doble.

Cotice al cliente para el diseño aseado. Si esa cita es inaceptable para ellos, vaya al desglose de lo que costará cada componente (generalmente cuesta == tiempo de desarrollo). Deje que retiren los artículos "a la carta" si así lo desean. Muchos saltarán a la hora del afeitado por cosas "inútiles" como pruebas y diseño. Explique los riesgos de este enfoque, pero si aceptan el riesgo, proceda según las indicaciones. Si solo tengo suficiente dinero para un automóvil clunker, entonces voy a comprar un automóvil clunker, incluso si sé que probablemente se descompondrá en 8 meses. Su cliente tiene la responsabilidad de sopesar estos riesgos y aceptar las consecuencias.

Lo único que no desea hacer es decirle al cliente que piense que tiene una pieza de software bellamente diseñada, cuando solo pagó (y recibió) una pieza de basura no probada. Si algo sale mal (lo que probablemente ocurrirá), en el primer escenario se verán mal, pero en el segundo escenario se verá mal.

Es no está bien, pero a veces se tiene que comprometer en aras de terminar un proyecto. La triste realidad es que la mayoría de los empresarios son completamente ignorantes y están más que dispuestos a sacrificar la capacidad de mantenimiento más tarde por algo en este momento. El truco es saber cómo lograr un equilibrio; tal vez el proyecto no sea tan bueno como podría ser, pero mientras no sea un chiquero es un compromiso digno.

Eso depende completamente de la pregunta "¿Usted o alguien más posiblemente querrá modificarlo más tarde?" En caso afirmativo, debe intentar tener un diseño "ordenado", de lo contrario corre el riesgo de tener que tirar todo y comenzar de nuevo 6 meses después.

Por supuesto, puede llevar la limpieza demasiado lejos, pero en general un poco de limpieza le ahorrará trabajo más tarde.