¿Cómo equilibras entre "hazlo bien" y "hazlo lo antes posible" en tu trabajo diario? [cerrado]

180

Me encuentro reflexionando sobre esta pregunta de vez en cuando, una y otra vez. Quiero hacer las cosas de la manera correcta: escribir código limpio, comprensible y correcto que sea fácil de mantener. Sin embargo, lo que termino haciendo es escribir parche sobre un parche; solo porque no hay tiempo, los clientes están esperando, un error debe repararse de la noche a la mañana, la compañía está perdiendo dinero por este problema, un gerente está presionando mucho, etc., etc.

Sé perfectamente que a largo plazo estoy perdiendo más tiempo en estos parches, pero como este tiempo abarca meses de trabajo, a nadie le importa. Además, como solía decir uno de mis gerentes: "no sabemos si habrá un largo plazo si no lo arreglamos ahora".

Estoy seguro de que no soy el único atrapado en estos infinitos ciclos de elección real / ideal. Entonces, ¿cómo ustedes, mis compañeros programadores, lidian con esto?

ACTUALIZACIÓN: Gracias a todos por esta interesante discusión. Es triste que tantas personas tengan que elegir diariamente entre una cantidad y una calidad de su código. Aún así, sorprendentemente, muchas personas piensan que es posible ganar esta batalla, así que gracias a todos por este aliento.

Flot2011
fuente
12
Simple: hazlo bien y hazlo rápido
ren
158
@ren: Bueno, supongo que no eres un programador, eres un administrador :-)
Flot2011
44
Obligatorio. xkcd.com/844
MikeTheLiar
55
Hazlo lo antes posible. Entonces, si aún tienes tiempo, hazlo bien.
Laurent Couvidou
8
Como dice el tío Bob: la manera lenta es la manera rápida. Tómese el tiempo necesario para escribir esas pruebas unitarias y escriba bien su código. Esto podría ocasionar que tome algún tiempo más para la función a ser implementado, pero se ahorrará tiempo en el largo plazo, ya que será más fácil para que otros puedan modificar y corregir errores en.
martiert

Respuestas:

106

En realidad, esta es una pregunta muy difícil porque no hay una respuesta absolutamente correcta. En nuestra organización, hemos estado implementando mejores procesos para producir un mejor código. Actualizamos nuestros estándares de codificación para reflejar cómo nosotros, como grupo, escribimos código, y hemos instituido un ciclo muy fuerte de prueba / refactorización / diseño / código. Entregamos continuamente o al menos lo intentamos. Como mínimo, tenemos algo que mostrar a los interesados ​​cada dos semanas. Sentimos que somos artesanos del software y la moral es alta. Pero, a pesar de todos estos controles y equilibrios, sufrimos el mismo problema que usted.

Al final del día, estamos entregando un producto a un cliente que paga. Este cliente tiene necesidades y expectativas, realistas o no. A menudo, el equipo de ventas nos mete en problemas solo para obtener una comisión. A veces, el cliente tiene expectativas de puesta en marcha que no son realistas o exigen un cambio a pesar de que tenemos un contrato vigente. Las líneas de tiempo suceden. La PTO y los días perdidos durante un sprint pueden suceder. Todo tipo de pequeñas cosas pueden culminar en una situación en la que nos vemos obligados a entrar en el enigma de "hacerlo bien" o "hacerlo lo antes posible". Casi siempre, nos vemos obligados a "hacerlo lo antes posible".

Como artesanos del software, desarrolladores, programadores, personas que codifican un trabajo, nuestra inclinación natural es "hacerlo bien". "Hazlo CUANTO ANTES" es lo que sucede cuando trabajamos para sobrevivir, como lo hacemos la mayoría de nosotros. El balance es duro.

Siempre empiezo acercándome a la gerencia ejecutiva (soy Director de Desarrollo de Software y un desarrollador activo en ese grupo) para defender el cronograma, el equipo y el trabajo que se realiza. Por lo general, en ese momento me dicen que el cliente tiene que tenerlo ahora y que tiene que funcionar. Cuando sé que no hay espacio para negociar o dar, vuelvo y trabajo con el equipo para ver qué esquinas se pueden cortar. No sacrificaré la calidad en la función que impulsa la necesidad del cliente de obtenerla lo antes posible, pero algo saldrá y será empujado a otro sprint. Esto casi siempre está bien.

