¿Qué opinas sobre la prueba de Joel? [cerrado]

51

La prueba de Joel es una prueba bien conocida para determinar qué tan bueno es tu equipo. ¿Qué opinas de los puntos? ¿Estás en desacuerdo con alguno de ellos? ¿Hay algo que agregarías?

Casebash
fuente

Respuestas:

41

Jeff Atwood tiene la Declaración de Derechos del Programador .

De la publicación:

  1. Cada programador tendrá dos monitores.
  2. Cada programador tendrá una PC rápida
  3. Cada programador tendrá su elección de mouse y teclado
  4. Cada programador tendrá una silla cómoda.
  5. Cada programador tendrá una conexión rápida a internet
  6. Todo programador deberá tener condiciones de trabajo tranquilas.

Esto parece tener algunos elementos que me gustaría ver en la lista de Joel. Específicamente en el área de hardware (monitor dual, PC rápido, mouse / teclado, silla cómoda, conexión rápida).

Lo único que no se menciona es tener un escritorio cómodo y ajustable .

Todo esto podría agregarse cambiando:

Actual # 9: ¿Utiliza las mejores herramientas que el dinero puede comprar?

a

Mejorado # 9: ¿Utiliza las mejores herramientas y equipos que el dinero puede comprar?

esponja
fuente
¿No es su # 6 idéntico al # 8 en la prueba de Joel:
HerbN
Es Jeff Atwood's # 6, y sí, lo es.
Spong
Parece que la prueba de Joel es más específica para ayudar a los programadores a desarrollar software limpio y libre de errores en lugar de las condiciones de trabajo, excepto # 8
Archmede
13

Es interesante que el punto 8 ahora lea:

8. Do programmers have quiet working conditions?

cuando solía leer (algo así como)

8. Do programmers have their own office?

y el último párrafo aún comienza:

Ahora muévalos a oficinas separadas con paredes y puertas.

Siempre sospeché de esta prueba, ya que en todos los lugares en los que he trabajado, tanto como empleado como visitante, las únicas personas con sus propias oficinas son los directores y gerentes superiores.

Escribir software en el mundo real suele ser una actividad de equipo, debe hablar con sus compañeros de equipo para intercambiar ideas, etc. y eso es más difícil de hacer con personas en oficinas separadas, incluso con sistemas de mensajería instantánea. Poder dibujar y mostrar códigos y diagramas de personas ayuda mucho. Esto no quiere decir que los equipos distribuidos no puedan funcionar, obviamente pueden y lo hacen, eso es solo un conjunto diferente de problemas.

Lo que diría es que cada equipo debe estar en su propia oficina de 6-8 personas (suponiendo que ese sea el tamaño del equipo). De esa manera pueden interactuar sin molestar a los otros equipos (si hay alguno) y continuar con su trabajo sin ser molestados por el equipo de ventas o los visitantes (en un lugar donde trabajé, usted entró por la puerta principal directamente al área de desarrollo).

Si está trabajando con otros desarrolladores, pero cada uno está trabajando en proyectos separados, una oficina compartida puede ser útil, pero solo si es estricto acerca de llevar las reuniones a la sala de reuniones y respetar los plazos de otras personas, etc.

La mayoría de los otros son verdades evidentes.

