Tentaciones perjudiciales en la programación.

97

Por curiosidad, ¿qué tipo de tentaciones en la programación resultaron ser realmente perjudiciales en sus proyectos?

Como cuando realmente siente la necesidad de hacer algo y cree que va a beneficiar el proyecto o simplemente se engaña a sí mismo para creer que es así, y después de una semana se da cuenta de que no ha resuelto ningún problema real , sino que ha creado otros nuevos o , en el mejor de los casos, complació a tu bestia interior sin impacto visible.

Personalmente, me resulta muy difícil no refactorizar el código incorrecto. Trabajo con muchos códigos heredados malos, y me cuesta respirar profundamente para no tocarlo cuando no tengo pruebas que demuestren que mi refactorización no rompe nada.

Otro demonio para mí en la interfaz de usuario, literalmente puedo pasar horas cambiando el diseño de la interfaz de usuario solo porque me gusta hacerlo. A veces me digo que estoy trabajando en la usabilidad, pero la verdad es que me encanta mover botones.

¿Cuáles son tus demonios de programación y cómo los evitas?

programming-practices language-agnostic Dan
fuente
19
Me parece gracioso que nadie haya podido responder la segunda parte de su pregunta: "[y] ¿cómo los evita?".
Craige
3
¿Alguien ha notado que esta ha sido la pregunta principal en SE todo el día?
msarchet
+1 para "... pasar horas cambiando el diseño de la interfaz de usuario ..." Caigo en esa trampa demasiado a menudo.
7wp

Respuestas:

67

La generalización prematura es mi gran problema; en lugar de resolver el problema en cuestión primero y esperar hasta que haya una necesidad real de resolver el caso general, siempre busco el caso general por adelantado y termino escribiendo una tonelada de código que es más complejo de lo que debe ser.

Actualizar:

Consulte " Sin # 1 - Generalización prematura " para obtener una descripción detallada.

k3b
fuente
66
¡Odio cuando los astronautas de la arquitectura hacen eso!
ozz
13
Oh, la alegría de las fábricas metafactory :(
+1 "Un estudio de grandes diseñadores descubrió que todos eran buenos para anticipar el cambio" (Code Complete 2). Es bueno saber qué tipos de cambio son probables. Luego puede decidir si se puede ganar algo resolviendo el caso más general desde el principio, si ahorraría tiempo más adelante. A veces no vale la pena, sería tan fácil modificar el código más adelante.
MarkJ
1
¿Has oído hablar del principio YAGNI (No lo vas a necesitar) ?
Oscar Mederos
1
Esta. Culpo al hecho de que crear código bonito, generalizado y reutilizable es muy satisfactorio, especialmente si el problema en sí no es muy desafiante y / o es solo una repetición de lo que has hecho antes. Caso en cuestión, operaciones genéricas de la base de datos CRUD (UI, responder a la acción del usuario, hacer algo con un DB, thar).
Cthulhu
197

"Volveremos a esto y lo arreglaremos más tarde. ¡Solo necesitamos que funcione ahora!"

usuario18041
fuente
16
Este es el demonio absoluto.
alesplin
66
Te daría +100 por esto si pudiera. "Más tarde" NUNCA SUCEDE. Haz las cosas bien la primera vez o no hagas nada.
rapid_now
12
¿No es este el complemento de pasar horas refactorizando códigos incorrectos? Podemos dividir el mundo en programadores que "lo arreglarán más tarde" pero no lo hacen, y programadores que intentan hacerlo bien la primera vez y luego pasan horas "refactorizando códigos incorrectos".
66
reformule esto a "Volveremos y arreglaremos esta próxima iteración " y suena mucho más estructurado
Chris S
44
Usted debe hacer esto. Si pasas todo tu tiempo haciéndolo perfecto, nunca se enviará. Termine el proyecto, luego púlselo.
Zan Lynx
105

El plazo está muuuy lejos, tengo tiempo más que suficiente para hacerlo, así que ¿por qué no pasar un poco de tiempo navegando por la web?

usuario281377
fuente
72
reemplace "web" con "programmers.stackexchange.com" :)
davidhaskins
1
¿Hay algo más en la web que valga la pena leer? ¡Había olvidado que había algo más!
James McLeod
3
alias 'Damn you, Minecraft'
johnc
1
@david, ese es solo el punto de partida en la web - la pregunta es qué tan lejos llegas ...
Yo diría que esto ya no es tan válido debido a Agile.
vartec
103