Cuando no puede entregar porque hay tantos errores, la calidad del código es mala y empeora, y los plazos se acortan, entonces se encuentra en una situación diferente a la que describo. En ese caso, la mala gestión actual o pasada, las malas prácticas de desarrollo que condujeron a una mala calidad del código u otros factores pueden llevarlo a una marcha de la muerte.

Mi opinión aquí es hacer todo lo posible para defender el buen código y las mejores prácticas para comenzar a sacar a su empresa de las trincheras. Si no hay un solo colega dispuesto a escuchar o pelear por el grupo en contra de la gerencia, entonces podría ser el momento de comenzar a buscar un nuevo trabajo.

Al final, la vida real triunfa sobre todo. Si está trabajando para una empresa que necesita vender lo que está desarrollando, entonces encontrará esta compensación diariamente. Solo al esforzarme por lograr buenos principios de desarrollo desde el principio, he tenido éxito en adelantarme a la curva de calidad del código.

El empuje y atracción entre desarrolladores y vendedores me recuerda una broma. "¿Cuál es la diferencia entre un vendedor de autos usados ​​y un vendedor de software? Al menos el vendedor de autos usados ​​sabe que está mintiendo". Mantenga la cabeza en alto e intente "hacer lo correcto" a medida que avanza.

Akira71
fuente
14
"A menudo, el equipo de ventas nos mete en problemas solo para obtener una comisión" . ¿En qué momento consideraría que las ventas deben ser responsables de vender algo que la empresa no puede entregar, suponiendo que haya una? ¿Tiene ejemplos en los que han cruzado la línea entre el marketing agresivo y la sobreventa?
Tom W
8
@TomW Tengo varios ejemplos internos, detalles que no pude publicar aquí, pero cuando sucede, casi siempre sucede cuando necesitamos una cuenta de referencia o cerca del final del trimestre. Tenemos algunos vendedores muy buenos y otros no tan buenos. Recientemente ha habido un gran cambio en la limpieza de la casa una vez que se determinó que el desarrollo no era el problema y que toda la estructura de ventas cambió para mejor. Las cosas han ido maravillosamente desde entonces. Me encantaría ser más específico, pero no puedo.
Akira71
99
+1 - "No sacrificaré la calidad en la función que impulsa a los clientes a obtenerla lo antes posible, pero algo funcionará" ... eso fue fantástico.
Joel B
59
@TomW: siempre me gusta señalar que el principal arquitecto naval del Titanic que advirtió contra la reducción de costos (Thomas Andrews) se cayó con el barco mientras que el tipo de ventas / marketing que instó a reducir los costos y hacer las cosas lo antes posible (Bruce Ismay) escapó en un bote salvavidas
jfrankcarr
44
Me hubiera encantado tener el tiempo para escribir una respuesta como esta, pero tengo un cliente que le está hablando por teléfono a mi jefe. "A menudo, el equipo de ventas nos mete en problemas solo para obtener una comisión". Lo mismo aquí ... ¡pero de alguna manera todavía obtienen esos bonos!
Kenzo
62

Una cosa que me di cuenta en mi carrera es que siempre hay tiempo para hacerlo bien. Sí, tu gerente podría estar presionando. El cliente puede estar enojado. Pero no saben cuánto tardan las cosas en hacer. Si usted (su equipo de desarrollo) no lo hace, no se está haciendo; tienes todo el apalancamiento.

¿Porque sabes lo que realmente hará que tu gerente te empuje a ti oa tu cliente a enojarse? Mala calidad .

