¿Cuáles son las peores economías falsas en el desarrollo de software? [cerrado]

126

¿Cuáles son las peores economías falsas (es decir, formas de ahorrar dinero que finalmente cuestan más de lo que ahorran) que prevalecen en la industria del software y cómo combatirlas?

programming-practices project-management

— Jon Hopkins
fuente

2

:( He visto muchos de estos con demasiada frecuencia.

— Tony

3

programmers.stackexchange.com/questions/18585/…

— cmcginty

@Casey: está un poco relacionado, pero no del todo. El enlace que proporcionó trata directamente con el dinero, mientras que las respuestas en esta pregunta aquí también tratan sobre el dinero y las creencias. Ejemplo, vea mi respuesta: programmers.stackexchange.com/questions/19573/…

— Gan

¿Acabas de visitar mi empresa ... no importa; P

— pramodc84

1

@ Mark - suena como una buena pregunta, adelante. Sin embargo, algunos detalles más podrían ser buenos.

— Jon Hopkins el

182

Deuda técnica

es decir, "Solo hazlo rápido, lo refactorizaremos más tarde". En primer lugar porque aún no he visto a alguien que participe en este comportamiento en realidad refactorizar más tarde. En segundo lugar, porque hacer las cosas de manera rápida, en lugar de hacerlo de la manera correcta, hace que sea más difícil agregar funciones futuras o resolver errores futuros, por lo que terminará perdiendo tiempo a largo plazo.

Lamentablemente, muchos todavía piensan que ahorra ciclos de desarrollo para que hagan algo rápido. Supongo que es posible, pero aún no lo he visto en la práctica.

— revs Inaimathi
fuente

2

No puedo contar la cantidad de veces que he visto a la administración detener a los desarrolladores (2 a 3) durante un día, luego un especialista en implementación para solucionar un problema (y hacer esto varias veces durante el ciclo de vida del producto) en lugar de gastar 2- 4 días para hacerlo bien. Gran respuesta.

— DevSolo

44

Si el tiempo necesario para la reparación se puede medir en dólares, por ejemplo, la corrección de errores en un sistema de negociación de acciones, entonces la decisión de gestión se inclinará hacia un costo reducido. He descubierto que proponer "parchearlo ahora para mantenerlo en funcionamiento mientras determinamos la solución correcta para asegurarnos de que esto nunca vuelva a suceder" satisface la urgencia impulsada por los costos y también obtiene el resultado correcto, pero a veces hay que luchar por esto. .

— JBRWilkinson

99

Tenemos código en todas partes con comentarios como "Esto es un truco, reemplazar después de la demostración" que ha estado en la base durante 3 a 5 años. Nadie incluso recuerda que se hizo en este punto, por lo que nadie lo encuentra hasta que alguien (yo) esté reparando errores y lo encuentre. No hace falta decir que esta lección objetiva me ha enseñado muy bien a hacerlo bien la primera vez si de alguna manera soy capaz de hacerlo.

— CodexArcanum

22

Y honestamente, ¡estoy continuamente impactado por la cantidad de veces que ni siquiera ahorra tiempo a corto plazo!

— PeterAllenWebb

66

@Jorg - ¿Eh? "La deuda técnica y la deuda de diseño son metáforas sinónimo y neologísticas que se refieren a las posibles consecuencias de la arquitectura de software slapdash y el desarrollo de software apresurado". en.wikipedia.org/wiki/Technical_debt Esto es precisamente a lo que me refiero. Quizás un título más específico hubiera sido "Incurrir en deuda técnica sin intención de pagarlo", pero muchas personas en esta situación se dicen a sí mismas que realmente tienen la intención de pagar (pero no lo hacen), y quería un título contundente para poner texto en negrita en la parte superior. "Deuda técnica" parecía ser un resumen lo suficientemente bueno.

— Inaimathi

163

Contratar a 2 desarrolladores baratos en lugar de 1 realmente genial. (por el mismo precio)

— usuario2567
fuente

99

Este al menos parece tener una base en la realidad; tenga en cuenta que las personas no técnicas no pueden saber quiénes son los grandes desarrolladores (por lo que es muy probable que solo paguen el doble a un idiota asesor al azar que a una superestrella real).

— Inaimathi

112

O tristemente, solo contratando a 1 barato ...

— DevSolo

44

... o contratando a un gurú donde dos tontos harían el 1.5 de lo que el gurú hace por 1.0 del salario del gurú: /

— bobah

14

No obtienes el 75% de un gurú de un muñeco , y cualquier programador realmente bueno hará lo que sea necesario sin ser presumido al respecto.

— Peter Boughton

8

Los programadores 10x o 100x tienen una increíble relación calidad-precio increíble; solo se les paga 1.5 quizás 2x. Como dice Michael Lopp (Rands in Repose), si solo contratas a uno de estos en toda tu carrera, es una ganancia neta.

— Tim Williscroft

85

Mi ejemplo sería todo lo contrario del ejemplo de NimChimpsky , a saber:

Tratando de desarrollar en casa algo que se pueda comprar de forma inmediata.

Normalmente, esto ocurre debido a una falla en verificar el mercado para ver si ya existe algo que resuelva el problema. Esto puede ser agravado por los desarrolladores a quienes les gusta "sumergirse" en la codificación antes de hacer cualquier investigación y por los gerentes de proyectos que no tienen en cuenta ese tiempo = dinero.

Uno de los ejemplos más comunes que he visto en mi campo, el desarrollo web, son las empresas que intentan desarrollar un sistema CMS interno. Estos comienzan invariablemente pequeños, pero pronto se hinchan y se descontrolan a medida que las características se atornillan, mientras que todo el tiempo hay muchos productos y marcos gratuitos que serían mucho más adecuados.

— Dan Diplo
fuente

17

Solo porque puede ser, no significa que deba ser. Un CMS básico, bueno, sí, por qué reinventar la rueda. Pero cuando comienzas a hablar de sistemas a gran escala y modelar procesos comerciales complejos, ¿por qué intentar colocar una clavija redonda en un agujero cuadrado? Especialmente si tienes desarrolladores y habilidades existentes en casa.

— NimChimpsky

99

@NimChimpsky: creo que hay ejemplos válidos de ambos. Ciertamente, he visto personas que rompen sus procesos comerciales y pierden las ventajas que tenían al tratar de adaptarlas al software estándar, pero también he visto a desarrolladores que sufren del código del síndrome "no inventado aquí" cosas que podrían haber descargado simplemente porque fue más interesante para ellos.

— Jon Hopkins el

3

@NimChimpsky Si la especificación requiere un desarrollo a medida, entonces está bien: nos mantiene en puestos de trabajo :) El problema surge cuando la gente no comprueba primero si hay algo ya desarrollado que se ajusta a la factura y se sumerge directamente en el desarrollo. ¡Un poco de investigación puede recorrer un largo camino!