"Esto es solo un código de prueba de concepto desechable. Una vez que les guste, lo haré realmente bueno".

davidhaskins
fuente
13
Esto se llama desarrollo rápido de aplicaciones; y nunca funciona en un entorno empresarial. :)
John Kraft
12
Es curioso que para mí sea al revés, simplemente no puedo obligarme a escribir código desechable incluso cuando es exactamente lo que se requiere.
Dan
66
Trabajo en finanzas y RAD sigue fortaleciéndose, especialmente en VBA / Excel. Sin embargo, hay una habilidad especial, RAD no tiene que significar descuidado.
Ian
55
Y a veces la aplicación que pasó dos años perfeccionando termina siendo un código desechable porque alguien más arriba de la escalera decidió "oh, no podemos hacer eso" o alguna otra versión de "no importa".
PSU
12
Esta. Yo: "Esta es solo mi prueba de concepto. Si te gusta, escribiremos la versión de producción". Gerente: "Tu versión funciona, ¡vamos a enviarla!" Yo: "Bueno, no cubre todo el uso ca ... ya enviaste, ¿no?"
74
  1. Refactorizando parte del código unos días antes del lanzamiento.
  2. Internet: la mayor distracción de todas.
  3. Nueva tecnología : no puedo apartar mis manos de la nueva tecnología.
  4. Optimizar: Optimizar, Optimizar. .. y más Optimizar
  5. Perfección : nunca he quedado satisfecho con el código.
  6. TODO: Falta de tiempo todos los que nunca se harán.
  7. Estimación del tiempo: muchos PM no toman esto como "estimación". Toman como hecho.
  8. Promesas: Hacer demasiadas promesas.
Amir Rezaei
fuente
1
Una vez trabajé en un proyecto que tenía 100 personas en una habitación grande, y solo 2 PC compartidas tenían internet. La productividad fue muy alta. La gerencia le dio a todos internet y se preguntó por qué la producción del trabajo se redujo a la mitad.
rápidamente_ahora
2
Con respecto a la Estimación de tiempo ... muchos gerentes lo toman como punto de partida en la negociación (como negociar un precio). Los que lo toman como un hecho equivocado pero en realidad por encima del promedio ...
dbkk
@quickly_now Cortar la red probablemente funcione para tareas mundanas como la entrada de datos o las correcciones de rutina, donde no es necesario buscar nada. Para muchas cosas fuera de lo común (por ejemplo, buscar documentos API / código de ejemplo), Google es tu amigo: lleva 5 veces más tiempo resolverlo por tu cuenta. Además, si las personas no están motivadas y quieren distraerse, encontrarán formas.
dbkk
@dbkk: sí, hasta cierto punto. Todo estaba en Ada, no había API para buscar, estaba en hardware especializado y clasificado en seguridad nacional. Poner máquinas no clasificadas conectadas a Internet en ese entorno también fue una pesadilla de seguridad.
rápidamente_ahora
55

Caer presa de tratar de construir todo internamente, cuando existen marcos y bibliotecas existentes.

FrustratedWithFormsDesigner
fuente
66
A veces, los marcos y bibliotecas existentes están marcados con Verboten en letras rojas grandes por TI legal.
Christopher Mahan
22
Y, por supuesto, la tentación opuesta: usar un marco o biblioteca desconocidos y suponer que hará lo que necesita y que todo saldrá bien.
Carson63000
"pero solo tomará una semana para escribir y nuestro marco hará exactamente lo que queremos, el gratuito en línea probablemente esté lleno de errores"
2
@ Christopher: Entonces esa sería una buena razón para reimplementar (o encontrar una biblioteca diferente con una licencia aceptable). Pero con demasiada frecuencia, la razón de la reimplementación es solo NIH ...
Donal Fellows
@Carson: +1 :-)
Macke
48

Mis demonios recurrentes: optimización prematura y sobre ingeniería.

Y todavía no puedo evitarlos al 100% ...