ChrisF
fuente
99
El problema con rebotar ideas de los compañeros de equipo es que PREGUNTARles verbalmente es una gran distracción. Si necesita hacer una colaboración seria, trabaje en un espacio de colaboración. Pero para las preguntas de "oye, cómo harías esto", estás mucho mejor con IM.
Matt Olenik
@Matt: para las pequeñas cosas que tiene razón, pero el espacio de oficina siempre es escaso, ninguna empresa quiere gastar dinero en oficinas vacías, por lo que es útil tener equipos en su propio espacio. Puede convertir la oficina en un "espacio de colaboración".
ChrisF
2
No puedes referirte a ocho personas en la misma habitación, ¿verdad? Ya estoy molesto por compartir una habitación con otros tres programadores (cada uno de los cuales trabaja en sus propias cosas, uno trabajando en un proyecto completamente no relacionado y otro siendo el tipo de backend / base de datos). Sé con certeza que si compartiera la habitación con otros siete tipos, simplemente me iría por correo.
Baelnorn
1
@ ChrisF: tal vez ese es el problema. Los cuatro de nosotros sentados en la misma habitación apenas tenemos algo que ver el uno con el otro, en cuanto a programación. Es más como 4 personas trabajando en 2 proyectos y medio sentados en la misma habitación. Y ahora agregue un jefe al que no le importe mantener conversaciones de media hora con otro programador justo al lado de su escritorio a pesar de que la sala de reuniones está al otro lado del pasillo . >. <
Baelnorn
1
@ChrisF - "Escribir software en el mundo real es una actividad de equipo, necesitas hablar con tus compañeros de equipo para intercambiar ideas, etc. y eso es mucho más difícil con personas en oficinas separadas". - Entonces, ¿cómo trabajan los equipos de desarrollo en diferentes ubicaciones? He trabajado en estrecha colaboración con personas de los EE. UU., Brasil o la India, IM y Adobe Connect, así como en ubicaciones compartidas, desde equipos distribuidos pequeños hasta muy grandes. El tuyo es un ambiente muy disruptivo. El trabajo en equipo se puede hacer de manera eficiente, pero lo que está prescribiendo es todo menos (su idea es correcta desde la cascada de los 70)
luis.espinal
10

Me gusta, pero si lo estuviera usando para evaluar una empresa, no pesaría todos los artículos por igual. No tener control de fuente es un problema mucho mayor que no comprar las mejores herramientas que el dinero puede comprar.

JeffO
fuente
9

El único factor decisivo para mí es:

 8. Do programmers have quiet working conditions?

Interesante es la pregunta más probable que sea fallada por las publicaciones de trabajo de Stack Overflow.

Algunas de las preguntas son difíciles de fracasar, especialmente si hay más de un programador en la empresa:

 1. Do you use source control?
 2. Can you make a build in one step?
 4. Do you have a bug database?

La mayoría de los otros que realmente no me importan. Quiero decir, sinceramente:

12. Do you do hallway usability testing?

Hay uno para detectar mentirosos:

 5. Do you fix bugs before writing new code?
Tom Hawtin - tackline
fuente
20
Creo que se sorprendería de cuántas empresas no pueden hacer una compilación en un solo paso y no tienen una base de datos de errores. Probablemente tenga razón sobre el control de fuente, pero diría que muchas empresas lo usan simplemente para hacer una copia de seguridad de su código y ni siquiera rascan la superficie de los beneficios del control de fuente.
Rob Sobers
1
Cuando comencé en mi trabajo actual, teníamos un sistema de control de fuente, pero las compilaciones se realizaron en la máquina de un tipo y solo él conocía todos los pasos, y los errores fueron rastreados en papel. Todo esto está "arreglado" ahora, pero nunca daría por sentado estas cosas.
HappyCat
6

Tengo que decir que es una buena "línea de base", pero con cualquier herramienta de medición hay otros factores. Por ejemplo, ni una sola compañía para la que he trabajado ha realizado Daily Builds (lo sé, lo sé), pero algunas de ellas han sido muy buenas.

Personalmente, tengo algunos otros elementos que agregaría a una lista.

  1. ¿Apoya la educación del desarrollador asistiendo a conferencias, comprando libros o algo por el estilo?
  2. ¿Tiene un proceso simple y documentado para adoptar nuevas herramientas si es necesario para completar las funciones de trabajo?
  3. ¿Proporcionan a los desarrolladores equipos y un entorno que les permita ser productivos?

Más que nada, estos artículos me han "cabreado" con empleadores anteriores, y ahora son preguntas rápidas que hago sobre todas y cada una de las oportunidades.

Mitchel Sellers
fuente
1
¿No está ya 3 en la lista?
Casebash
Sí, de una forma u otra lo es. Pero enumero el mío un poco diferente, así que lo dejé allí.
Mitchel Sellers el
5

Estoy de acuerdo con la mayoría de los puntos de Joel. No estoy tan seguro acerca de las "pruebas de usabilidad del pasillo". Pruebas de usabilidad, claro, pero en realidad agarrar a alguien del pasillo y hacer que prueben su programa, ¿aunque no sea su trabajo? Esa parece ser una excelente manera de molestar a la gente.

