¿Darle a un desarrollador una máquina de desarrollo más lenta da como resultado un código más rápido / más eficiente? [cerrado]

130

Supongamos que les doy a mis desarrolladores una máquina que grita rápidamente. VS2010 basado en WPF se carga muy rápidamente. Luego, el desarrollador crea una aplicación WPF o WPF / e que funciona bien en su caja, pero mucho más lenta en el mundo real.

Esta pregunta tiene dos partes ...

1) Si le doy a un desarrollador una máquina más lenta, ¿eso significa que el código resultante puede ser más rápido o más eficiente?

2) ¿Qué puedo hacer para brindarles a mis desarrolladores una experiencia IDE rápida, mientras les doy experiencias de tiempo de ejecución 'típicas'?

Actualizar:

Para el registro, estoy preparando mi respuesta imparcial a la gerencia. Esta no es mi idea, y ustedes me están ayudando a corregir las solicitudes equivocadas de mi cliente. Gracias por darme más municiones y referencias a dónde y cuándo abordar esto. He hecho +1 en casos de uso válidos, tales como:
- optimizaciones específicas de programación del lado del servidor
- laboratorios de prueba
- la posibilidad de comprar un mejor servidor en lugar de las mejores tarjetas gráficas

makerofthings7
fuente
20
¡Quizás haga que prueben la aplicación en una PC virtual!
Mark C
209
Estoy sin palabras de que esto sea incluso una pregunta. ¿Cómo podría resultar en algo más que un desarrollo más lento y una moral deficiente?
Fosco
76
Desarrollar sobre el estado del arte. Prueba en la peor máquina que puedas encontrar.
Adam
14
¿Limpiar el piso con un cepillo de dientes en lugar de un trapeador resulta en un piso más limpio? Claro que sí, eventualmente. Un operador de trapeador no puede detectar la suciedad de 150 cm de distancia tan bien como un operador de cepillo de dientes a 30 cm de distancia. No intentes con un piso grande.
dbkk
13
Nota personal: nunca trabajes para MakerofThings7
matt b

Respuestas:

234

Absolutamente

También es cierto que los gerentes deben realizar todas las reuniones en Pig-Latin. Mejora sus habilidades de comunicación en general para que estén en desventaja al hablar oraciones simples. Tendrán que confiar más en las expresiones faciales y el lenguaje corporal para transmitir su punto de vista y todos sabemos que de todos modos es al menos el 70% de toda la comunicación.

Los directores financieros deben usar solo un ábaco y tiza. De lo contrario, terminan confiando demasiado en 'datos en bruto' y no lo suficiente en su 'instinto'.

Y se debe exigir a los vicepresidentes y superiores que celebren todas las reuniones de negocios importantes en entornos que distraigan, como campos de golf, mientras están semi intoxicados. Oh chasquido ...

Jay Beavers
fuente
85
Me gustó el sarcasmo. +1
Terence Ponce
8
Los vicepresidentes y los superiores a menudo están haciendo una red pura: el objetivo de la reunión es jugar al golf borracho. Cuando llegas a un nivel realmente alto, puedes intoxicarte y jugar al golf mientras eliges los países a los que invadir, y a quién dar contratos de defensa.
Dan Rosenstark el
1
No veo sarcasmo aquí. +1
FinnNk
376

La respuesta es (seré audaz y diré) siempre

NO .

Desarrolle con lo mejor que pueda obtener con su presupuesto, y pruebe en la gama de equipamiento min-max spec que implementará.

Hay emuladores, máquinas virtuales, máquinas reales con probadores que pueden probar el rendimiento para ver si es un factor.

peterchen
fuente
10
No puedo votar más de una vez, aunque desearía poder hacerlo. Tengo una computadora antigua en la que trabajo y el tiempo que tarda VS2010 en realizar algunas tareas (por ejemplo, abrir el proyecto) puede ser bastante molesto.
rjzii
108
¿Puedes hacer que el no sea muy grande y audaz?
Dr. Hannibal Lecter
44
Las pruebas de aceptación que realice deben cubrir los requisitos de rendimiento. Debería haber requisitos de rendimiento. Si no prueba el rendimiento, sus evaluadores se denominan clientes (y les cobra dinero).
Tim Williscroft
2
Concuerdo completamente. Darle a un desarrollador máquinas más lentas no producirá mejor código. El desarrollador se sentirá frustrado con la máquina y siempre tendrá algo de inquietud. Hace peor código, y no pueden concentrarse mucho cuando todo se atasca. Verán, uno tendrá un IDE como Eclipse, digamos 2 libros en pdf, 2 navegadores web, uno para ejecutar la depuración (en caso de desarrollo basado en la web), un servidor en ejecución y un reproductor de música;) Dele una máquina lenta y él te besará adiós.
1
La respuesta no es incorrecta. ¡La respuesta correcta es Nooooooooo!
Pekka 웃
70