Tomás Narros
fuente
10
+1 para sobre ingeniería. Una vez escribí un "marco de configuración" completo con "adaptadores de parámetros de configuración" para archivos .ini, archivos XML, tablas de bases de datos y sockets de red (porque todos quieren alojar un servicio web de configuración, ¿verdad?)
TMN
8
¿Sobre ingeniería prematura?
Christopher Mahan
Sin embargo, también se aplica @Chris "sobreingeniería prematura". También se ha mencionado en otras respuestas . Sé que es una de mis pesadillas.
Matthew Scharley
¿Qué hay de la megaingeniería sobre optimizada prematura ...
Newtopian
44
Esto es mío. Yo culpo a la administración, dándome plazos libres de reinado / futuro lejano y no dándome plazos para componentes específicos.
Cthulhu
46

Estimaciones demasiado optimistas.

Cuando su gerente lo está mirando hacia abajo, y siente la sensación de ardor al dar una estimación más baja de lo que su intestino le dice ... ¡no lo haga!

Después de todo, ¡tu intestino probablemente ya esté demasiado bajo!

Nicole
fuente
13
Cuando le preguntan si será realmente tomar ese tiempo, sólo decir que sí y luego sentarse en silencio hasta que sienten la incomodidad ...
PeterAllenWebb
44
Mi profesor universitario me dijo una vez: "Calcule su mejor estimación y luego duplíquela". Me ha funcionado hasta ahora.
zzzzBov
2
Alternativamente, intente el enfoque SMBC .
desviarse
44
Uno de mis viejos jefes triplicó las estimaciones de los desarrolladores, luego negoció para duplicarse con los clientes. Los clientes pensaron que tenían un trato, los desarrolladores obtuvieron el tiempo que necesitaban incluso si no lo sabían. Ganar-ganar!
DaveE
2
La programación basada en la evidencia podría ayudar con este problema: joelonsoftware.com/items/2007/10/26.html
Rei Miyasaka
33

Usar una tecnología / herramienta / lenguaje en su proyecto simplemente porque lo acaba de aprender.

Para tratar de demostrar lo bueno que eres como desarrollador.

Para considerar el código que has escrito como tuyo.

biziclop
fuente
Si tan solo pudiera votarlo cada vez que lo hiciera. Afortunadamente, la mitad de las soluciones resultaron ser bastante buenas. La mitad no lo hizo.
Dan
O uno que aún no has aprendido. Solo no te olvides de atarte las espuelas porque será un viaje largo.
Evan Plaice
32

Me tomaré un descanso y miraré stackoverflow.com;)

Richard Miskin
fuente
2
Siempre me encanta cuando stackoverflow es la respuesta a una de estas preguntas
Bill Leeper
31

La peor tentación:

Oh, bueno ... supongo que un pequeño truco sucio / truco / arreglo no te hará daño

Adivina qué, duele. :)

ir

Goran Jovic
fuente
11
"Correcciones de puerta de enlace"
Mark C
44
El uso de una gotodeclaración dará como resultado un ataque de rapaces.
Maxpm
1
@ Maxpm: ¡Buen pensamiento! Incluido.
Goran Jovic
1
@ Mark C, ¿qué es una solución de puerta de enlace? Mi gøøgle-fu no es lo suficientemente bueno.
1
@ Thorbjørn Ravn Andersen: en.wikipedia.org/wiki/Gateway_drug_theory
Jimmy
23

Característica de fluencia

Haga un plan, sígalo y despliegue. Y luego regrese y agregue las cosas que la gente está pidiendo.

He visto esto una y otra vez. Te sientas, elaboras el diseño y comienzas a codificar. Los usuarios escuchan algunas tonterías confusas acerca de que su función favorita está "perdida" y comienzan a presionar por ella. Su jefe exige que lo agregue a la hora 11, incrusta el despliegue, introduce errores en todas partes y, 3 meses después, una vez que todos se hayan calmado, se le pide que lo elimine, porque nadie puede entender por qué ¡Esa horrible característica retro en primer lugar! ¿No podrías decir que el resto del diseño lo hizo inútil?