— Dan Diplo

66

¿Por qué reinventar la rueda? Porque eres un ingeniero de ruedas. O porque tu rueda es mejor que la rueda del próximo chico. O porque la rueda no encaja. Ver: mostlymaths.net/2010/03/…

— Derek

2

Donde yo trabajo casi todo OTS se podía comprar - y casi todo es re-inventado en la casa porque de acuerdo a nuestros líderes de Fearless (TM) "nuestro medio ambiente es tan complejo que nada en el mercado podría posiblemente manejarlo". Pfeh! Pero qué demonios, paga las cuentas. Ayer nos dijeron que un componente importante de nuestro software se reescribirá el próximo año, ¡CON UNA INTERFAZ GRÁFICA! Ooooooh-aaaaaaah! Estoy a-twitter ... (<pheh!>)

— Bob Jarvis

73

No hay recursos dedicados para la gestión de proyectos.

He experimentado varias veces cuando se contrataron unos pocos programadores, y alguien que ya tiene un trabajo diario exigente debería haber gestionado el proyecto, pero de hecho estaba demasiado ocupado con otras tareas, por lo que el proyecto nunca ganó impulso. Los programadores hicieron "prototipos" y cosas por el estilo, pero sin una pista, gran parte de ellos se ejecutaban en círculos para parecer ocupados.

Mal equipo para nuevos programadores

Una vez experimenté una compañía donde la política era "los nuevos programadores tienen que trabajar en una PC realmente vieja con una pantalla pequeña hasta que demuestren que son dignos". No es de extrañar que tal política haya causado una selección negativa que haya alejado a las buenas personas que siempre tienen la opción de trabajar en un entorno más sano.

— usuario281377
fuente

19

+1. No proporcionar un buen equipo para sus empleados tiene "la obligación de fallar" por escrito.

— Terence Ponce

3

+1. Pero tenga en cuenta lo siguiente: en muchas empresas, los presupuestos de hardware se incluyen en la infraestructura y se mantienen separados de los presupuestos de desarrollo. El administrador de infraestructura no va a recibir un golpe en contra de su presupuesto para ayudar a aliviar el presupuesto del administrador de desarrollo. He visto esta desagradable política jugar varias veces.

— Fil

3

¿Qué tal un mal equipo para TODOS los programadores? Mi ex empleador nos pagó los salarios de Silicon Valley para escribir código en computadoras de escritorio que habían sido mediocres cinco años antes. Debido a los plazos vencidos, despidieron a la mitad del personal hace un año, y la mayoría del resto en julio, pero ¡vaya, ahorraron dinero en equipo!

— Bob Murphy

1

Kaz: Todo desarrollador debería tener una máquina adecuada. Si comprar nuevo hardware significa que la PC del nuevo desarrollador es un poco mejor que la de otros desarrolladores, bueno, en el peor de los casos, tiene máquinas de intercambio si son del tipo de personas que tienen el tamaño de una polla. A las personas normales simplemente no les importará mientras tengan el equipo que les permita trabajar de manera eficiente. En el lugar donde estoy trabajando actualmente, tengo una PC más nueva (probablemente más rápida) que la persona que me contrató. Las personas que vinieron después de mí tienen PC aún más nuevas, probablemente más rápidas. ¿Adivina qué? A nadie le importa, porque todas nuestras máquinas son lo suficientemente rápidas.