Telastyn
fuente
43
Si bien generalmente hay tiempo para hacer un buen trabajo, generalmente no hay tiempo para hacerlo perfectamente. Hay un mundo de diferencia entre los dos.
Donal Fellows
2
@DonalFellows, por supuesto. 'Correcto' siempre es "seguir las mejores prácticas, utilizando nuestra mejor comprensión del problema en este punto, lo mejor que podamos". La gente comete errores. Cambio de requisitos. Las mejores prácticas cambian. No corte esquinas y refactorice cuando sucedan cosas .
Telastyn
3
@DonalFellows - "El enemigo de la excelencia es la perfección". Un programa escrito de manera sostenible, que cumple con los requisitos de los clientes y lo hace con un rendimiento aceptable, es un programa que está "hecho". Nada de torre de marfil al respecto.
KeithS
1
@DonalFellows Nadie usó la palabra perfecto, una solución perfecta es una solución incorrecta, Telastyn está hablando de una solución correcta. La solución correcta es la que cumple con los requisitos y es poco probable que cause problemas en el futuro y sea fácil de manejar en caso de que lo haga. Los absolutos siempre están mal.
Jimmy Hoffa
77
+1 - Para Telastyn, mientras que todos los clientes quieren que se hagan sus cosas ahora. MUCHO MÁS los clientes quieren que sus cosas funcionen más que hacerlo ahora. Parece que todos los que no están de acuerdo con Telastyn afirman que perderán un cliente si no se hace rápidamente. Esa es, con mucho, la excepción y no la regla. Cuál es la regla, que la mayoría de las personas que no están de acuerdo, es que ignoran que perderán muchos más clientes al entregar productos de mala calidad. La afirmación de que el cliente lo quiere ahora es la excusa habitual de las personas a las que no les importa la calidad. Así que soy escéptico sobre el riesgo reclamado.
Dunk
21

Esto se reduce a lo que comencé a pensar como "El conflicto eterno" (entre negocios e ingeniería). No tengo la solución, ya que es un problema que nunca desaparece, pero puedes hacer cosas para ayudar a mitigar.

  • Comunicar valor

Lo que la gente a menudo no se da cuenta es que, como ingenieros, estamos asumiendo que el problema del "negocio exitoso" siempre es un hecho. Queremos que nuestro código sea agradable, ordenado y fácil de mantener para que podamos agregar nuevas funciones y ajustar las existentes rápidamente y con un mínimo de clientes haciendo QA por nosotros descubriendo casos extraños que hubieran sido frustrados por un mejor código. Mantener a los clientes y mantener una ventaja competitiva con características y delicadeza que nadie más puede producir con la suficiente rapidez son dos ventajas comerciales a las que contribuye un buen código e informan en gran medida la razón por la que queremos un mejor código en primer lugar.

Así que explícalo. "Queremos hacer X en nuestra base de código porque si no lo hacemos, impactará negativamente en el negocio debido a Y" o "... porque mejorará nuestra capacidad de seguir siendo competitivos al mejorar nuestra capacidad de cambiar nuevas mejoras y características más rápido ".

Y haga todo lo posible para tratar de obtener evidencia tangible de que las mejoras están funcionando. Si mejorar algún subconjunto de una aplicación resultó en una función / mejora más rápida, verifique cualquier herramienta de trabajo atrasado que pueda estar usando para evidencia de ello y apúntela en las reuniones apropiadas.

  • Pon al equipo en la misma maldita página

Los egos son a menudo un problema. Una cosa que los equipos de ingeniería necesitan con urgencia es establecer el valor de tener algún tipo de enfoque consensuado para resolver ciertos tipos de problemas en lugar de que todos hagan su propia taza de Kool Aid d'jour porque saben más. Está bien creer que la preferencia del otro tipo es peor que la tuya, pero valora la coherencia en lugar de tener más razón si su enfoque es viable y es un argumento que no puede ganar. El compromiso por el bien de la consistencia es clave. Cuando las cosas son consistentes, es más difícil hacerlas mal, ya que la forma establecida y consistente también será la más rápida.

  • Elige las herramientas adecuadas