Satanicpuppy
fuente
Dejar la especificación descongelada y abierta como una concesión porque el primer primer ministro (que ahora fue despedido) no sabía nada sobre el desarrollo de software y diseñó un calendario de lanzamiento completamente poco realista. La peor idea de todas.
Evan Plaice
20

  1. Agregar más funciones

  2. La competencia tiene esta característica. Entonces, esta es una característica imprescindible, por lo tanto, más programación que analizar estrategia, posicionamiento, etc.

  3. La competencia NO tiene esta característica. Por lo tanto, esta es una característica diferenciadora, por lo tanto, más programación que analizar estrategia, posicionamiento, etc.

  4. Resolver un problema de negocios con más programación. por ejemplo, no se puede obtener una mayor experiencia en la administración del servidor Linux en el que se aloja su sitio web mediante la programación de más funciones. A veces solo tiene que aprender a solucionar el problema en lugar de volver a codificarlo todo en C # .Net

  5. Resolver un problema de marketing con más programación. por ejemplo, al abusar del concepto de vaca púrpura de Seth Godin de que indirectamente está resolviendo un problema de marketing al programar más funciones en su producto para convertirlo en una "vaca púrpura". A veces, es solo un monstruo mutante.

  6. Resolver un problema de productividad con más programación argumentando a sí mismo que el tiempo dedicado a escribir este script se ahorrará en horas en el futuro en lugar de programar cosas realmente importantes

  7. Planea codificar pero aún no codifica porque quieres "hacerlo bien"

  8. Codificando una versión sucia y prometiendo que "lo mejorarás más tarde" pero nunca volviste a "hacerlo mejor"

  9. No hacer una maqueta o un mapa del sitio porque es "muy problemático". Simplemente puedo capturar las páginas de la competencia para maquetas y dibujar a mano alzada el mapa del sitio "más tarde", que nunca es. Y luego simplemente vaya directamente a la programación de la primera página que visualizo en mi mente.

Confesión: personalmente he cometido errores 1, 3, 7, 8. También he cometido 2, 4, 5, 6 pero a menudo me engañé a mí mismo que no lo hice.

Actualmente estoy remediando 9.

EDITAR No me di cuenta de que la pregunta nos obliga a poner soluciones.

1) Agregar más funciones Simplemente no lo haga. Trabaje con su negocio, marketing, fundadores, asesores, etc. y reduzca su aplicación a solo 1 cosa.

Vaya a leer sobre Twitter, Groupon , etc. acerca de cómo simplemente reducen las cosas a solo 1 cosa que los llevó a su éxito.

Si crees que solo funciona si quieres construir grandes empresas, piénsalo de nuevo. Ctrl + F para esta línea "Cuantas más funciones agregue al software, peor se venderá (no hace falta decir que es muy poco intuitivo para la mayoría de los desarrolladores de software)" en este enlace.

2) La competencia tiene esta característica. Entonces esta es una característica imprescindible

Ver solución 1

3) La competencia NO tiene esta característica. Entonces esta es una característica diferenciadora

Ver solución 1

4) Resolver un problema de negocios con más programación.

Si necesita contratar a alguien para que le enseñe, consulte, o hágalo por usted y luego documente cómo lo hizo, para que pueda hacerlo usted mismo la próxima vez. ¡¡SIMPLEMENTE HAZLO!! No reescriba el código, no pase GO, no recolecte $ 200.

5) Resolver un problema de marketing con más programación.

Si la gente no entiende lo que está vendiendo, ES un problema de marketing. Regrese a la solución 1 y gire.

6) Resolver un problema de productividad con más programación

Espere.

Espere hasta que sienta que su productividad ha sufrido un problema particular de productividad durante un período de más de 2 semanas y razonablemente sucederá durante otras 2 semanas.

Ahora, evalúe la cantidad de tiempo dedicado a programar un script para resolver este problema. Recuerde tomar su peor estimación y multiplicar por 2.

Multiplique su estimación por su tarifa por hora.

Ahora revise soluciones alternativas: externalice, compre una solución lista para usar, no haga nada al respecto, etc.

Elija la solución más rentable.

Apégate a ello.

7) Planeando codificar pero aún no codificando porque quieres "hacerlo bien"

Ve a hacer ejercicio. Sentirás una avalancha de endorfinas que motivarán tu trasero y te harán planear actuar. Sé esto porque acabo de hacer 5x5 benchpress y 5x5 sentadillas.

8) Codificando una versión sucia y prometiendo que "lo mejorarás más tarde" pero nunca volviste a "hacerlo mejor"