— user281377

3

Cuando el hardware es inadecuado, hago un punto para informar a la gerencia, generalmente haciendo un trabajo útil como cortarme las uñas de los pies o leer el periódico durante compilaciones largas. Me sale la vieja máquina lenta? Claro, no hay problema. Oh, tienes una corrección de errores prisa y me has tiene que hacer la acumulación? Claro, señor-gerente-bwana-sahib-amigo - ¡nos vemos en 90 minutos! (Una vez que un gerente me preguntó qué hacía todo el día, le dije "Re-construí la aplicación. Cuatro veces". "¿EN OCHO HORAS?!?", Gritó. Eso tomó 10 horas ". Nueva máquina apareció no mucho después ... :-)

— Bob Jarvis

71

Podemos ahorrar dinero haciendo que los programadores se doblen como probadores / escritores técnicos

Si está pagando salarios de programador por el trabajo de probador / escritor técnico, está desperdiciando dinero y es probable que obtenga un trabajo de menor calidad que alguien que ha dedicado su carrera a esa tarea. Además, cuando un programador se enfrenta a una fecha límite ajustada, es muy probable que las pruebas y la documentación se caigan o se hagan a medias para cumplirlo.

Por cierto: los desarrolladores SIEMPRE se enfrentan a un plazo ajustado.

— revs JohnFx
fuente

12

La gente inteligente puede hacer cualquier cosa bien falacia.

— Jon Hopkins

3

He hecho la entrada de datos, aunque ciertamente no iba a bajar mis tarifas por ello. Querían a alguien que fuera rápido y preciso para la entrada de datos críticos, y no les importaba pagar al menos el triple de las tasas de entrada de datos. Su elección.

— David Thornley

1

Yo diría que es el trabajo de los programadores probar su código, pero no estoy seguro de si a eso se refería.

— Ben Lakey

3

Los programadores deben probar su propio código, no con la exclusión de contar con probadores dedicados que son profesionales en romper software.

— JohnFx

1

De acuerdo sobre la redacción técnica, en desacuerdo sobre las pruebas. Las pruebas son una parte natural de escribir un buen software. La escritura técnica es un cambio demasiado grande de la codificación. Encuentro que necesito cambiar muchos engranajes para pasar de la codificación a la escritura técnica y se siente como un mal uso de mi tiempo.

— Adam Bruss

63

El código de investigación / lectura / escritura no relacionado con el desarrollo del producto es un desperdicio de recursos.

Algunos programadores e incluso gerentes creen en eso. Normalmente, solo hacen programación basada en el conocimiento en sus cabezas, e investigan y buscan respuestas cuando enfrentan problemas. No mejoran continuamente su conocimiento de manera proactiva. En mi opinión, siempre debemos mantenernos actualizados, y el conocimiento que reunimos nos sería útil para resolver problemas existentes y futuros. Por supuesto, debe asignar su tiempo sabiamente para hacerlo.

Esto también es similar a la respuesta de Dan . Algunos gerentes solo quieren que los desarrolladores se sumerjan rápidamente y desarrollen el producto de acuerdo con los requisitos sin tener que investigar los productos existentes en el mercado.

— Gan
fuente

3

Desearía haber votado esto más de una vez.

— MAK

1

Vamos a escribir una biblioteca GUI. Vamos a construir un kit de herramientas de mensajería. Si no VENDE la pieza de software, es solo una parte de una cosa más grande, por el amor de Dios, simplemente use la implementación de otra persona. Puntos de seguridad para usar una solución de código abierto, siempre puede arreglarlo y brindarle soporte si es necesario. Si tiene el dinero para comprar soluciones con la fuente incluida, hágalo, pero tenga cuidado con la mala calidad de los componentes de software comercial. Los proveedores rara vez le venden el componente dos veces, por lo que puede sentirse decepcionado una vez que lo posee (sé que he trabajado en lugares que han sido mordidos por esto antes)

— Tim Williscroft

58

En muchos casos, la deslocalización cuesta más dinero. En mi empresa es muy difícil conseguir nuevos espacios para empleados, nos vemos obligados a externalizar. También es difícil conseguir contratistas en el sitio; hay una relación de 3: 1 en alta mar a tierra que se supone que deben mantener. En consecuencia, muchos equipos solo contratan una docena de offshore y apenas los usan, para que puedan obtener 4 contratistas en el sitio.

— Jeremy
fuente

18

+1. Mi experiencia con la deslocalización es que inevitablemente cuesta mucho más dinero del que ahorra.

— Adam Crossland

2

+1, pero en alta mar puede funcionar si se usa correctamente

3

+1. Parece que tenemos diferentes desarrolladores off-shore en cada nuevo proyecto, lo que significa que los desarrolladores on-shore pasan la mayor parte de su tiempo enseñando a los nuevos desarrolladores off-shore el modelo de dominio comercial y técnico, además de proporcionar soporte técnico. Fin del proyecto y se han ido a otro lado y comenzamos de nuevo con el siguiente grupo de desarrolladores 'baratos'.

— Chris Knight

8

muchos equipos solo contratan una docena de offshore y apenas los usan, para que puedan obtener 4 contratistas en el sitio. Guau.

— Poolie

1

Y olvidando que la deslocalización, por su propia naturaleza, extenderá el plazo. Tenemos un control de calidad en alta mar y puede llevar entre 3 y 4 días volver a vender algo que dos personas en la misma oficina podrían volver a resolver en menos de una hora debido a las diferencias de tiempo.

— HLGEM

50

¡Largos bucles de retroalimentación!

Le sucede a todos: construyes algo que crees que es increíble y resulta que te equivocaste. Ese no es el problema. El problema es cuánto tiempo pasas construyendo antes de descubrir que debes parar.

En el nivel superior, ve este problema con ciclos de lanzamiento largos. Si construyes durante un año sin comentarios, estás jugando todo el año. Cuanto más a menudo suelte, más pequeños serán sus juegos de azar y mejor será el juego.

Pero también ocurre en los niveles más bajos. Como desarrollador, realmente me gustan las revisiones frecuentes de código (o, mejor, la programación de pares) porque limita la cantidad de tiempo que puedo seguir haciendo algo tonto antes de que alguien diga: "¡Oye, hay una manera más simple!" Por la misma razón, me gusta que mis pruebas unitarias se ejecuten rápida y frecuentemente, para poder atrapar y matar insectos antes de que crezcan.

Una vez que comience a notar la importancia de los ciclos de retroalimentación cortos, lo verá en todas partes. Por ejemplo, la noción militar del bucle OODA .

— William Pietri
fuente

66

+1. Además: cuanto más largo sea el ciclo de retroalimentación, menos recordará sobre la tarea. En el extremo, debe volver a familiarizarse con toda la base de código nuevamente.

— Joseph Tanenbaum

¿Cómo es una economía falsa? ¿Cuál es el ahorro previsto?

— Chris Pitman

La intención es ahorrar tiempo "perdido" en las cosas que haces en cada ciclo. Por ejemplo, construir, probar, liberar, prestar atención a los usuarios. Esa es la excusa, de todos modos. Creo que está realmente enraizado en evitar las molestias.

— William Pietri

Es por eso que es imperativo que los revisores y amigos de pareja tengan la mayor humildad y respeto por el codificador tanto como sea posible. Un crítico problemático que trata mal al codificador y puede garantizar que el ciclo de retroalimentación crecerá mucho.

— Jonathan Neufeld

47

No es mi propia anécdota, pero una vez escuché de una tienda que dejó de proporcionar café gratis a sus desarrolladores, diciéndoles que en cualquier momento que quisieran tomar café, tenían la libertad de caminar a la cafetería más cercana (algo así como diez minutos viaje en cada sentido) y compre algunos.

Más o menos la definición de falsa economía.

— EricBoersma
fuente

44

Eso es muy especial Compare y contraste con algunos de los bancos mercantes en Londres que tenían un Starbucks subsidiado construido en el edificio para eliminar el tiempo que tomaba salir y tomar café.

— Jon Hopkins

48

No estoy de acuerdo con que esto sea automáticamente una economía falsa: los 10 minutos de aire fresco mientras camina al aire libre para comprar el café oxigenarán al empleado y mejorarán su concentración y la interacción social (aunque limitada) reducirá la depresión, especialmente en invierno. Aquellos empleados que no recibirán café porque no es gratis, probablemente irán a casa a tiempo, dormirán más y tendrán una mejor salud debido a la ingesta reducida de cafeína.

— JBRWilkinson

66

-1, una caminata de 20 minutos es perfecta para liberar tu mente y obtener una nueva perspectiva del problema.

— Malfist

23

@Malfist: Según lo entendí, no fue solo la caminata de 20 minutos, sino también la espera de 15 minutos para tomar el café que interrumpió el trabajo. Un descanso de 45 minutos en cualquier momento del día va a destruir la productividad durante más de una hora y media. Todo para ahorrar 100 dólares al mes en café.

— EricBoersma

8

20 + 15 = 35 [seis caracteres más]

— Malfist

47

Proporcionar estaciones de trabajo de pantalla única porque un segundo monitor es demasiado costoso . Incluso si solo le ahorra una hora de trabajo cada año, una segunda pantalla sigue siendo una buena inversión. Sé con certeza que el mío me ha ahorrado muchas, muchas horas de trabajo.

Una configuración de varios monitores puede hacer que casi cualquier tarea sea más eficiente, no solo las tareas de desarrollo. Tres monitores son incluso mejores que dos, pero el efecto se vuelve menos pronunciado con cada pantalla adicional.

Configuraciones de monitores múltiples:

disminuir la sobrecarga de cambio de ventana
le permite vigilar las cosas que se ejecutan en segundo plano (correo, compilación, etc.).
darte una sensación de libertad. Es como estar en un atrio frente a estar en un armario de escobas.
etc ...

— Arjen Kruithof
fuente

2

Estaba enfrentando exactamente ese problema una vez. Escribí un correo a uno de nuestros CEO calculando explícitamente que, dado un aumento del 5% en la eficiencia, habría ahorrado una cantidad de dinero que valía la pena en aproximadamente medio mes en relación con mis ingresos netos. Este cálculo fue bastante férreo ... pero ... supongo que ya sabes el final de la historia :)