Hay dos escuelas de marcos / conjuntos de herramientas / bibliotecas / lo que sea. "Configura el 99% para mí, así que tengo que saber / hacer muy poco" vs. "mantente fuera de mi camino cuando no te quiero allí, pero ayúdame a hacer bricolaje muy rápida y consistentemente con las cosas que realmente quiero para usar en el principio de zanahoria en lugar de palo ". Favorecer el segundo. La flexibilidad y el control granular nunca deben sacrificarse en el altar de un cambio rápido porque, por ejemplo, "no podemos hacer esto porque nuestras propias herramientas no nos lo permiten" nunca es una respuesta aceptable y la pregunta siempre surgirá Ingeniería de producto trivial / desechable. En mi experiencia, las herramientas inflexibles casi siempre se rompen de par en par o se solucionan de manera poco elegante y hacen un gran desastre gigante inmanejable. Más a menudo que no, las soluciones flexibles / más fáciles de modificar son igual o casi tan rápidas a corto plazo, independientemente. Rápido, flexible y fácil de mantener son posibles con las herramientas adecuadas.

  • FFS, si los ingenieros no deciden, al menos obtenga información del ingeniero al elegir las herramientas

Tengo la sensación de que esta es una pregunta de perspectiva del desarrollador, pero he estado en demasiadas situaciones en las que las decisiones tecnológicas se tomaron con cero aportes del ingeniero. ¿Qué demonios es eso? Sí, en última instancia, alguien debe hacer la última llamada, pero obtener opiniones calificadas si es un gerente no técnico, no lo que dice un vendedor o un sitio de demostración sobre sus propios productos. Cualquier cosa prometedora para ahorrarle dinero porque las personas no necesitan ser tan inteligentes o porque protege a los desarrolladores de sí mismos es una mentira sucia y sucia. Contrata talentos en los que puedas confiar. Explíqueles lo que desea de una pila u otra solución tecnológica y tómese en serio sus aportes antes de decidir a qué carro tecnológico se subirá.

  • Centrarse en el diseño sobre la implementación

Las herramientas son para la implementación y, como tales, pueden ayudarlo, pero la primera prioridad debe ser la arquitectura, independientemente del conjunto de juguetes que tenga para construir esa arquitectura. Al final del día, KISS y DRY y todas las excelentes filosofías que se extienden de esos asuntos más que si se trata de .NET o Java o tal vez algo que es gratis Y no apesta.

  • Registra tus preocupaciones

Cuando el lado del negocio insista en que lo haga de la manera incorrecta, guarde ese correo electrónico, especialmente la parte donde dijo por qué le costaría. Cuando todas sus predicciones se hacen realidad y resultan serios problemas que dañan el negocio, es cuando tiene una gran cantidad de argumentos para tomar las preocupaciones de los ingenieros más en serio. Pero cronometra las cosas con cuidado. En medio del infierno ardiente es un mal momento para un "te lo dije" en el siguiente código de incendio. Apague el fuego y lleve su lista de preocupaciones previamente ignoradas a una reunión / conversación retrospectiva, e intente mantener el enfoque en las preocupaciones de ingeniería expresadas e ignoradas y el razonamiento que entendió por qué se ignoraron, no los nombres de las personas reales tomando la decisión de ignorar. Eres ingeniero Mantente en los problemas, no en las personas. " Expresamos preocupación por X porque temíamos que esto condujera a problemas con Y. Nos dijeron Z y posponer el trato con eso ".

Erik Reppen
fuente
Muy buena y profunda respuesta. Permítanme agregar que ya he experimentado un mal caso de elegir las herramientas correctas , que produjo una gran pérdida de tiempo. Podríamos enviar el producto un mes después, después de que se tomó la decisión de abandonarlo y usar algo que no nos bloquee.
mhr
1
Me siento bien con esta respuesta, pero también acabo de encontrar mi primer trabajo donde biz y dev no están constantemente peleándose y el impacto es encantador. Acabamos de hacer las cosas. No siempre es tan pronto como quisiéramos, pero en realidad tomamos en cuenta el futuro y se nota tanto en el producto como en nuestra capacidad de modificarlo a medida que las necesidades cambian. Inevitable Big Ball of Mud es una mentira, en mi opinión.
Erik Reppen
19

Sólo hay una solución. Reserve alrededor del 10-20% del tiempo de proyecto / trabajo para refactorizar. Si es difícil convencer a la administración de que es una tarea justificable, déles el único argumento real: sin refactorizar, el costo del mantenimiento del código crecerá exponencialmente con el tiempo. Es bueno tener algunas métricas / artículos / resultados de investigación para respaldar esta tesis durante la reunión con el gerente :)