1) Muy, muy poco probable. No, y sus desarrolladores pueden poner algo desagradable en su café por sugerirlo. Tiempo que sus desarrolladores pasan esperando que el código se compile o que el IDE haga lo que esté haciendo o el tiempo que no estén dedicando a mejorar el código. También interrumpe su flujo mental. Mantenga sus mentes en el problema y serán mucho más eficientes resolviendo ese problema.

2) Proporcione a cada una una segunda PC que represente las especificaciones más bajas que desea que admitan realmente, con un conmutador KVM para ir entre eso y su estación de trabajo real.

BlairHippo
fuente
Me gusta la idea de usar un KVM con una PC vieja para probar. Dependiendo del proyecto, puede ser engorroso para los desarrolladores instalar las últimas compilaciones en la máquina lenta cada vez que se les ocurre una nueva compilación.
Al Crowley
44
Otra cosa a considerar es darles una cuenta en al menos la segunda PC que no tiene privilegios administrativos.
David Thornley
43

Me gustan los largos tiempos de compilación. Me da más tiempo para trabajar en mi currículum.

Wonko el cuerdo
fuente
1
jejeje, cuanto más tiempo mejor!
Newtopian
33

Esta es una idea terrible. Desea que sus desarrolladores sean lo más productivos posible, lo que significa darles una máquina lo más rápida posible, para que no se queden sentados todo el día esperando que las cosas se compilen. (Ligeramente OT, pero también ayuda a no bloquear el acceso a sitios potencialmente útiles con WebSense y similares). con especificaciones similares, y asegúrese de realizar una prueba temprana y, a menudo, para asegurarse de que no va por el camino equivocado en términos de opciones tecnológicas.

o. nate
fuente
quien ... espera un minuto. Si las compilaciones fueran rápidas, esto ya no sería posible: xkcd.com/303
gbjbaanb
32

El desarrollo debe realizarse en el mejor entorno que sea factible. Las pruebas deben realizarse en el peor entorno posible.

Yevgeniy Brikman
fuente
27

Si me dieran una máquina lenta, me pasaría el día optimizando el proceso de desarrollo y no optimizando mi código entregado. Entonces: ¡NO!

usuario6015
fuente
26

¡Los programadores de sistemas integrados se topan con esto todo el tiempo! Y hay una solución de dos partes:

  1. Sus requisitos deben especificar el rendimiento X en el hardware Y.
  2. Prueba en hardware Y, y cuando no obtengas rendimiento X, errores de archivo.

Entonces no importará en qué hardware trabajen sus desarrolladores.

Una vez que haya hecho eso, supongamos que un equipo más rápido puede ahorrarles a sus programadores media hora al día o 125 horas en un año. Y supongamos que cuestan $ 100,000 al año con beneficios y gastos generales (ridículamente bajos para Silicon Valley), o $ 50 por hora. Que 125 horas * $ 50 / hora es $ 6250. Entonces, si gasta menos de $ 6250 al año en hardware de desarrollo rockin 'por programador, está ahorrando dinero.

Eso es lo que debe decirle a su gerencia.

Tim Williscroft dijo más o menos la primera mitad de esto en un comentario, y en un mundo justo, obtendría la mitad de los puntos que obtenga esta respuesta.


Agregado el 24 de octubre:

Mi ex empleador tenía esa teoría, y les ayudó a gastar alrededor de $ 100 millones.

Son un conglomerado con sede en Japón que estaba acostumbrado a contratar programadores en Japón, Corea y China. La gente allí es genial con el uso de hardware de desarrollo horrible, días de trabajo de 13 horas, dormir en sus escritorios y no tener una vida. Así que pensaron que cuando adquirieron una conocida empresa de Silicon Valley para hacer un sistema operativo de teléfono celular basado en Linux, esos californianos tontos que querían equipo moderno eran simplemente prima donnas y realmente no tenían una buena razón para ello (como la productividad).

Cuatro años más tarde, el sistema operativo funcionó como una mierda, todos los horarios se vencieron, y los clientes se enojaron y rescindieron los contratos de derecha a izquierda. Finalmente, el proyecto del SO fue cancelado, y un gran porcentaje de la fuerza laboral mundial del conglomerado fue despedido durante el último año. Y, francamente, no quisiera haber sido uno de los ejecutivos que tuvo que explicar a los accionistas a dónde se fue todo ese dinero y esfuerzo.