— Raffael

39

El hardware más barato dado a un consultor cuando el consultor cuesta más de 150 $ / hora .

Poniéndolo en perspectiva, un mejor hardware puede al menos hacer que el trabajo sea 30 minutos más efectivo por día. Eso daría 30 minutos * 20 días de trabajo por mes = 600 minutos / mes = 10 horas / mes> más de 1 día de trabajo = 10 horas * 150 $ / hora = 1500 $

Ahora, ¿no sería un consultor más eficiente si tuviera una computadora de $ 1500? ¿Haría que el consultor esté menos irritado?

Ahora el problema parece ser que hay dos presupuestos, uno para el consultor y otro para el hardware de la PC.

— Amir Rezaei
fuente

8

Como consultor, estuve allí, hice eso y obtuve la camiseta. (Sin embargo, solo obtuve $ 80 / hora.) Pero bueno, esa es una razón por la que me gusta la contratación por hora. A diferencia de un puesto asalariado, si un cliente de consultoría decide perder mi tiempo y tengo que trabajar extra para compensarlo, eso es más dinero en mi bolsillo.

— Bob Murphy

2

Sin ofender, pero si estoy pagando $ 150 / hr por un consultor, será mejor que tenga su propia computadora.

— Steven Evers

8

@SnOrfus: Eso no suele funcionar en el entorno corporativo, donde hay un control estricto de las PC que están permitidas en el dominio. Tienes que proporcionarles hardware.