Editar: hay algunos buenos recursos sobre "refactorización frente al aumento de los costos de mantenimiento" mencionados en este documento técnico: http://www.omnext.net/downloads/Whitepaper_Omnext.pdf

Andrzej Bobak
fuente
12
Hay una mejor opción: hacer que la refactorización forme parte de tu hábito habitual de codificación. Por día Cada hora. Cada vez que agrega o cambia una función. Por lo tanto, no tiene que reservar tiempo extra para ello o "convencer a la gerencia".
Doc Brown,
Solo es válido cuando no tiene que lidiar con el código que ya está escrito. Es una tarea común agregar un nuevo valor al código fuente antiguo / heredado / heredado. Pero cuando mira ese código, no sabe por dónde comenzar y siente que es más fácil escribir ese código nuevamente que aprender cómo funciona. Intente justificar estas estimaciones: dos días para agregar un nuevo valor, seis días para refactorizar el código anterior para que sea mantenible. A menudo se escucha "no refactorizar, solo agregue el nuevo valor, más adelante descubriremos qué hacer con ese código antiguo".
Andrzej Bobak
1
@ Flot2011 Entonces solo tiene una solución. Deje que la refactorización del "día a día" sea su tarea rutinaria. Por ejemplo, todos los martes se centran solo en mejorar la calidad del código. Asegúrese de que la gerencia lo respete y asegúrese de que sepan que refactorizar no es una pérdida de tiempo. Sin estas dos condiciones cumplidas tarde o temprano, abandonarán la idea de mejorar "algo que ya está aquí y está funcionando".
Andrzej Bobak
1
@DocBrown Funciona cuando hablas con la gerencia. Si hablas con el desarrollador senior y le dices que agregarás dos campos al formulario y te llevará 3 días ... Bueno, buena suerte :).
Andrzej Bobak
2
Tener que inflar sus estimaciones para obtener tiempo de mantenimiento es problemático por varias razones. A veces vale la pena incurrir en deudas técnicas. Lo que sucede cuando biz de repente nota que en una situación de emergencia se necesitaron 15 minutos para colocar dos nuevos campos en la última vez que tomó 8 días. OMI, biz necesita ser consciente de la deuda tecnológica y el impacto a largo plazo que tiene. El problema debe entenderse como que pagas ahora o que pagas 5 veces más tarde cuando todo está dicho.
Erik Reppen
14

Siempre que tenga tiempo para hacer algo bien, úselo: escriba el mejor código que pueda y mejórelo constantemente. No dificulte su trabajo siendo descuidado e introduciendo deudas técnicas cuando no sea necesario.

Las llamadas de emergencia para corregir un error grave no son cosas que pueda controlar usted mismo, cuando ocurren, debe reaccionar lo antes posible, así es la vida. Por supuesto, si tiene la impresión de que todo su trabajo consiste en llamadas de emergencia, y nunca tiene tiempo suficiente para hacer las cosas bien, entonces está en camino de agotarse y debe hablar con su jefe.

Si eso no ayuda, todavía existe la "estrategia de Scotty" para tener tiempo suficiente para hacer las cosas bien: multiplique todas sus estimaciones por un factor de 4:

http://blogs.popart.com/2007/07/what-scotty-from-star-trek-can-teach-us-about-managing-expectations/

Doc Brown
fuente
La estrategia de Scotty funciona. Simplemente no dejes que tu jefe sepa que estás haciendo esto. Muchas veces el tiempo que lleva en realidad es el doble. Siempre es mejor terminar temprano que tarde.
Lucas
11