No fueron solo las máquinas de lento desarrollo las que causaron este fiasco. Hubo muchos otros errores estratégicos y tácticos, pero eran el mismo tipo de cosas en las que las personas que trabajan en las trincheras podían ver venir el choque del tren, y se preguntaban por qué los tomadores de decisiones no podían.

Y la marcha lenta fue sin duda un factor. Después de todo, si está bajo la pistola para entregar a tiempo, ¿es realmente algo inteligente retrasar deliberadamente el trabajo?

Bob Murphy
fuente
+1 incluso treinta minutos puede ser una estimación muy modesta en algunos círculos.
justin
20

En programación, hay un viejo dicho que dice que " la optimización prematura es la raíz de todo mal ". Creo que has logrado crear con éxito otra "raíz" (o al menos la primera rama) de todo mal. De ahora en adelante, podemos decir "la desoptimización prematura del desarrollador es la raíz de todo mal".

En resumen, la respuesta es que esto solo ralentizará su tiempo de desarrollo y dificultará aún más el mantenimiento. Los tiempos de compilación tomarán más tiempo, la búsqueda de código en el disco será más lenta, la búsqueda de respuestas en línea tomará más tiempo y, lo que es más importante, los desarrolladores comenzarán a utilizar su código de forma prematura para incluso poder probar la funcionalidad necesaria.

Ese último punto es el tema más crítico y no se menciona en muchas de las otras respuestas. Puede obtener su primera versión bien, pero luego, cuando desee actualizar el código en el futuro, encontrará que la optimización prematura de los desarrolladores alejó su código del buen diseño y lo acercó a "tengo que hacerlo en menos trabajo para mantener mi trabajo "estilo de código. Agregar funciones adicionales se volverá más difícil porque las optimizaciones elegidas en ese momento pueden ser innecesarias y bloquear su código en una ruta de hacks semi-optimizados además de otros hacks semi-optimizados.

Como ejemplo de esto, imagine que el requisito mínimo del sistema de su versión actual es una máquina de procesador único de velocidad algo lenta. Coloca a los desarrolladores en esta caja y se les ocurre una solución intrincada de un solo subproceso que se basa en muchos hacks porque querían desarrollar el producto rápidamente. Ahora, 5 años después, tiene una nueva versión del producto que tiene un requisito mínimo de una máquina con doble procesador. Desearía poder separar limpiamente partes del programa que puede ejecutar en paralelo, pero la decisión que tomó hace 5 años que obligó a sus desarrolladores a crear un software hacky ahora le impide usar toda la potencia de su nuevo requisito mínimo. .

Lo que debe hacer es agregar una fase al final de su ciclo de desarrollo donde realice pruebas de aceptación en los cuadros de límite inferior. Ciertamente, parte del código será demasiado lento debido a la máquina más rápida del desarrollador, pero puede aislar esa parte y optimizarla allí. El resto de su código se mantiene limpio y mantenible.

Veo que su pregunta dice: "¿Puedo forzar a mis desarrolladores a que optimicen antes de tiempo dándoles máquinas de desarrolladores pobres pero que aún obtengan un buen código?" Y la respuesta es no.

Entropía Fallos
fuente
"Deberíamos olvidarnos de las pequeñas eficiencias, digamos alrededor del 97% del tiempo: la optimización prematura es la raíz de todo mal". Al diseñar algo, es una buena idea pensar durante 2 minutos sobre el 3%.
Keyo
15

Lectura interesante, todas esas respuestas.

Pero creo que la mayoría de las personas que responden aquí están perdiendo el punto. La pregunta, como lo leí, no es (solo al menos) acerca de dar realmente a los desarrolladores un P1 para hacer un código más rápido.

El punto es que una gran cantidad de software hoy es tan lento o incluso más lento que el software que usamos en el último milenio a pesar de las computadoras mucho más potentes. A juzgar por las respuestas aquí, la mayoría de los desarrolladores no entienden esa pista. Esto es muy obvio en las aplicaciones web. Este sitio es una muy buena excepción, pero muchos sitios tienen una portada en 1 mb. ¿Qué obtengo por esperar a que se descargue? No lo sé. Creo que parece tratarse de una ignorancia del desarrollador que no respeta el tiempo que el usuario necesita gastar en él, o peor aún si paga por mb. La cuestión es que todas esas páginas web ni siquiera contienen imágenes de alta resolución. A menudo es solo un código basura entregado desde un entorno de desarrollo. Bueno, por supuesto, no es un código basura, supongo, pero no me da ninguna ganancia como usuario.

