A continuación te presentamos la segunda y ultima parte sobre este artículo escrito por Joel Spolsky que hemos traído para ti, aun hay muchos consejos y análisis que hacer así que sigue leyendo. Si aún no has leido los primeros 6 pasos, IR A LA PRIMERA PARTE.
7. ¿Tiene una especificación?
Escribir especificaciones es como usar hilo dental: todo el mundo está de acuerdo en que es algo bueno, pero nadie lo hace.
No estoy seguro de por qué sucede esto, pero es probablemente porque la mayoría de los programadores odian escribir documentos. Como resultado, cuando los equipos que consisten únicamente en programadores y atacan un problema, prefieren expresar su solución en código, en lugar de hacerlo en documentos. Ellos preferirían mucho bucear y escribir código que producir una especificación primero.
En la fase de diseño, cuando descubre problemas, puede corregirlos fácilmente editando unas pocas líneas de texto. Una vez que el código está escrito, el costo de solucionar problemas es dramáticamente mayor, tanto emocionalmente (la gente odia tirar el código) y en términos de tiempo, por lo que hay resistencia a la fijación de los problemas. Software que no fue construido a partir de una especificación por lo general termina mal diseñado y el horario se sale de control. Este parece haber sido el problema en Netscape, donde las primeras cuatro versiones se convirtieron en un lío tal que la administración estúpidamente decidió tirar el código y empezar de nuevo. Y luego hicieron este error de nuevo con Mozilla, la creación de un monstruo que giró fuera de control y tomó varios años para llegar a la etapa alpha.
Mi teoría es que este problema se puede arreglar enseñando a los programadores a ser escritores menos renuentes enviándolos a tomar un curso intensivo de escritura. Otra solución es contratar gerentes de programas inteligentes que produzcan la especificación escrita. En cualquier caso, debe aplicar la regla simple "sin código sin especificaciones".
8. ¿Los programadores tienen condiciones de trabajo tranquilas?
Hay ganancias de productividad ampliamente documentadas al proporcionar a los trabajadores espacio, tranquilidad y privacidad. El clásico libro de gestión de software Peopleware documenta estos beneficios de productividad ampliamente.
Aquí está el problema. Todos sabemos que los trabajadores trabajan mejor al entrar en el "flujo", también conocido como "en la zona", donde están totalmente concentrados en su trabajo y completamente sintonizados fuera de su entorno. Ellos pierden la noción del tiempo y producen grandes cosas a través de la concentración absoluta. Así es cuando obtienen todo su trabajo productivo. Escritores, programadores, científicos, e incluso jugadores de baloncesto le dirá sobre estar en la zona.
El problema es que entrar en "la zona" no es fácil. Cuando intenta medirlo, parece que tarda un promedio de 15 minutos en comenzar a trabajar con la máxima productividad. A veces, si estás cansado o ya has hecho un montón de trabajo creativo ese día, simplemente no puedes entrar en la zona y pasas el resto de tu día de trabajo jugueteando, leyendo la web, jugando Tetris.
El otro problema es que es tan fácil de conseguir estar fuera de la zona. El ruido, las llamadas telefónicas, salir a almorzar, tener que conducir 5 minutos a Starbucks para el café, y las interrupciones de los compañeros de trabajo - especialmente las interrupciones de los compañeros de trabajo - todo esto te empuja fuera de la zona. Si un compañero de trabajo te hace una pregunta, causando una interrupción de 1 minuto, esto te saca de la zona lo peor es que te toma media hora conseguir ser productivo otra vez, su productividad total está en un serio apuro. Si estás en un entorno ruidoso como el tipo que los cafeinomanos dotcoms aman crear, con los chicos de marketing gritando en el teléfono al lado de los programadores, tu productividad se sumerge y es interrumpida una y otra vez y nunca entraras en la zona.
Con los programadores, es especialmente difícil. La productividad depende de ser capaz de hacer malabares con muchos pequeños detalles en la memoria a corto plazo de una vez. Cualquier tipo de interrupción puede hacer que estos detalles se desplomen. Al reanudar el trabajo, no puedes recordar ninguno de los detalles (como los nombres de variables locales que estaba usando o dónde estaba actualizando ese algoritmo de búsqueda) y tienes que seguir buscando estas cosas, Lo que te hace empezar a reaccionar lenta y torpemente hasta que bajas por completo tu aceleración inicial.
Aquí está el álgebra simple. Digamos (como la evidencia parece sugerir) que si interrumpimos a un programador, incluso por un minuto, estamos realmente soplando 15 minutos de productividad. Para este ejemplo, vamos a poner dos programadores, Jeff y Mutt, en cubículos abiertos uno al lado del otro en una granja estándar de engorde de ternera Dilbert. Mutt no puede recordar el nombre de la versión Unicode de la función strcpy. Podría buscarlo, lo que le llevaría 30 segundos, o podría preguntarle a Jeff, que tarda 15 segundos. Puesto que él está sentado al lado de Jeff, le pregunta a Jeff. Jeff se distrae y pierde 15 minutos de productividad (para salvar a Mutt 15 segundos).
Ahora vamos a moverlos a oficinas separadas con paredes y puertas. Ahora, cuando Mutt no puede recordar el nombre de esa función, podría buscarlo, lo que aún le toma 30 segundos, o podría preguntarle a Jeff, que ahora tarda 45 segundos y se pone de pie (no es una tarea fácil dada la condición física promedio de los programadores!). Así que ahora Mutt pierde 30 segundos de productividad, pero ahorramos 15 minutos para Jeff. Ahhh!
( También puedes leer: ¿La programación es un trabajo aburrido? )
9. ¿Utiliza las mejores herramientas que el dinero puede comprar?
Escribir código en un lenguaje compilado es una de las últimas cosas que todavía no se puede hacer al instante en una computadora de casa. Si su proceso de compilación toma más de unos segundos, obtener la última y mejor computadora le ahorrará tiempo. Si la compilación toma incluso 15 segundos, los programadores se aburren mientras se ejecuta el compilador y pasan a leer The Onion, que los chupará y matará horas de productividad.
La depuración del código GUI con un solo sistema de monitor es doloroso si no imposible. Si está escribiendo código GUI, dos monitores harán las cosas mucho más fáciles.
La mayoría de los programadores eventualmente tienen que manipular bitmaps para iconos o barras de herramientas, y la mayoría de los programadores no tienen un buen editor de mapas de bits disponible. Intentar utilizar Microsoft Paint para manipular mapas de bits es una broma, pero eso es lo que la mayoría de los programadores tienen que hacer.
En mi último trabajo, el administrador del sistema siguió enviándome spam automatizado quejándose de que estaba usando más de ...escucha esto... 220 megabytes de espacio en disco duro en el servidor. Me señaló que dado el precio de los discos duros en estos días, el costo de este espacio era significativamente menor que el costo del papel higiénico que usé. Pasar incluso 10 minutos limpiando mi directorio sería un desperdicio fabuloso de productividad.
Los equipos de desarrollo de primera categoría no torturan a sus programadores. Incluso las frustraciones menores causadas por el uso de herramientas de poca potencia se suman, haciendo programadores gruñones e infelices. Y un programador gruñón es un programador improductivo.
Para agregar a todo esto, los programadores son fácilmente sobornados al darles las cosas más frescas, más recientes. Esta es una manera mucho más barata para conseguir que trabajen para usted que realmente pagar salarios competitivos!
10. ¿Tiene probadores?
Si tu equipo no tiene probadores dedicados, por lo menos uno para cada dos o tres programadores, está enviando productos con errores o está perdiendo dinero al tener programadores de $100 / hora que pueden hacer trabajos con probadores de $30 / hora. Escatimar en probadores es una economía tan indignante y falsa que estoy simplemente somprendido de que más personas no lo reconozcan.
11. ¿Los nuevos candidatos escriben código durante su entrevista?
¿Contrataría a un mago sin pedirles que le mostraran algunos trucos de magia? Por supuesto no.
¿Podría contratar un servicio de catering para su boda sin probar su comida? Lo dudo. (A menos que sea tía Marge, y ella te odiaría para siempre si no la dejas hacer su "famosa" torta de hígado picado).
Sin embargo, cada día, los programadores son contratados sobre la base de un currículum impresionante o porque el entrevistador disfrutó charlando con ellos. O se les hacen preguntas de trivia ("¿cuál es la diferencia entre CreateDialog() y DialogBox()?"), Que podría ser respondida mirando la documentación. No te importa si han memorizado miles de trivialidades sobre la programación, te importa si son capaces de producir código. O, peor aún, se les pregunta "AHA!" el tipo de preguntas que parecen fáciles cuando sabes la respuesta, pero si no sabes la respuesta, son imposibles.
Por favor, deja de hacer esto. Haga lo que quiera durante las entrevistas, pero haga que el candidato escriba algún código.
12. ¿Haces pruebas de usabilidad en el pasillo?
Una prueba de usabilidad del pasillo es donde usted agarra a la persona siguiente que pase en el pasillo y lo fuerzas para intentar utilizar el código que acabas de escribir. Si haces esto a cinco personas, aprenderás el 95% de lo que hay que aprender sobre problemas de usabilidad en tu código.
El buen diseño de interfaz de usuario no es tan difícil como se podría pensar, y es crucial si desea que los clientes amen y compren su producto. Puedes leer mi libro en línea libre de diseño de la interfaz de usuario, una cartilla corta para los programadores.
Pero lo más importante acerca de las interfaces de usuario es que si muestra su programa a un puñado de personas (de hecho, cinco o seis es suficiente) rápidamente descubrirá los mayores problemas que la gente está teniendo. Incluso si sus habilidades de diseño de interfaz de usuario son deficientes, siempre y cuando usted se obligue a hacer pruebas de usabilidad de pasillo, que no cuestan nada, su interfaz de usuario será mucho, mucho mejor.
Y bueno con esto concluimos nuestro artículo ¿Te ha servido de algo? ¿Aprendiste algo nuevo? Te gustaría que publicáramos este tipo de artículos más seguido? Nos encantaría leer tus opiniones así que déjalo en los comentarios.
Fuente | Joel On Software
No hay comentarios:
Publicar un comentario