Considero que mi trabajo es proporcionar el mejor software de calidad posible dentro de las limitaciones de tiempo permitidas para el proyecto. Si me preocupa que el nivel de calidad sea bajo, involucraré al propietario del proyecto. Describo mis preocupaciones y analizo los riesgos potenciales de implementar el software en ese estado. Una de las 3 cosas sucederá en este punto:

  1. El propietario del proyecto no querrá aceptar los riesgos y retrasará el cronograma para permitirnos dedicar más tiempo a la calidad del software.

  2. El propietario del proyecto no querrá aceptar los riesgos, pero no puede retrasar el cronograma. Si esto sucede, debemos negociar qué características / funcionalidades eliminar del alcance del proyecto para dedicar más tiempo a la calidad del software para las partes principales de la aplicación.

  3. El propietario del proyecto aceptará los riesgos y el software de baja calidad saldrá a tiempo. A veces, el riesgo empresarial de no implementar nada (o hacerlo tarde) es mucho mayor que el riesgo empresarial de implementar software de baja calidad, y solo el propietario del proyecto puede tomar esa decisión.

Escribir software es muy parecido a pintar un retrato. Es imposible decir que un retrato se hace "bien" o "perfecto". Lo perfecto es enemigo de lo hecho. Literalmente, podría pasar 1 mes trabajando en un solo método y algunos aún no lo consideran "perfecto". Mi trabajo es pintar un retrato con el que el cliente esté satisfecho.

Shane
fuente
7

Esto no funcionará en todos los casos, pero he tenido suerte usando esta estrategia si el problema es un problema de producción roto que debe solucionarse con urgencia. Calcule el tiempo para hacer una solución rápida para poner en marcha la producción y el tiempo para hacer la solución de calidad para el futuro. Presente las estimaciones a su jefe / cliente y obtenga el tiempo aprobado para ambos. Luego, realiza la solución rápida para que la producción se ejecute y una solución a largo plazo inmediatamente después, cuando la presión de tiempo urgente está apagada. Creo que si lo presento, ya que necesito este tiempo para hacer bien el trabajo, pero puedo poner una solución temporal hasta que pueda hacer eso, parece que a mis clientes les gusta ese enfoque. Se pone en marcha nuevamente y se atiende la necesidad a largo plazo.

HLGEM
fuente
7

El equilibrio óptimo puede ser pasar tanto tiempo extra haciéndolo bien como desperdiciaría arreglando los errores que elimine haciéndolo bien. Evite el dorado de la solución. En la mayoría de los casos, la solución de Volkswagen bien hecha es tan buena como la solución de Cadillac. Por lo general, puede actualizar más tarde cuando se demuestre que necesita el Cadillac.

La reparación del código que no ha seguido las mejores prácticas suele llevar mucho más tiempo. Intentar encontrar de dónde viene el valor nulo cuando la llamada se ve como abcde (), puede llevar mucho tiempo.

Aplicar DRY y reutilizar el código existente suele ser mucho más rápido que codificar y probar otra solución más. También facilita la aplicación de cambios cuando se producen. Solo necesita cambiar y probar un conjunto de códigos, no dos, tres o veinte.

Apunte a un código básico sólido. Se puede perder mucho tiempo tratando de hacerlo perfecto. Hay mejores prácticas que conducen a un código que es rápido, pero no necesariamente el más rápido que podría ser. Más allá de eso, tratar de anticipar cuellos de botella y optimizar el código a medida que se construye puede ser una pérdida de tiempo. Peor aún, la optimización puede ralentizar el código.

Siempre que sea posible, proporcione la solución de trabajo mínima. He visto semanas desperdiciando soluciones de chapado en oro. Tenga mucho cuidado con el alcance.

Pasé un tiempo trabajando en un proyecto que debería haber tomado seis meses. Cuando me uní, había estado en progreso durante un año y medio. El líder del proyecto le había hecho una pregunta al gerente del proyecto al principio: "¿Quieres que lo haga bien o que responda?" En una semana, se implementó una función los lunes, miércoles y viernes; Martes y jueves la función fue eliminada.

EDITAR: cuando el código esté hecho a un nivel satisfactorio, déjelo. No vuelvas a arreglarlo si encuentras una mejor manera de hacerlo. Si debes hacerte una nota. Si se requieren cambios, revise su idea e impleméntela, si aún tiene sentido.

Si hay lugares donde implementaría extensiones para las próximas funciones, no implemente las extensiones. Puede dejar un comentario de marcador para recordarle dónde hacer los cambios.