En general, no se trata solo de optimizar el código, sino de elegir no incluir las cosas que se ralentizan más de lo que ofrece.

Hace unas semanas comencé una computadora portátil desde 1995. Windows 3.x estaba en funcionamiento en muy poco tiempo. La base de datos de la que debería obtener algunos datos comenzó antes de que la tecla enter se liberara por completo (casi al menos).

Sé que hoy obtenemos mucho más de nuestro software, pero también tenemos computadoras muchas veces más rápido. ¿Por qué la industria del desarrollo no decide mantener la velocidad del software desde 1995 y hacer que las personas compren nuevo hardware porque quieren una nueva funcionalidad? Hoy es más como si los programas y sitios web de todos los días obligan a las personas a comprar nuevo hardware para hacer exactamente las mismas cosas que antes. Pero, por supuesto, de una manera más elegante.

Tengo que decir que creo que el desarrollo de Linux parece manejar esto mejor. Las distribuciones de Linux han estado por muchos años muy por delante de Windows incluso en la fantasía con muchas cosas interesantes como ventanas animadas. La cosa es que a pesar de eso han trabajado en las computadoras de hoy e incluso de ayer. No solo en hardware de vanguardia.

A estas alturas supongo que muchos desarrolladores tienen un nivel poco saludable de adrenalina. Sí, encontré una manera de devolver algo de frustración de todos los que esperaban frente a:
servidor sql de oficina (iniciando la consola de administración) arcgis (iniciando y usando) acrobat reader (iniciando) agresso (usando, al menos como aplicación web) Windows (mirando y usando, bueno, todavía no he probado 7). Páginas web .net (descargando)

y así

Me siento bien :-)

Saludos
Nicklas

revs Nicklas Avén
fuente
Esta. Esta. ESTA. TANTO ESTO. Esa siempre ha sido mi mayor frustración con el software. La gente pasa más tiempo tratando de mejorar la interfaz que realmente preocuparse por la usabilidad. Un ejemplo de esto es Android vs. Blackberry. Android se ve mejor y puede hacer más, pero Blackberry es MUCHO más agradable (y rápido) de usar que Android, al menos en mi opinión.
kcoppock
1
Estoy completamente de acuerdo con el argumento sobre que el software ahora es tan rápido como lo fue hace 20 años para casi las mismas funcionalidades. Pero lograr que los desarrolladores trabajen en hardware de 20 años no ayudará en nada al problema. Si la empresa que crea el software no invierte en usabilidad y / o pruebas de rendimiento desarrolladas en hardware más lento, empeorará las cosas en todo caso. Este es un debate completamente diferente para el cual la cabeza de un programador no es el único receptor adecuado de una bofetada bien merecida detrás de la cabeza.
Newtopian
10

1) Si le doy a un desarrollador una máquina más lenta, ¿eso significa que el código resultante puede ser más rápido o más eficiente?

Hemos estado creando software durante las últimas 6 décadas, y todavía recibimos preguntas como estas. Parece más como otro intento de cortar esquinas. Sin ofender, pero vamos, ¿crees que la pregunta es incluso lógica? Piénselo en estos términos (si puede): desea construir un vehículo 4x4 que pueda operar en condiciones difíciles, lluvia, barro, lo que sea. ¿Va a colocar a sus ingenieros y a la línea de montaje debajo de los elementos solo para asegurarse de que el vehículo resultante pueda operar en ellos?

Quiero decir, ¡Jesucristo! Hay desarrollo y hay pruebas. Las pruebas se realizan en un entorno diferente y más duro, o el desarrollador sabe cómo armar un banco de pruebas en su propio entorno de desarrollo de una manera adecuada para las pruebas de estrés. Si no puede, reemplácelo con un mejor desarrollador.

2) ¿Qué puedo hacer para brindarles a mis desarrolladores una experiencia IDE rápida, mientras les doy experiencias de tiempo de ejecución 'típicas'?

Deberías preguntar eso a tus desarrolladores. Y si no pueden darle una respuesta objetiva y válida, debe reemplazarlos con desarrolladores reales.