— HardCode

1

@ HardCode - Sí, supongo. Puedo ver el punto ahora.

— Steven Evers

3

@HardCode En un proyecto reciente, en lugar de agregarnos (contratistas) a su red corporativa interna, nos pusieron en cuarentena a nuestra propia línea DSL. Una línea de DSL dedicada para 3 desarrolladores @ $ 40 al mes es un cambio radical y nos facilitó enviar actualizaciones de forma remota sin poner en pánico al personal de TI. Además, si la PC de producción que ejecuta nuestro código se infecta y falla, automáticamente es nuestra culpa, ya que somos responsables de la seguridad de nuestras comunicaciones y computadoras portátiles personales. ¿Puedes decir ganar-ganar-ganar?

— Evan Plaice

38

Meses de trabajo ahorran días de planificación

(No invertir suficiente tiempo en la planificación)

— serg
fuente

21

En la escuela de posgrado se decía que unas pocas semanas en el laboratorio pueden ahorrarte una hora de biblioteca.

— David Thornley

77

Sip. Cuando estaba tomando una clase de laboratorio de pregrado donde identificamos productos químicos desconocidos, el profesor nos dijo "una hora en la biblioteca los salvará a cuatro en el laboratorio". Lo tomé en serio, y fue muy divertido entrar al laboratorio durante una hora a la semana y obtener una mirada desagradable de los premedicos que pasaban doce horas a la semana haciendo pruebas de aminas en compuestos que claramente no eran aminas. Y cuando enseñé en el mismo laboratorio varios años después, les di a los estudiantes el mismo consejo, y solo unos pocos lo tomaron.

— Bob Murphy

3

Si no puede planear, planea fallar

27

Sospecho que lo más frecuente es que los gerentes simplemente no proporcionan a los desarrolladores las herramientas que necesitan para hacer su trabajo de manera eficiente.

Básicamente, punto 9 en la prueba de Joel .

— richeym
fuente

2

He estado en proyectos en los que nos harían desperdiciar una o dos semanas en lugar de comprar, por ejemplo, una biblioteca por $ 300 con el trabajo ya realizado, y mejor (no somos "desarrolladores de control" donde trabajo). O elija alguna herramienta de software "porque está hecha por" esta o aquella "compañía" en lugar de buscar si hay mejores alternativas, luego haga nuestra vida un infierno por años.

— MetalMikester

Me he encontrado con eso yo mismo. El razonamiento de PM / cliente fue que no teníamos un artículo presupuestario para comprar cosas para el cliente (los cambios de contacto fueron un poco molestos), por lo que tendríamos que reinventar la rueda (nuevamente).

— Ken Henderson

24

Desafortunadamente, todavía se puede usar "arrojar (suficientes) cuerpos al problema" en algunos lugares. La Ley de Brook contrarresta esto de The Mythical Man-Month , aunque algunos requieren experiencia para aprender esta lección. En general, esto no es algo que pueda detener, ya que la gerencia puede creer la declaración falsa sobre agregar personas y no tener que pagar un precio por ello.

— JB King
fuente

2

+1. Oh, dios, sí. Esto está sucediendo actualmente en una escala épica en un proyecto importante donde trabajo.

— Bobby Tables

3