BillThor
fuente
A menos que DRY signifique la implementación confusa e ilegible de esquemas de herencia masivos en cascada. No hagas eso. Lo siento, lo digo mucho, pero realmente odio eso. Además, +1 para una solución de trabajo mínima en la mayoría de los casos. A veces, algunas características arquitectónicas de futuro pueden ser útiles siempre y cuando no se exceda.
Erik Reppen
1
@ErikReppen El código que es confuso, ilegible y una implementación de esquemas de herencia masivos en cascada fallaría mi definición de DRY. Si necesita descifrar el código cada vez que lo usa, el diseño claramente falla en SECO incluso si la implementación pasa.
BillThor
Sin embargo, puede implicar una gran cantidad de reutilización de código. La parte molesta es escalar un árbol de 18 clases o prototipos para encontrar la definición real de un método que está haciendo algo realmente molesto, especialmente si hay anulaciones.
Erik Reppen
6

Haz que funcione y luego hazlo perfecto

Puedo sacar un poco de tiempo para esto, pero si el tiempo es esencial, entonces su prioridad principal debería ser hacerlo funcionar, así de simple. Comente extensamente sobre las deficiencias en su código y tome nota de lo que ha hecho en cualquier software de gestión de proyecto / tiempo que esté utilizando.

Con suerte, esto le dará más tiempo para volver a estos problemas y hacerlos perfectos.

Obviamente no hay una respuesta correcta absoluta a esto, pero es una respuesta que trato de seguir. Sin embargo, es posible que no lo encuentre adecuado para su estilo de trabajo actual. Lo que me lleva a la alternativa ...

Simplemente encuentre un método que funcione para usted ; y luego seguir con eso. Todos tienen su propia forma de tratar los proyectos y no existe un enfoque de "talla única". Encuentra un enfoque y hazlo tuyo.

Fergus en Londres
fuente
3
Cuando la gerencia sabe, eso funciona. Lo toman como hecho y no quieren que gaste ningún otro esfuerzo en refactorizar, etc.
Adronius
5

"Hacerlo bien" significa hacer las compensaciones correctas para una situación particular. Algunos de ellos son:

  1. Tiempo de desarrollo y costo
  2. Facilidad de lectura, depuración y actualización del código más tarde (todo, desde nombres de variables hasta arquitectura)
  3. La minuciosidad de la solución (casos extremos)
  4. Velocidad de ejecución

Obviamente, si se usa una pieza de código una vez y se tira, el # 2 puede ser sacrificado por cualquiera de los otros. (Pero tenga cuidado: puede pensar que va a tirarlo a la basura, luego encontrará que debe seguir usándolo y manteniéndolo, en ese momento será más difícil convencer a las personas de que le den tiempo para mejorar algo que "funciona").

Si usted y / o su equipo van a seguir usando y actualizando algún código, tomar atajos ahora solo significa reducir la velocidad más adelante.

Si actualmente está entregando código defectuoso (débil en el n. ° 4) y está tardando mucho en hacerlo (débil en el n. ° 1), y es porque está tratando de actualizar el código que estaba débil en el n. ° 2, bueno, ha Obtuve un argumento sólido y pragmático para cambiar tus prácticas.

Nathan Long
fuente
1
Sugeriría: "Si NADIE va a mantener un código ...": Escribir basura, tirar y correr no debería ser una opción (para cualquier persona con conciencia), pero sucede con demasiada frecuencia; contratistas / consultores / gerentes asegurándose de que estén seguros fuera de la puerta justo antes de que "golpee" el ventilador.
Phill W.
@PhillW. - totalmente de acuerdo. Editado en consecuencia.
Nathan Long
4

Si es un error, hágalo lo antes posible, si es una función nueva, tómese su tiempo.

Y si trabaja para una empresa que no respeta el trabajo del desarrollador, es posible que no tenga más remedio que hacerlo rápido y sacrificar la calidad.

He trabajado para varias compañías que simplemente iban de proyecto en proyecto y hacían todo rápido. Finalmente, tuvieron poco éxito en cada proyecto porque la implementación (no solo la programación) se apresuró.