Pero para entretener la pregunta, brinde a sus desarrolladores (suponiendo que tenga buenos desarrolladores), buenas herramientas y buen hardware, lo mejor que pueda pagar. Luego, configure un entorno de línea de base común más bajo en el que debe operar su software. Ahí es donde deberían realizarse las pruebas. Es una práctica de ingeniería mucho mejor tener un entorno de prueba que sea distinto del entorno de desarrollo (preferiblemente uno que le permita realizar pruebas de estrés).

Si sus desarrolladores son buenos, deberían haberle comunicado esto (suponiendo que se los haya pedido).

luis.espinal
fuente
1
Hemos estado creando software durante las últimas 6 décadas, y todavía recibimos preguntas como estas. - Voté tu respuesta, pero te animo a que examines la pregunta original desde una perspectiva diferente. De hecho, hay muchos gerentes que ignoran los beneficios de las máquinas rápidas y potentes para sus desarrolladores. Entonces, con eso en mente, la pregunta original puede haber sido tratar de desengañar a esos gerentes de la ridícula noción de que las máquinas lentas pueden de alguna manera empujar a los desarrolladores a producir código más rápido y más eficiente.
Jim G.
1
"2) ¿Qué puedo hacer para brindarles a mis desarrolladores una experiencia IDE rápida, mientras les doy experiencias de tiempo de ejecución 'típicas'? Deberían preguntar eso a sus desarrolladores". Creo que este es un sitio de SE para programadores, no un sitio de SE para gerentes. Estaba preguntando a los desarrolladores.
stimpy77
1
"desea construir un vehículo 4x4 que pueda operar en condiciones difíciles, lluvia, barro, lo que sea. ¿Va a poner a sus ingenieros y a la línea de ensamblaje debajo de los elementos solo para asegurarse de que el vehículo resultante pueda operar en ellos?" <<< ama la analogía
stimpy77
6

Resulta en un grupo de desarrolladores de bitchin. Esto es lo suficientemente difícil como es, no empeoremos la experiencia.

Sin embargo, le recomendaría que tenga un hardware similar a sus usuarios en un entorno de prueba o control de calidad para resolver cualquier problema de rendimiento. Es una buena idea.

bigtang
fuente
8
¿Desarrolladores que puta? De ninguna manera ...
Jé Queue
6

Romperé la norma y diré que sí SI Y SOLO si están escribiendo software de servidor. Ríete todo lo que quieras, pero el equipo más eficiente que vi fue un grupo de muchachos Perl con terminales Wyse. Esto fue a fines de la década de 1990, era una tienda de fotografía de la Universidad y estaban escribiendo software de cuadrícula espacial (que básicamente solo calcula). Sin embargo, estaban hablando con algunos RS / 6000 de modelo tardío relativamente potentes.

Solo para agregar interés al evento, había un programador ciego allí. Estaba completamente impresionado.

texto alternativo

Jé Queue
fuente
3
Programador ciego? ¿Es eso posible?
WernerCD
1
@WernerCD, hasta el día de hoy todavía intento imaginar el poder mental que debe tomar para mantener un registro de las líneas de código en mi cabeza.
Jé Queue
3
Sí, la mayoría de nosotros estamos escribiendo software de servidor ... +1
goodguys_activate
@ MakerOfThings7, dame más hardware de servidor cada día en mi máquina local, gasta $ donde debería estar (pero dame un monitor grande :)) No tengo problemas con mi Dell Latitude CPx de una década siendo una pantalla para los grandes sistemas en el DC
Jé Queue
44
¿Quizás un programador ciego podría usar una pantalla braille?
Antsan
5

Esta no es una mala idea, pero desea que sus desarrolladores tengan un entorno de programación rápido.

Posiblemente podría implementar esto dándoles a sus programadores dos máquinas: una caja de desarrollo rápida y una caja de productos más lenta (posiblemente virtual) para la prueba.

Algunos ajustes del proceso de compilación VS podrían hacer que la implementación en la caja de prueba sea la norma, con la depuración remota.

Hay otras formas de considerar forzar a sus codificadores a desarrollar un código más eficiente: puede incluir objetivos de rendimiento y uso de memoria en sus pruebas unitarias, por ejemplo. Establecer presupuestos para el uso de la memoria también es un objetivo excelente. También establecer presupuestos de peso de página para el código html.

Damien
fuente
5

El problema no es que el desarrollador construya código ineficiente en una máquina rápida, el problema es que no ha definido las métricas de rendimiento que deben medirse.

Debe definirse, como parte de los requisitos del producto, un objetivo específico que se pueda medir en todas las computadoras en función de la experiencia requerida del cliente. Existen muchos sitios web (Check SpecInt) que le permiten relacionar su computadora con otros tipos de computadoras.