Configure un sistema de archivos tickler en GTD. y seguimiento agresivo. Cumplir todas las promesas para usted y los demás.

9) No hacer una maqueta o un mapa del sitio porque es "muy problemático".

Ve a gastar USD75 en una edición de escritorio de maquetas balsamiq. Lo sé porque lo compré hace 3 semanas. Me ha hecho rehacer mis maquetas porque me siento como un artista, arquitecto y visionario, todo en uno, a pesar de que mi dibujo en el mundo real apesta. La fuente utilizada en balsamiq te recuerda inconscientemente que esto es solo una maqueta, no escrita en piedra que te ayuda en RAD.

Fin EDITAR

revs kimsia
fuente
Hice +1 en esta respuesta, pero me resultó un poco difícil de leer. Realmente no entiendo el contexto de los primeros 9 puntos. ¿Te importaría aclarar? Aún así, buen trabajo.
@MattFenwick Hola, gracias por tu +1. Los puntos 1-5 generalmente se aplican en el escenario de creación de un producto para vender, aunque también puede aplicarlo a escenarios en los que su tendencia a encontrar la mejor respuesta lo lleva a investigar ampliamente sobre la técnica anterior. Por ejemplo, en investigación.
Kim Stacks
Los puntos 6-9 se refieren más a las tendencias neuróticas de un programador. Leí en alguna parte (no lo encuentro) que un diseñador siempre abordaría cualquier problema con una solución de diseño; un vendedor con una solución de marketing; y un programador con una solución de código. Sí, el temido "Cuando tienes un martillo dorado, todo lo que ves es el síndrome de las uñas". Esto es particularmente evidente en el punto 6) Resolver un problema de productividad con más programación
Kim Stacks
@MattFenwick lo siento si te confundiste con mi nombre. Cambié mi apodo después de escribir esta respuesta. Veo que tu experiencia es más de investigación. Mi respuesta deriva en gran medida de mi experiencia en el desarrollo de soluciones para vender. Pero estoy seguro, hay ciertas similitudes entre mi línea de trabajo y la suya, ya que ambos hacemos programación.
Kim Stacks
17

Un par de cervezas me ayudarán a trabajar mejor y por más tiempo.

Adam Crossland
fuente
11
Espera ... ¿quieres decir que no? ( xkcd.com/323 )
Craige
44
@Craige: después de 21 años de experiencia con la bebida y 20 años de experiencia como ingeniero de software profesional, todavía estoy trabajando en la parte de calibración.
Adam Crossland
44
@adam, ¿te tomó un año beber para convertirte en ingeniero?
17
Codificar mientras bebes cerveza te ayuda a crear redes sociales tremendamente populares que valdrán miles de millones en un par de años. Es cierto, vi esto en una película.
janosrusiczki
1
@Kitsched: ¡Sí! Especialmente si tienes un diseño preexistente de otra persona para estafar.
Mason Wheeler
16

"Sí, puedo refactorizar este desorden gigantesco de 2000 líneas de espagueti en un día ..."

Hila
fuente
13
Alternativamente: "el chico nuevo [que no sabe absolutamente nada sobre el software o la estructura de su código] no está haciendo nada, puede arreglarlo". Puntos de bonificación cuando el chico nunca ha usado el idioma en el que está escrito el código.
wildpeaks
16

"Puedo pasar sin una prueba para eso. Es demasiado difícil de probar".

y es malvado hermano

"Debo hacerme una prueba para eso, no importa cuán difícil sea escribir o comprender la prueba".

Wayne Conrad
fuente
2
Si una prueba es difícil de escribir, es posible que no la esté programando correctamente :)
Merlyn Morgan-Graham
2
@Merylyn Morgan-Graham, bastante cierto. Pero hay algunas áreas, como la concurrencia, que es simplemente más difícil de probar.
Wayne Conrad
1
@Merlyn: Si te encuentras escribiendo un simulador de instrucciones para poder forzar un cambio de contexto en los lugares correctos, entonces probablemente has ido demasiado lejos en tus pruebas de concurrencia. :)
Zan Lynx
1
@Zan: Estoy de acuerdo: en el punto requerido, presionaría a los desarrolladores e intentaría que refactorizaran su código y me permitieran insertar simulacros. Aunque trabajo contra idiomas de alto nivel donde observamos Big-O, optimizamos cuellos de botella, tenemos que pensar en la concurrencia principalmente para la integridad de los datos en lugar de la velocidad bruta, y enviar (y a menudo ninguno de ellos porque es lo suficientemente rápido caja).
Merlyn Morgan-Graham
15