Las mejores compañías por ahí entienden que un buen software requiere tiempo y artesanía.

Dimitry
fuente
3

En caso de emergencia, cree la solución de parcheo. Cree un nuevo error en el seguimiento de errores mencionando esto. Hazlo bien, siempre que tengas tiempo adecuado.

Manoj R
fuente
55
El problema es que casi nunca hay tiempo adecuado, ese es exactamente el problema, y ​​los errores de este tipo siempre tendrán la prioridad más baja.
Flot2011
Diría que esto es cierto solo si por "emergencia" te refieres a "algo que sucede no más de una vez cada seis meses" y por "cuando tienes tiempo" te refieres a "dentro de una semana más o menos". De lo contrario, su pregunta de seguimiento se convierte en "ayuda, el cliente necesita algo lo antes posible, pero el código que tengo que cambiar es un desastre confuso y me llevará semanas resolverlo".
Nathan Long
3

Creo que hago lo que hacen todos los que están atrapados trabajando en esta industria. Lo hago lo más rápido que puedo y si tengo que dejar de lado algunas de las cosas buenas que ayudarían a prevenir problemas en el futuro, o facilitar la resolución de problemas en el futuro, lo hago. No es una situación óptima, pero cuando tiene que cumplir con plazos basados ​​en estimaciones basadas en estimaciones, basadas en muchas variables desconocidas, es prácticamente lo mejor que puede hacer.

Mate
fuente
3

Aquí hay un buen plan:

  1. Haga que su plan de hacer lo correcto tome exactamente la misma cantidad de tiempo que hacerlo lo antes posible.
  2. Optimice su tiempo para hacerlo hasta que su entorno sea feliz; mantener la calidad
  3. ???
  4. Éxito
tp1
fuente
1

Hago la mayoría de las cosas de manera rutinaria, la primera forma que me viene a la mente. Eso es rápido, y me gusta pensar que soy un programador decente y que hago la mayoría de las cosas razonablemente bien en el primer intento.

De vez en cuando (me gustaría decir dos veces al día, pero dos veces por semana es más realista), especialmente cuando encuentro algo extremadamente aburrido que hacer de forma rutinaria, pienso "¿cuál sería una forma IMPRESIONANTE de hacer esto? ? " y paso el tiempo extra para encontrar o inventar una mejor manera de hacerlo.

Creo que si sigo haciendo eso con la frecuencia suficiente, mi codificación de rutina continuará mejorando.

RemcoGerlich
fuente
1

El software es algo extraño y el proceso de desarrollo de software es más extraño.

A diferencia de la mayoría de las cosas en la vida real, pero como la mayoría de las cosas que tienen que ver con las computadoras

Más rápido es más confiable

Esto va en contra de cada intuición que su vida le ha enseñado hasta ahora, los autos altamente afinados se descomponen con más frecuencia que los estándar, las casas construidas rápidamente se desmoronan más rápidamente, la tarea hecha en la parte trasera del autobús escolar no obtiene altas calificaciones.

Pero los procedimientos metódicos lentos no producen un mejor software. Los chicos que pasan semanas produciendo documentos de requisitos y días en diagramas de clase antes de escribir código no producen un mejor software. El tipo que obtiene el requisito básico, aclara algunos problemas, garabatea un diagrama de clase en la pizarra y obtiene la codificación de su equipo casi siempre producirá un software más confiable y mejor, y lo hará en días en lugar de meses.

James Anderson
fuente
No estoy seguro de estar de acuerdo con usted, pero es un punto de vista interesante y poco ortodoxo. +1 por pensar fuera de la caja.
Flot2011
-1

El trabajo no es adecuado para ti.

El código de baja calidad escrito "porque no hay tiempo, los clientes están esperando, un error debe repararse de la noche a la mañana, la empresa está perdiendo dinero por este problema, un gerente está presionando mucho" es un síntoma de una empresa mal administrada.

Si está dispuesto a enorgullecerse de su trabajo y escribir un código de alta calidad, entonces lo mejor que puede hacer es encontrar un empleador que lo entienda y que le pague por hacerlo.

B Seven
fuente