Esto es bueno por muchas razones. Le permite definir el hardware mínimo compatible más fácilmente para que pueda limitar la cantidad de quejas de los clientes: todos sabemos que la mayoría del software se ejecuta en la mayoría de las computadoras, es solo una cuestión de rendimiento, si establecemos nuestras especificaciones para que las personas en el rango de requisitos mínimos tiene un rendimiento razonablemente aceptable, limita las quejas de los clientes, y luego, cuando un cliente llama, puede usar los puntos de referencia para determinar si realmente hay un problema, o si el cliente simplemente no está satisfecho con la forma en que se supone que funciona el producto.

Mike Glasspool
fuente
5

Estoy convencido de que tener una computadora más lenta para el desarrollo da como resultado un código más rápido, pero esto tiene un precio. La razón es que he experimentado esto de primera mano: después de un largo tiempo de viaje, compré una netbook para trabajar en el tren, una netbook que es más lenta que cualquier computadora que he comprado en los últimos 5 años. Debido a que todo es muy lento, veo muy rápidamente cuando algo es insoportablemente lento en este netbook, y soy consciente de los puntos lentos mucho más rápido (no es necesario comparar todo el tiempo). Trabajar en una netbook realmente cambió la forma en que me desarrollé.

Dicho esto, no estoy abogando por hacer esto, especialmente en un entorno profesional. Primero, es desmoralizante. El hecho mismo de que casi todo el mundo dijera la idea ni siquiera tenía sentido demuestra que los programadores reaccionan mal ante la idea.

En segundo lugar, tener todo más lento significa que las cosas que puede hacer en una máquina rápida (toma aproximadamente 1 minuto) ya no son factibles en una máquina lenta, debido a la pereza, etc. Es una cuestión de incentivo.

Finalmente: el código producido puede ser más rápido, pero casi seguramente tarda más en producirse.

David Cournapeau
fuente
+1 Pero tengo que estar en desacuerdo en algunos puntos. También compré una netbook, pero noté que la velocidad no es el verdadero problema, es el tamaño de la pantalla pequeña. 1GHz es lo suficientemente rápido para proyectos pequeños en movimiento, pero 1024x600 es demasiado pequeño.
Joe D
4

Punto 1, NO! Studio está diseñado para ejecutarse en máquinas decentes y ese requisito solo se ha vuelto más potente con cada versión. En realidad, puede bloquear algunas versiones de studio si activa intellisense y utiliza una caja de núcleo único no HT.

En el punto # 2 hay algunas características en los proyectos de prueba que le permiten limitar algunos recursos. No son perfectos, pero están ahí. VPC o imágenes VM de baja especificación para un trabajo bastante bueno de ser restringido también. He tenido usuarios que se sientan en máquinas malas para hacer pruebas ocasionalmente para que puedan ver las implicaciones de las funciones que han solicitado.

Cuenta
fuente
4

No, de hecho, generaría más errores porque no realizarán tantas pruebas y no utilizarán herramientas adicionales como los perfiladores. Bríndeles las mejores máquinas que pueda pagar (incluido el hardware de aceleración de gráficos si es un desarrollador de juegos o una tienda de gráficos) y haga que prueben dentro de máquinas virtuales. Las especificaciones de VM se pueden ampliar o reducir según sea necesario.

JohnL
fuente
+1: de hecho, generaría más errores porque no realizarán tantas pruebas y no utilizarán herramientas adicionales como los perfiladores. - Gran punto. No olvidemos el costo de oportunidad asociado con una máquina de desarrollo lento.
Jim G.
4

Creo que esta es una pregunta interesante, y no elegiría un "no" tan rápido. Mi opinión es: depende de qué tipo de equipo de desarrollo estamos hablando. Ejemplo: si está liderando un grupo que se postula para el concurso anual de programación ICFP, tal vez tener buenos resultados después de una pequeña cantidad de tiempo de desarrollo en un clúster HPC no significa necesariamente que la solución que encontró sea buena. Lo mismo puede decirse si está escribiendo algún algoritmo científico o numérico: en su viejo AMD Duron 600 MHz con 64 MB de memoria, se ve obligado a tener cuidado con la forma en que está haciendo las cosas, y esto puede afectar incluso algunos diseños opciones

Por otro lado, un programador / científico / lo que sea inteligente debe tener cuidado de todos modos. Pero me encontré escribiendo algunos de mis mejores códigos cuando NO tenía computadora y tenía que tomar notas en papel. Esto puede no aplicarse para grandes proyectos que involucran grandes marcos, cuando un IDE es estrictamente necesario.