La dilación y la estimación optimista de tareas son mis pecados más grandes.

Estiramiento, flexiones o dominadas (o cualquier otro ejercicio físico) para el primero y ánimo pesimista antes de estimar el segundo.

Nikita Barsukov
fuente
Aclaración ... Por "estimación optimista de tareas" te refieres a "síndrome fácil de mierda" ¿verdad? :)
Evan Plaice
@Evan Plaice, exactamente. Como "oh, es tan trivial" y luego buscar en Google cada letra de su código después de que comenzó la codificación real.
Nikita Barsukov
13

"Es mucho más fácil volver a implementar la funcionalidad desde cero que comprender el código existente".

k3b
fuente
2
Sí, c2.com/cgi/wiki?RewriteCodeFromScratch afirma que esta es una de las "Cosas que nunca debes hacer".
David Cary
Trabajar en código abierto ayuda a esta tendencia. Personalmente miré los parches antes de cruzar los ojos, luego seguí adelante y escribí mi propia implementación solo para darme cuenta de que era casi idéntica al parche (incluso después de mejorar / refactorizar mi código). Es curioso cómo funciona eso.
Evan Plaice
10

Una tentación masivamente dañina que ha sufrido el proyecto en el que me encuentro es el 'Efecto de plataforma interna'. Este es un enfoque que los arquitectos, que ya se han ido, han establecido en su sabiduría infinita que ha creado un proyecto que genera alrededor de 20 millones de dólares por año pero cuesta 60 millones para actualizar y mantener (cifras aproximadas, obviamente, pero esta es la magnitud del problema).

AlexC
fuente
10

NIH - No inventado aquí

Me cuesta mucho darles a las soluciones de terceros una oportunidad justa. Todos deberían ser naturalmente escépticos con respecto a las soluciones de terceros que no fueron hechas a medida para ellos, pero me cuesta ser 100% objetivo al respecto.

El ahorro de tiempo puede ser tan grande que incluso si 9 de cada 10 veces la solución de terceros debe ser evitado, que deben ser lo suficientemente objetivo de realizar el uno que funcione.

Nicole
fuente
1
Veo tu punto y tengo que vivir con eso todo el tiempo. Estoy directamente en la opinión opuesta a veces hasta el punto de que merecería una respuesta justo al lado de la suya. Sin embargo, me cuesta creer que puedo hacerlo mejor en una semana que un grupo de expertos en el tema que han estado trabajando durante años. Por supuesto, debe asegurarse de que las personas detrás de dicho tercero sean realmente expertos. Una buena investigación sobre el entorno del componente ayudó mucho a elegir correctamente entre la adopción o la codificación.
Newtopian
1
@Newtopian la forma "correcta" definitivamente está en algún lugar en el medio. Mi problema con las bibliotecas de terceros no es si puedo hacerlo mejor que un equipo de expertos con meses o semanas de tiempo, sino que rara vez, tal vez nunca encuentre una biblioteca que sea exactamente lo que necesitamos. Siempre hay que adaptarse para hacer, y luego a menudo me encuentro a mí mismo y a otros pasando tanto tiempo luchando con eso como escribiendo una solución que es exactamente lo que necesitamos.
Nicole
Yo mismo que venía del extremo opuesto del espectro tenía curiosidad por saber cómo lograste tratar de lograr este "solo medio", si es que lo hiciste. También tenía curiosidad por saber qué hace que no desee utilizar a terceros al tratar de comprender qué me hace usarlos en exceso, ya que estoy seguro de que ambos son igualmente perjudiciales para la productividad.
Newtopian
@Newtopian, ¿tiene sentido mi explicación anterior sobre por qué? Mi intento de tratar de alcanzar el medio es simple para ser más objetivo al evaluar y buscar soluciones de terceros.
Nicole
9

Diseño, codificación y / o pruebas unitarias contra "datos de muestra" suministrados en lugar de analizar una copia de la base de datos real de los clientes. La fecha límite era corta y seguían diciendo que se acercaba, pero nunca lo hizo. Cuando se desplegó, la explosión fue espectacular. Realmente, quién hubiera esperado que un cliente tuviera 3 clientes principales.