Trabajo con un grupo de líderes de proyectos, gerentes, etc., todos los cuales tienen su certificación de gestión de proyectos tan maravillosa (como sea que se llame) y NINGUNO DE ELLOS había oído hablar de The Mythical Man-Month antes de presentarlos. lo. Sheesh!

— Bob Jarvis

2

Escuché una gran cita sobre esto una vez: 9 mujeres no pueden tener un bebé en un mes

— Richard

@ Richard Usé ese en una reunión. me dio un placer inmenso!

— Tjaart

21

Reuniones diarias :

(meeting duration in hours) x (Y team members) x (average salary per hour) = ...

— Zzz
fuente

99

Tener una reunión solo por tener una reunión ...

— Gan

55

Agenda para hoy: ¿Cuál será la agenda para la reunión de mañana?

— Mark C

99

Las reuniones diarias están bien si son cortas; Las reuniones stand-up de 3 minutos al estilo Scrum no pierden mucho tiempo, pero mantienen a todos al tanto de los desarrollos de los demás. Sin embargo, las largas reuniones con numerosos participantes desinteresados son tóxicas.

— 9000

3

@ Mark C - Puede sonar como una broma, pero en realidad me invitaron a reuniones para planificar cuál sería la agenda de los próximos días ...

— Gavin Coates

@Gavin Coates es una realidad y una situación ... :)

— Zzz

20

Comprar software estándar en lugar de desarrollarlo internamente.

Tengo experiencia en sistemas de gestión de escala empresarial, enfocados tanto en RRHH como en laboratorios biológicos.

Una solución estándar costaba £ 50-100k y necesitaba un mayor desarrollo y personalización para cumplir con los requisitos del negocio.

La solución desarrollada internamente tardó (<6) meses en desarrollarse, y otros proyectos se trabajaron en paralelo, y utilizó un desarrollador ya empleado.

Pasé del sector público donde teníamos un LIMS (sistema de gestión de información de laboratorio) desarrollado internamente a una gran industria farmacéutica internacional donde la implementación de una solución estándar había llevado más de un año y no había sido completada.

(6 meses de un desarrollador ya contratado que trabaja en otros proyectos en paralelo. Entonces ~ 10k. Y eso no incluye los costos de soporte asociados con la solución estándar). ¡El punto principal es que el sistema desarrollado internamente realmente se estaba utilizando! Entonces, tiene el beneficio de costo adicional asociado con eso, que no puedo calcular.

Estoy de acuerdo con sitios web básicos, etc., ¿por qué molestarse en desarrollar el suyo propio? Pero para cualquier sistema complejo grande y si ya tienes habilidades internas, lo construiría yo mismo .

— NimChimpsky
fuente

26

Apuesto a que también hay un montón de ejemplos de lo contrario.

— Jon Hopkins el

13

Comprar o desarrollar se reduce a las personas adecuadas que realizan la debida diligencia. Simple como eso. Piensa antes de actuar. (+1)

— DevSolo

44

@DevSolo: en el clavo. La decisión de construir o comprar debe estar respaldada por un análisis de costo-beneficio, en lugar de una actitud emotiva de "no inventado aquí" o "Amo el software de XXX".

— JBRWilkinson

99