Tim Goodman
fuente
1
Seguramente es una cuestión cultural, si no es excesivamente perjudicial y si es parte de la forma en que funciona el negocio, no debería "molestar a la gente", especialmente si el propósito del negocio es el desarrollo de aplicaciones.
Murph
1
¿Quizás el punto es que debería ser parte del trabajo de otras personas?
JeffO
77
El punto principal de las pruebas de usabilidad en los pasillos es que debe ser alguien que no use el programa regularmente. Una vez que lo haya construido y / o haya pasado horas usándolo (como un probador dedicado) su perspectiva sobre la aplicación será sesgada
GSto
5

La prueba de Joel no prueba qué tan bueno es un equipo. Comprueba qué tan bien se adhiere su equipo a la prueba de Joel.

Aquí hay una mejor prueba de lo bueno que es tu equipo. Lo llamo la prueba GrandmasterB. Tiene una pregunta

1) ¿El software que escribes es bueno?

Es irrelevante para mí si usted 'prueba en el pasillo' o no, o qué control de fuente tiene, o cuál es su proceso de construcción (si hay uno, no todos los idiomas lo tienen). La verdadera medida de un equipo es la calidad del software que crean.

Básicamente, podría seguir cada paso de la prueba de Joel y aún así terminar con código basura y productos que nunca se envían. Por ejemplo, el control de fuente no lo convierte mágicamente en un mejor codificador; hace que el código sea más fácil de administrar. Y tener la última versión de Visual Studio no significa que su aplicación funcionará mejor que si estuviera escrita con Visual Studio 2005 .

Gran maestro B
fuente
14
Te estás perdiendo el punto. La prueba de Joel no se trata de qué tan bueno es el software, sino de cuán efectivo es el proceso de producción. Un equipo que no pasa la prueba de Joel aún puede hacer buenos productos, pero lo más probable es que tome mucho más tiempo y los trabajadores sean miserables. Además, las herramientas no se refieren solo al software. También significa hardware, desde su computadora hasta su escritorio y teclado.
Matt Olenik
Creo que te estás perdiendo el punto. Si un equipo termina los proyectos a tiempo y produce un software de buena calidad, son, por definición, efectivos. Y tienen, por definición, un proceso efectivo.
GrandmasterB
2
Nunca mencionaste el envío a tiempo. Además, me sorprendería enormemente ver un equipo efectivo que falló (completamente) la Prueba de Joel. Cosas como el control de versiones, las pruebas y la usabilidad son críticas. Los otros elementos también pueden ser impedimentos bastante grandes.
Matt Olenik
Este es un buen punto, pero la principal debilidad es su subjetividad. Todos pueden tener una opinión diferente sobre la calidad del software, dependiendo de su experiencia, nivel de habilidad y perspectiva de uso. Pero me gusta el punto.
Bernard Dy
Si su proceso efectivo solo es efectivo para los miembros que están en el equipo, particularmente si el equipo es pequeño, ¿qué tan bien resistirá el crecimiento o en caso de un desastre o retiro prematuro? Ser capaz de producir código que funcione bien y se envíe a tiempo a través de un proceso que solo existe en las cabezas de las personas que lo desarrollan es una receta para el desastre, un equipo que tarde o temprano (probablemente antes) enfrentará un problema del que la mayoría de las personas no puede o simplemente no quiere recuperarse.
Finni McFinger
5

Aunque creo que tiene sentido en el sentido general, la lista me pareció bastante centrada en el tipo específico de software que hace Fog Creek Software ( shrinkwrap ). Eso no es realmente sorprendente, ya que también habla de eso en otra publicación, Five Worlds . Y hay muchos desarrollos fuera de ese mundo.

Hay algunas condiciones que realmente no tienen mucho sentido si desarrolla, por ejemplo, software integrado para un satélite o una máquina expendedora, como las compilaciones diarias (3) o las pruebas de usabilidad (12).

Khelben
fuente
Convenido. Una vez que te alejas de las aplicaciones "top of the stack", muchas ideas contemporáneas parecen volverse un poco ... irrelevantes.
Paul Nathan
Estoy de acuerdo. Hay muchos trabajos de desarrollador en tiendas de TI corporativas ... ciertamente no tan glamurosas como hacer una envoltura retráctil. Como la mayoría de estas compañías no están en el negocio del software, la mayoría de ellas generalmente obtienen un puntaje de 4 en la prueba de Joel.
Bernard Dy
66
¿Por qué no crearía pruebas unitarias para software embebido (y que un sistema de compilación las ejecute automáticamente)?
Peter Mortensen