Nunca volveré a comenzar un proyecto hasta que tenga una copia de los datos reales .

dwidel
fuente
Si todavía no hay un producto, ¿habrá algún dato para copiar?
Svish
Si no hay datos, siempre hay papel. Los registros de la compañía también ayudarían aquí.
burnt_hand
9

El Hay que ser una biblioteca que hace que en algún síndrome.

relacionado cercanamente a

El fetiche del complemento

Newtopian
fuente
2
Siempre parece que puedo encontrar la biblioteca que "lo hace". A menudo, mi problema es hacer que funcionen como se anuncia. :(
Ben L
Fácil de encontrar una biblioteca - Difícil de encontrar una biblioteca que tenga buenas pruebas unitarias incorporadas
burnt_hand
8

El perfeccionismo mata; probablemente la mayor razón por la que los proyectos no tienen éxito.

Naftuli Kay
fuente
Supongo que es posible que esto sea cierto, pero nunca he estado en un proyecto que haya fallado, o que incluso haya llegado tarde, por este motivo.
PeterAllenWebb
Depende de cómo defina la perfección y a qué nivel esté apuntando.
Svish
7

Bueno, a veces la programación me lleva a la botella.

mipadi
fuente
7

Reescritura en lugar de refactorización.

Dave O.
fuente
De acuerdo. Si está dispuesto a comprometerse con la cantidad de esfuerzo requerida para una reescritura, casi SIEMPRE es mejor refactorizar. Todavía llevará más tiempo de lo que pensabas, pero estás haciendo la refactorización de forma incremental, ¿verdad? Puedes parar antes de que sea "perfecto".
PeterAllenWebb
1
como corolario ... escribir de nuevo en otro lugar en lugar de refactorizar. Nuestra base de código tiene tantas implementaciones diferentes de las mismas cosas que es imposible obtener ningún tipo de coherencia.
Newtopian
6

Pensar que tiene que haber una mejor manera de hacer esto. No me voy a conformar con algo que pueda ser "suficientemente bueno". Estoy tomando nada menos que la perfección! Por lo general, esto se evita al hablar con otros que pueden tener una perspectiva diferente sobre un problema o al ver una solución desde un ángulo diferente.

JB King
fuente
5

Automatizando todo hasta el punto se gasta más tiempo en el mantenimiento de las herramientas que en el trabajo real.

Solución: al igual que con la optimización del código, primero encuentre cuellos de botella en la productividad y solo después de descubrirlos, cúrelos con una buena automatización .

Dan
fuente
Estoy de acuerdo con esto en principio, pero nunca he visto una automatización excesiva en la práctica. Aún así, esa podría ser mi experiencia.
PeterAllenWebb
4

¿Cuáles son tus demonios de programación?

Aparte de lo que otros han mencionado.

Priorización : ignorar el trabajo de alta prioridad con respecto al proyecto y trabajar primero en otras cosas del proyecto porque son más interesantes.

Cómo los evitas?

Con un poco más de autodisciplina. En serio, la autodisciplina y la automotivación para hacer lo correcto ayudan a evitar la mayoría de estos "demonios".

rev. Mahesh Velaga
fuente
3

Todavía no hemos recibido la aprobación del cliente, pero la fecha límite se acerca, así que aquí hay algunas compilaciones preliminares para que pueda comenzar ...

Más tarde, una vez que haya terminado de construir el proyecto para que coincida con las composiciones ...

Ah, aquí están las revisiones del cliente, solo quieren cambiar algunas cosas menores *

(* la funcionalidad principal es completamente diferente)

Luego sigue refactorizando su código original, basado en el modelo defectuoso original en lugar de comenzar desde cero porque está bajo la presión de un plazo corto y asume que esas fueron las últimas revisiones.

Este me mordió todo el tiempo. Es difícil de evitar como desarrollador web. Mi mejor consejo es presionar por más tiempo para que pueda hacer los cambios de la manera correcta.

travis
fuente
2
Adopte una política donde no comience el desarrollo hasta que tenga la firma de un cliente.
Ben L
1
@Ben: ¡Ojalá eso estuviera bajo nuestro control!
sevenseacat