Una cosa es segura: las máquinas rápidas y los buenos resultados inmediatos hacen que los programadores (malos) se echen a perder y pueden ser una de las razones de la basura que encontramos en las computadoras.

Lorenzo Stella
fuente
55
Te diré qué: compra una computadora realmente buena y la intercambiaré contigo ... :)
Wonko the Sane
4

Trabajo en un paquete que demora aproximadamente una hora en compilar en mi máquina 8G de 8 núcleos (compilación completamente limpia). También tengo una computadora portátil relativamente baja que pruebo. La computadora portátil de gama baja no administra dos compilaciones completas durante un solo día de trabajo.

¿Soy más productivo en la máquina rápida con algunas pruebas deliberadas realizadas en la computadora portátil, o debo hacer todas mis compilaciones en la computadora portátil?

Tenga en cuenta que estos no son números inventados.

Es una demostración manipulada en la que normalmente no necesito hacer una compilación limpia todos los días (puedo hacer muchas pruebas en módulos individuales), pero incluso las compilaciones parciales muestran aproximadamente una diferencia de orden de magnitud en los tiempos de compilación / enlace .

Entonces, el problema real está en mi máquina más lenta, una construcción típica es lo suficientemente larga como para ir a tomar una taza de café, mientras que en mi máquina más rápida solo puedo tomar un poco de café.

Desde el punto de vista del trabajo, prefiero desarrollar en una máquina rápida. Puedo cumplir los plazos de manera mucho más confiable. Por otro lado, imagino que si la administración me obligara a desarrollar en mi máquina lenta, obtendría mucha más navegación web, o al menos leer libros.

Rayas
fuente
En términos generales, ¿qué hay en tu construcción para que demore tanto? ¿Está vinculado a la CPU o al disco (cuál es el cuello de botella) ¿Sería un problema si algo como TFS hiciera las compilaciones por usted?
goodguys_activate
1
¿Te lleva medio día de trabajo tomar una taza de café? Debes estar trabajando para el gobierno.
finnw
E / S ligada a la máquina lenta. Todavía E / S a veces en la máquina rápida, pero más de un cuello de botella de CPU. Al sistema de compilación actual no le gusta trabajar en más de una biblioteca a la vez, por lo que parte de la CPU y E / S se quedan en el piso cuando quedan menos de 8 archivos para compilar en cualquier subproyecto dado. En cuanto al café, podría beberlo más rápido, pero trato de limitar mi consumo, por lo que si lo bebiera más rápido necesitaría otra actividad de tiempo libre.
Rayas
3

Curiosamente, trabajé en una startup donde terminamos haciendo esto. Creo que en realidad funcionó bastante bien, pero solo debido a la situación específica en la que estábamos. Era una tienda mod_perl donde la recarga automática de clase realmente funcionaba correctamente. Todos los desarrolladores usaron vim como su IDE de elección (o usaron algún software de edición remota). El resultado final fue que se perdió muy poco tiempo (si lo hubo) esperando que el código se compilara / recargara, etc.

Básicamente, me gusta esta idea IFF: hay un impacto insignificante en el ciclo de desarrollo para todos los desarrolladores, y solo afecta la operación en tiempo de ejecución de su código. Si su código está compilado, preprocesado, etc. de todos modos, entonces está agregando tiempo para "reparar el error; probar; siguiente" ciclo en el que los desarrolladores están trabajando.

Desde el punto de vista interpersonal, las personas nunca se vieron obligadas a usar los servidores lentos, pero si usaba los servidores lentos, no tenía que hacer nada de su propio mantenimiento o configuración. Además, esta configuración existió desde el principio, no puedo imaginar tratar de vender esto a un equipo de desarrollo establecido.

Después de releer su pregunta original, se me ocurre que una cosa que me aterroriza perpetuamente son los entornos de desarrollo que difieren de los entornos de producción. ¿Por qué no usar una máquina virtual para la ejecución de código que puede paralizar durante el tiempo de ejecución sin afectar la estación de trabajo de desarrollo? Últimamente, he estado usando / amando VirtualBox.

usuario6041
fuente
3

Voy a romper la tendencia aquí también.

Anécdota: trabajé para una empresa holandesa de desarrollo de software que actualizó 286 computadoras a 486-es (sí, soy tan viejo). En cuestión de semanas, el rendimiento de todas nuestras bibliotecas internas se redujo en un 50% y los errores aumentaron ... Una pequeña investigación mostró que las personas ya no pensaban en el código durante el proceso de depuración, sino que recurrían al código sucesivo 'rápido' -> compilar -> prueba -> corregir (código) etc. ciclos.