Si va a hacer una declaración general sobre compilación vs. compra, debería ser: prefiera comprar soluciones a problemas que no son parte de la competencia central de su empresa. No siempre es la respuesta correcta, pero es una posición predeterminada sensata y tan confiable como un cliché. Sin embargo, decir que comprar un software estándar es una economía falsa, ni siquiera es un cliché útil. Siento que su dolor fue por las soluciones 'E' (que se supone que significa 'Enterprise', pero realmente significa 'Caro' '). Pero la presencia de malas opciones no significa que no haya buenas por ahí.

— evadeflow

2

Creo que el problema es comprar y luego seguir necesitando un mayor desarrollo y personalización , el costo de una pequeña personalización en un gran sistema incorporado a menudo puede ser más que escribir su propio sistema pequeño que simplemente hace lo que desea. Por lo tanto, compre si puede trabajar de la manera en que el sistema que está comprando espera que funcione, ¡pero comprar y personalizar puede dar lo peor de ambos lados!

— Ian

15

Comprar productos caros disponibles cuando las alternativas de código abierto son mejores y gratuitas.

¿Cuántas empresas usan git? ¿Cuántas empresas usan algún control de versión empresarial de mala calidad?

— Hasen
fuente

1

Erm, ¿se puede considerar "la peor economía falsa"? ¿O probablemente necesites elaborar más ...?

— Gan

3

No estoy seguro de estar completamente de acuerdo con el ejemplo de control de fuente, como mínimo. Git fue diseñado específicamente para resolver problemas de código abierto: muchos desarrolladores, poco control central, muchas sucursales, etc. El software "empresarial" funciona bajo un conjunto diferente de supuestos: la necesidad de administrar una variedad de productos en un negocio, seguridad, flujo de trabajo, etc.

— PeterAllenWebb

1

@Gan: Piensan que usar código abierto es la economía falsa, pero lo tienen todo al revés.

— hasen

3

Soy colaborador de X11 y GNOME, y bastante competente en el uso de git y la administración de servidores de gitosis. Sin embargo, este verano cambié mi trabajo de consultoría de git a un servidor Perforce pagado personalmente porque hace muchas cosas automáticamente que tienes que hacer manualmente con git. Dado que me pagan por entregar el código y no perder el tiempo con el control de versiones, usar y pagar el "control de versiones empresarial de mala calidad" es mucho más rentable que usar git.

— Bob Murphy

77

El código abierto frente a los productos comerciales es realmente una base "caso por caso" en mi experiencia.

— MetalMikester

14

Usar lenguajes "simples" sin mucha expresividad

Sí, hace que sea más fácil encontrar programadores para mantener el código, pero hace que sea más difícil encontrar buenos programadores que no solo aprendan la última palabra de moda que los contratará. Sí, hace que el código de bits individuales sea más fácil de entender, pero también lo hace tan rígido como un 2x4 y aumenta el volumen de código que necesita ser entendido. Sí, está respaldado por una gran corporación, pero dijo que una gran corporación innova de manera lenta y burocrática.

— dsimcha
fuente

44

@burnt_hand: Básicamente me refiero a la excesiva aversión al riesgo de la gerencia en términos de elección de idioma.

— dsimcha

1

+1: Sigue usando C porque "tenemos esas habilidades y aprender un lenguaje nuevo y sofisticado como Python / Perl / PHP aumenta mucho el riesgo". Lo escuché más de una vez. ¿Eso significa que el equipo es demasiado estúpido para aprender un nuevo idioma?

— S.Lott

1

@ S.Lott Los agentes de reclutamiento piensan que eres !, pero esa es otra historia

— burnt_hand

2

es decir, compañías que se apegan a Java y C # y tienen demasiado miedo de tocar python o ruby porque no son "estándar de la industria", lo que me recuerda a: paulgraham.com/avg.html

— hasen

1

@hansen: El ensayo de Paul Graham es en parte lo que me inspiró a escribir esta publicación. Mi otra inspiración fue mi trabajo desarrollando bibliotecas (incluida la biblioteca estándar) para el lenguaje de programación D.

— dsimcha

13

Malos gerentes de proyecto / jefe de equipo.

Dado que una persona incompetente tiene el poder de arruinar el trabajo de un grupo de personas. Al final, el proyecto funcionaría mucho mejor sin las decisiones de la alta gerencia (proyecto / equipo líder).

Dosifica el "Solo hazlo rápido, refactorizaremos más tarde" decide.

— Amir Rezaei
fuente

44

Estoy de acuerdo en que hay malos gerentes, pero ¿"el proyecto sería mucho mejor sin las decisiones de la alta gerencia"? En general, estas son las personas que patrocinan el proyecto. Esto me parece un poco como los desarrolladores que he conocido que piensan que comprender la tecnología es más importante que comprender el negocio y olvidar quién es el cliente real.

— Jon Hopkins el

2

@ Jon Hopkins Con la alta gerencia no refiero al cliente. El punto es que los "malos gerentes de proyecto" son aquellos que cometen errores tras errores y van en contra de un grupo de personas. ¿Quién crees que decide "Hazlo rápido, refactorizaremos más tarde". ¡Lee la respuesta con la tasa más alta!

— Amir Rezaei

Ah, más claro. Quito mi -1.

— Jon Hopkins el

He notado una tendencia inquietante de los gerentes de proyecto que invierten el tiempo y el costo sobre la calidad. Estoy seguro de que no soy el único. A los PM les gusta usar el diagrama triangular con Costo / Calidad / Tiempo en él, pero la Calidad siempre se inicia primero. Es muy triste, e institucionalizar y forzar las métricas de gestión de proyectos (PMI) en algo tan complicado como el software solo parece empeorar las cosas.

— Bernard Dy el

1

@Bernard: el tiempo y el costo son medibles. ¿Calidad? No tanto. Triste pero IMO cierto ...

— Bob Jarvis

12

Faltan requisitos del usuario

Un paso importante y difícil de diseñar un producto de software es determinar lo que el cliente realmente quiere que haga.

Lo creas o no, a veces falta esta parte o está desactualizada. El costo es que uno crea funcionalidades que el usuario final nunca solicitó.

— Amir Rezaei
fuente

Creo que esto debería estar en la cima!

— Roopesh Shenoy

8

La productividad vale más que la creatividad.

La creatividad es difícil de medir en general, y la mayoría de las veces es imposible de observar, no importa medir, cuando se trata del desarrollo de software. La productividad, por otro lado, se puede medir (a menudo deficientemente) y se puede observar.

Como resultado, los desarrolladores que pueden (escribir más líneas de código | escribir código más rápido | recitar technobabble más rápido en respuesta a preguntas | son más visiblemente productivos) tienden a ser valorados más que aquellos que (usan menos líneas de código para resolver el mismo problema | tomar más tiempo para escribir el código, pero producir un producto más confiable | comprender el tema lo suficientemente bien como para responder preguntas en inglés simple y fácil de entender (resolver problemas de forma creativa).

— blueberryfields
fuente

6

Todo lo siguiente puede ser malo cuando se usa o no se usa inapropiadamente

software externo vs interno
Cumplimiento de ISO 9001 (economía: una mitigación de un riesgo de pérdida de MSS si la calidad del producto disminuye)
desarrollo / QA outsourcing
desarrollo / construcción / lanzamiento / procedimientos de soporte

— revs bobah
fuente

¿Cómo es ISO 9001 una (falsa) "economía"?

— Andrew Grimm

@Andrew Grimm: el cumplimiento garantiza cierto nivel de calidad que mitiga los riesgos derivados de la mala calidad (pérdida de MSS, por ejemplo) para que la economía potencial sea clara. Para los departamentos pequeños, esto puede ser inapropiado porque las pérdidas en los gastos generales son mayores que las del riesgo potencial

— bobah

1

@ Andrew: en mi experiencia, depende de lo que quieras. Si desea que aumente la calidad, probablemente sea una economía falsa, ya que tiende a ser costosa y puede no ser adecuada para el software. Si lo quiere como una cosa de marketing o porque se espera en su industria, es una buena idea.

— Jon Hopkins el

55

@Andrew Grimm: lo "único" que garantiza ISO 9001 es una calidad constante y repetible. No garantiza la "alta" calidad. Sin embargo, si una calificación ISO 9001 es lo que se requiere en el espacio de mercado en el que la compañía quiere estar, entonces se requiere.

— Vatine

1

@Vatine: lo que ISO 9001 garantiza es un proceso consistente y repetible. En algunos campos, donde los procesos consistentes producen una calidad consistente, eso es importante. No garantiza una alta calidad, pero si un cliente ve algo que ha hecho bien y sabe que tiene la certificación ISO 9001, confiará en una calidad similar.

— David Thornley

4

Tener demasiados gerentes de entrega no facturables.

Hace un par de años, en nuestra empresa teníamos varios proyectos de gran presupuesto en marcha y el reclutamiento estaba en su apogeo. En ese momento, nuestra compañía contrató a demasiados gerentes de entrega (¡Muchos de ellos no eran de TI!) Y muy pocos codificadores / evaluadores. La relación de gerente a programador fue literalmente 1: 2. Más tarde, después de completar esos proyectos, tuvimos una situación en la que tuvimos a muchos de estos gerentes (algunos de ellos eran verdaderos holgazanes) sentados en el banco sin hacer nada. Tuvimos un ciclo de evaluación en el que todos obtuvieron poco o ningún aumento (incluso nosotros, los programadores trabajadores, suspiramos) para que la empresa no tenga que despedir a nadie. Afortunadamente, la compañía se dio cuenta de esta situación e hizo el RIGHTTSIZING en el primer trimestre de este año.

— mananjani
fuente

3

Optimización antes de perfilar (también conocida como optimización prematura).

Muchas veces he visto a alguien buscar una solución inteligente que complica innecesariamente el mantenimiento y la legibilidad debido a que es más rápido. Naturalmente, el código no ha sido marcado (ni siquiera con micro-puntos de referencia), por lo que rápidamente se vuelve "más rápido basado en el argumento más persuasivo" sobre una sección de código que probablemente no tuvo un impacto en el rendimiento general de todo aplicación por mucho.

Como tal, es una economía muy falsa, y el tipo de economía falsa que ocasionalmente enreda incluso a los profesionales experimentados.

— Edwin Buck
fuente

3

Acceso limitado o nulo a internet

Porque, obviamente, sus empleados usarán Internet para jugar juegos de Facebook, no investigar demasiado las respuestas a preguntas técnicas sobre Stackoverflow.

En realidad, por supuesto, Internet es un gran impulso de productividad, y si bien puede ser apropiado usar algún tipo de filtro de sitio para sitios genuinamente dudosos, hay algo mal si está bloqueando el archivo Léame de Visual Studio o las páginas del gobierno local de Telford por alguna razón. "turismo sexual"

— jk.
fuente

2

Hacer que sus desarrolladores usen un monitor de 15 pulgadas y una PC de baja especificación, ya que es el estándar corporativo.

Los monitores de tamaño razonable son baratos, rápidos de instalar y hacen que los programadores sean más productivos, además de hacer que sus programadores piensen que se preocupa por ellos.

— Ian
fuente

2

Demasiados licenciados en administración de empresas (o similares), organizados jerárquicamente, que intentan aplicar lo que creen que es la gestión moderna: molestar a las personas con "KPI", "SLA" y qué no, requerir "informes" (sin, por supuesto, preocuparse por la infraestructura para generarlos), de modo que los programadores pierdan sus días rellenando elegantes hojas EXCEL, informes Q4 y demás, y copie de una gran herramienta de administración nueva y pegue en otra (parece ser la regla que estas herramientas nunca están integradas ni integradas entre sí) y asisten a reuniones donde se presentan los informes y las cifras (y todos se sienten culpables por no haber cumplido con este o aquel KPI).

— Ingo
fuente