Relacionado: cuando comencé una subsidiaria para esa misma compañía en los EE. UU., Terminé contratando programadores rusos porque estaban acostumbrados a PC con menos funciones / menos potencia y eran codificadores mucho más eficientes.

Me doy cuenta de que estos fueron tiempos diferentes, y que los recursos eran mucho más escasos de lo que son hoy, pero nunca deja de sorprenderme cómo, con todo el progreso que se ha hecho en el frente del hardware, el resultado neto parece ser que cada paso adelante es negado por una programación más descuidada que requiere especificaciones mínimas más altas ...

Por lo tanto ... creo que los programadores deberían verse obligados a probar sus aplicaciones en máquinas que no excedan la potencia de cómputo 'Average Joe' y las especificaciones de hardware.

John SMythe
fuente
77
La nota clave aquí es "prueba", el sistema en vivo no tiene que cargar un IDE hinchado, ejecutar el back-end localmente en lugar de hardware dedicado, ejecutar correo, oficina, etc. Necesita una máquina de alta gama solo para que aparezca el desarrollador entorno en la mayoría de los idiomas de hoy.
Bill Leeper el
3

El hardware es menos costoso que el tiempo de desarrollo.

La mayoría de los cuellos de botella se encuentran en la base de datos, no en la PC cliente, pero eso no excusa las pruebas en máquinas más lentas que el desarrollador. Use herramientas de prueba para probar la optimización.

Brian
fuente
3

Absolutamente no. Ofrezca a sus programadores la mejor computadora portátil que el dinero puede comprar, un teclado de su elección, múltiples pantallas grandes, una oficina privada, sin teléfono, refrescos gratuitos, todos los libros que quieran (que sean relevantes), viajes anuales a conferencias tecnológicas clave y Obtendrás excelentes resultados. Luego pruebe en las combinaciones de hardware / software / navegador / ancho de banda de límite superior e inferior.

addictedtoswdev
fuente
2

Este es un pensamiento interesante (darles a los desarrolladores una máquina lenta puede llevarlos a optimizar más).

Sin embargo, la solución se enmarca de una mejor manera: ponga el tiempo de respuesta en los requisitos para los programas y tenga una máquina de gama baja disponible para pruebas.

Además, si tiene un compilador / lenguaje realmente genial, es posible que pueda idear diferentes formas de generar código y elegir el mejor. Eso solo sería ayudado por una computadora más rápida.

Paul Nathan
fuente
2

Otros han respondido que, en general, desea que los desarrolladores tengan máquinas rápidas. Estoy de acuerdo. No omita la RAM (desea tener la mayor cantidad de memoria posible), algunos procesos de compilación requieren mucho uso del disco.

¡Es posible que desee deshacerse de los antivirus en las unidades de compilación! Eso solo se ralentiza y puede ser un factor de desaceleración extremadamente fuerte.

Es posible que desee que los desarrollos se desarrollen en Linux si es posible. Las herramientas son mucho mejores para todo tipo de tareas adicionales (solo grep para algo en un archivo, etc.). Esto también elimina el antivirus.

usuario1249
fuente
No olvide el beneficio de un disco duro rápido: codinghorror.com/blog/2009/10/…
Jim G.
2

Mi Macbook Pro en el trabajo tiene unos años. Entre Linux y Windows (para probar las peculiaridades de IE) vms, así como un par de navegadores web y terminales abiertos, la rueda giratoria OSX aparece mucho. Adivina lo que hago cuando gira, me siento y espero. En este caso, una máquina lenta reduce la productividad.

Thierry Lam
fuente
2

Para muchas aplicaciones, el problema es hacer que los desarrolladores prueben con conjuntos de datos del mundo real antes de que estén "listos". Para aplicaciones interactivas, se requeriría una máquina de prueba de línea de base / VM.

usuario6043
fuente
2

Trabajo en una máquina lenta con Windows95 y me permite escribir de manera eficiente inteligencia artificial MindForth en Forth y JavaScript.

Mentifex
fuente
2

Preguntar a los programadores si los programadores deberían obtener un buen hardware es como preguntarle a un hombre gordo si le gusta la comida. Sé que este es el intercambio subjetivo, pero aún así ... ¿vale la pena hacernos la pregunta? :PAGS

Dicho esto, por supuesto, estoy de acuerdo con la mayoría: NO .

Matthew Read
fuente