Micromanagement

Hoy he caído por casualidad en una tira sobre micromanagement en Geek Hero Comic:

Está claro que esta tira no es Sinergia Sin Control, pero me ha hecho pararme a pensar si tengo un problema: me he visto reflejado con el tipo del peinado de el de Simply Red (o el Actor Secundario Bob, o Bisbal, o mi amigo Valle ^_^).
Tengo que admitir que soy muy maniático con muchos detalles que considero importantes, y, más que importantes, malos síntomas. Hoy mismo, en una presentación sobre metodología de desarrollo que he hecho para los compañeros, me he declarado un entrometido maniático, y les he pedido disculpas por anticipado al respecto.
Concretamente, soy MUY maniático con estos detalles (entre otros), que si seguís el blog ya habréis visto comentados:

  • Programar usando el ratón en vez de dominar (progresivamente) los atajos de teclado.
  • No aprovechar las vistas de Eclipse, en sus diferentes variantes: ordenar el código mediante algún criterio en vez de utilizar la vista 'outline'; no utilizar //TODOs y //FIXME para que aparezcan en Tasks; no explotar las posibilidades de la depuración...
  • ¡Cortapegar!
  • Nomenclatura de variables.
  • ...
Buscando al respecto del micromanagement he encontrado diversas opiniones y descripciones. En general se puede definir como gestionar intentando controlar todos los detalles, hasta el más pequeño, sin capacidad de delegación o de confianza.
Tengo que admitir que me siento bastante representado en unos cuantos puntos (la Wikipedia lo asocia a desórdenes obsesivos compulsivos, no sé si diría que tanto, pero casi), así que debo reconocer mi errores al respecto (alguno ciertamente grave). En mi defensa, diré que mi intención siempre fue intentar ayudar, pero está claro que no siempre fue de forma correcta.
Prometo esforzarme en mejorar :).
Una vez hecho este ejercicio de autocrítica...

¿Dónde está la barrera que separa el micromanagement del management y del mentoring? Parece claro que los tres son prácticas relacionadas. Diría incluso que el micromanagement es la perversión de la unión de los otros dos, es llevarlos al extremo. Pero ¿dónde comienza uno y empieza el otro? Creo que es algo subjetivo, que depende de los implicados. Lo que a una persona le puede parecer una ayuda, una sugerencia, a otro le puede parecer un entrometimiento. Seguramente llegar al punto de la confrontación es un síntoma, pero hay otros, como la falta de percepción de confianza, que no son tan fáciles de ver.

Sin embargo, ¿no son herramientas como Checkstyle una forma de micromanagement? ¿No lo es el Daily Scrum? Yo los veo como herramientas para mejorar la calidad del producto y uno mismo, pero esa es mi percepción...

¿Qué opináis? ¿Microgestionais? ¿Lo habéis sufrido alguna vez? ¿Creéis que con ciertas personas o en ciertos momentos puede ser necesario adoptar posturas así? ¿Cómo lo evitaríais?

Supongo que, como siempre, in medio stat virtus.

P.D.: a los compañeros que leáis esto, no dudéis en atarme en corto en este aspecto ;)

Posted by Juan Ignacio Sánchez Lara 19:29 Enlaces a esta entrada  



Trazabilidad

Podríamos explicar la trazabilidad (bidireccional) en el contexto del desarrollo de software como "dado un requisito llegar a la línea de código que lo implementa, y al contrario, dada una línea, saber con qué requisitos corresponde"(a grandes rasgos, no cortapegéis esto para nada importante ;) ).
Esto tiene muchos matices y complicaciones, tanto teóricas como prácticas. ¿Realmente es importante? ¿Necesitamos bidireccionalidad? La trazabilidad es claramente una función no biyectiva: una misma línea probablemente corresponde con varios requisitos, y un requisito corresponde con muchos fragmentos de código dispersos.
Hasta hace poco siempre había visto esto como algo imposible de conseguir -a un coste razonable-. Los requisitos se registraban en un procesador de textos, las tareas en un diagrama de Gantt, y el código en un repositorio, todo desconectado. Los intentos que ví para solucionar esto eran añadir funcionalidad a estas herramientas para lograr lo que se necesitaba. Por ejemplo, hay (caros) plugins para Word que añaden "orientación a requisitos", permitiendo, por ejemplo, versionarlos. En las tareas del Project habría que meter los códigos de los requisitos. En los commits de código, los códigos de las tareas... Trabajo, trabajo, trabajo. Al final, se abandonaba.
El problema era de planteamiento. Es inutil forzar el uso de herramientas para un fin ajeno a los objetivos del implicado: al programador no le da ningún beneficio el esfuerzo extra de añadir el código de la tarea. Al analista, el uso de herramientas más complejas que el word le supone también más trabajo. El gestor del proyecto probablemente no tiene ni tiempo ni ganas de actualizar o comprobar el diagrama de gantt...
La solución ha venido de forma conjunta a la adopción de técnicas ágiles y el cambio de herramientas integradas. Las tareas se añaden en el gestor de incidencias (Trac en nuestro caso). Esto, de paso, soluciona el problema del versionado. Además, al ser información estructurada, al estar en una base de datos, se pueden generar informes y vistas en función de las necesidades. Al programador se le da el Eclipse con Mylyn, que le da valor añadido. Indicar la tarea en la que está trabajando no sólo no es trabajo (hacer un click en ella), sino que le aporta valor añadido, ya que el entorno recuerda el contexto (la perspectiva, las vistas, los ficheros abiertos...), haciéndole más fácil alternar entre tareas. Al final, en el gestor tenemos los requisitos (con su histórico) y podemos ver el código relacionado.

¿Moraleja? Si tienes que forzar a tu equipo a algo, la culpa no es del que no te hace caso, sino tuya. Las herramientas adecuadas para las tareas adecuadas.

Posted by Juan Ignacio Sánchez Lara 20:11 Enlaces a esta entrada  



Calidad de Código

Practiques Integración Contínua o no, creo que tus scripts de compilación deberían ejecutar también unas cuantas herramientas de calidad de código. En mi opinión este tipo de herramientas es útil tanto para controlar (y mejorar) la calidad del código en sí como para formar al equipo en una mentalidad de mejora contínua.
Yo acabo de integrar las siguientes (y la lista probablemente siga aumentando):

A esto hay que añadir que Hudson integra también el seguimiento de las tareas abiertas (TODOSs, FIXMEs, etc) que también es fundamental.

¿Qué otras herramientas utilizáis?

Posted by Juan Ignacio Sánchez Lara 11:55 Enlaces a esta entrada  



Informática Corporativa

En muchas organizaciones, y muy notablemente en la Administración, se viene creando un departamento (o movimiento, o tendencia, o normativa...) de "Informática Corporativa". Procede de que la organización crece horizontalmente y la informática, que es transversal (ya que afecta y se desarrolla en todos los departamentos), se vuelve heterogénea en la organización. Esta heterogeneidad es vista como algo negativo, ya que en apariencia aumenta los costes:

  • El personal es menos flexible, ya que un especialista en la tecnología de un departamento puede no serlo para otro.
  • Los recursos hardware son menos versátiles, ya que las aplicaciones desarrolladas en un departamento no son desplegables en otro.
Para dar forma a esta informática corporativa se establecen unos procedimientos (casi siempre a medida, síndrome NIH) que dan lugar a una arquitectura común para los desarrollos.
Esto, visto desde el punto de vista funcional, desde la organización se pretende interpretar como algo fantástico: durante uno o dos (o más) años estudiamos las tecnologías disponibles, para seleccionar la más mejor, especializarnos en ella, y utilizarla para todo.
En la práctica, lo que sucede es que las organizaciones tardan dos años en seleccionar una tecnología que ya está obsoleta para cuando se implanta por primera vez, y se pelea contra ella durante años. Los errores cometidos durante el estudio (todos nos equivocamos) en vez de solventarse se parchean, para mantenerse de forma supuestamente ortodoxa en la normativa. El personal de toda la organización se especializa (en el mejor de los casos) en herramientas que carecen de interés en muy poco tiempo, y se estancan en ellas. Por tanto, todo intento de cambio se percibe como una amenaza, una intromisión en su trabajo. Además, como la arquitectura se convierte en normativa, se prohíbe la instalación en la red interna de todo aquello que se salga de ella.
La informática cambia con mucha frecuencia. Y, aunque no cambiase, no hay balas de plata. Intentar hacer norma de una tecnología es una locura: no hay nada que sirva para todo (ni en metodologías ni en herramientas) y lo menos malo para todo lo es hoy pero no mañana.

No me gusta señalar problemas sin proponer alternativas. ¿Solución? Normaliza el cambio:
  • Establece una política de formación que permita que la gente no sólo se recicle periódicamente, sino que también evolucione constantemente.
  • Haz una revisión tras cada proyecto para analizar los puntos positivos y negativos.
  • Haz un estudio de viabilidad real, en el que de verdad se estudien alternativas de implementación.
El cambio es bueno. ¡Esto no significa que cada mes tengas que hacer las cosas de forma diferente! Si tienes gente formada, y haces un estudio de viabilidad real, el cambio surgirá de forma progresiva y natural: se irán incorporando cosas nuevas, se sustituirán componentes mejorables... Incluso los "cambios radicales" (piensa en un primer proyecto con Python en vez de J2EE) parecerán normales, ya que, en el fondo, los conceptos son los mismos.

PD: mañana tengo que trabajar en mostrar que un cambio es positivo, ¡deseadme suerte! ;)

Posted by Juan Ignacio Sánchez Lara 21:56 Enlaces a esta entrada  



X enlaces de esta semana

Unas cuantas cosas que me han llamado la atención esta semana:

La LOPD y el Cloud Computing

Interesante artículo sobre las implicaciones legales de externalizar los datos.

100 Interview Questions for Software Developers

Preguntas que debes hacer (o para las que te debes preparar) en una entrevista de trabajo.

Getting ready for the cloud

Desplegar una aplicación Java existente en Amazon EC2.

Posted by Juan Ignacio Sánchez Lara 11:49 Enlaces a esta entrada  



Buenas prácticas: Tratamiento de Excepciones

Entrada rápida que resume algo que ya he escrito en otros sitios, y que me gustaría tener público (¡y recibir comentarios!).

Criterios a tener en cuenta al tratar excepciones en Java:

  • Es mejor que la aplicación falle a no saber que ha fallado (y qué ha fallado). Corolario: si no vas a tratar una excepción correctamente, mejor no hagas nada y que la aplicación falle.
  • Siempre que se produzca un error en la aplicación tiene que haber información sobre el error en pantalla, al menos indicando que se ha producido un error. Corolario: no te limites a trazar el error en el log, ¡no siempre habrá alguien mirando!
  • No traces mediante System.out o System.err, utiliza un sistema de logging.
  • Si sólo vas a relanzar la excepción, no la relances, haz que el método lance ese tipo de excepción.
  • No loguees y relances constantemente, no es necesario. Los únicos puntos que no deben lanzar excepciones son los métodos invocados directamente por la aplicación, para que no le llegue al navegador la traza del error. Y si utilizas un framework que gestione bien las excepciones (como Seam), incluso puedes saltarte esta norma.
  • Cuando escribas en el log, escribe información significativa, como los parámetros recibidos por el método. Lo trivial (el nombre del método, por ejemplo) ya se verá en la traza.
  • Al trazar, no concatenes el mensaje de la excepción, vuelca la excepción en sí (toda la traza).
  • Un método no debería declararse como throws Exception, ya que enmascara todas las excepciones, sin permitir gestionar el error concreto. No pasa nada, por ejemplo, por que lance varias: throws IOException, MiOtraException. De esta forma, el que la invoque sabrá a qué tipos de error se debe enfrentar.
Contraejemplos (ejemplos de cómo no se deben hacer las cosas):
  • } catch(Exception e) { }; : se ocultan los errores, es imposible saber qué ocurre.
  • } catch(Exception e) { System.err.println(e) }; : estamos trazando en err, ni se ve nada en pantalla ni en el log, así que en explotación no sabremos qué ocurre.
  • } catch(Exception e) { log.debug("Ha ocurrido algo malo: "+e); }; : el nivel de log es incorrecto (debería ser error), no se dan datos sobre el error, estamos concatenando la excepción, no estamos relanzando...
  • } catch(Exception e) { log.error(e) }; : no se dan datos sobre el error, y no estamos lanzando nada, así que en pantalla no se verán los errores.
Ejemplos válidos en otras circunstancias:
  • } catch(Exception e) { log.error("Identificador: "+id, e); throw new MiExcepcion(e) }; : trazamos el error (la excepción) e indicamos un parámetro que puede estar provocando el error. Además, lanzamos una excepción (que contiene la provocada, para no perder traza) para que el nivel superior pueda seguir tratando el error. Esto sería incorrecto, de todas formas, si en nuestro sistema esto vuelca la traza en el interfaz de usuario. Aparte, probablemente incluso sea innecesario hacer esto (ver último ejemplo correcto).
  • } catch(Exception e) { log.error("Identificador: "+id, e); anhadirMensajeDeErrorAlUsuario(e) }; : trazamos el error (la excepción) e indicamos un parámetro que puede estar provocando el error. Además, mostramos un mensaje de error en pantalla. Esto sería incorrecto, de todas formas, si este método es invocado por un nivel que necesita procesar el error específicamente.
  • ...) throws IOException : si el método no va a hacer nada interesante con la excepción, ¿para qué capturarla?
Actualización 0901131738: este es un tema del que se pueden encontrar infinidad de fuentes, como en java.net, con más detalle, en inglés.

Posted by Juan Ignacio Sánchez Lara 16:04 Enlaces a esta entrada  



Dos enlaces de esta semana

Uno de morralla comercial y otro de programación:

SOA ha muerto. Larga vida a los servicios

¿Qué significa "SOA ha muerto"? ¡Nada! Lo único que consiguen grupos como Burton con declaraciones como estas es cambiar las conversaciones de enteradillos que los directivos que no saben de qué están hablando mantienen entre reuniones. Igual, siendo malpensado, consiguen también redirigir inversiones: ya han conseguido vender su consultoría acerca de SOA, ahora tienen que conseguir vender otra, y ya sabemos que este es el año del Cloud Computing...

Lead developer, Are Yoy Mentoring?

Un buen artículo sobre cómo reintegrar a un programador negativo. En vez de quejarse, tener iniciativa, preguntarle, utilizar herramientas de análisis estático...

Posted by Juan Ignacio Sánchez Lara 9:40 Enlaces a esta entrada  



Introducción a Seam

Como apoyo para una próxima sesión de formación he preparado una modesta presentación/resumen de lo que es Seam, muy por encima. Las principales fuentes son el manual de referencia y "Seam in Action", así que si quieres conocerlo en profundidad, nada como las fuentes originales, mucho más detalladas y sin mis gazapos (ni tonterías de mi cosecha ni relación con trabajo previo mío).

Posted by Juan Ignacio Sánchez Lara 22:19 Enlaces a esta entrada  



Reseña: Peopleware

Peopleware es otro de esos clásicos que todos los informáticos deberíamos leer. Es un libro atípico, porque habla de la Ingeniería del Software en términos de personas, sentimientos, emociones...

A continuación, la tabla de contenidos con el argumento de cada capítulo.

Contenido del libro
Parte I: La gestión del recurso humano
El software lo desarrollan personas, no máquinas, adecuemonos a eso.
Capítulo 1: En algún lugar, en este momento, un proyecto va a fracasar
Los proyectos software fracasan, principalmente, por cuestiones sociológicas, no técnicas.
Capítulo 2: Haz una hamburguesa de queso, vende una hamburguesa de queso
El desarrollo de software es inherentemente diferente de la producción (industrial). Es un error aplicar técnicas de producción (pensar en las personas como máquinas) al desarrollo.
Capítulo 3: Vienna waits for you
(Dejo el nombre del capítulo en inglés por ser un extracto de una canción de Billy Joel, 'Stranger'.)
Más horas de trabajo no implica ni más ni mejor trabajo, para las personas el trabajo no es lo más importante. La adicción al trabajo es un problema.

Capítulo 4: Calidad - si el tiempo lo permite
Comprometer la calidad no es una buena estrategia: mina la auto
estima
de la gente.
De hecho, a la larga una mayor calidad redunda también en una mayor productividad.
Capítulo 5: Revisión a la Ley de Párkinson
No es cierto que el trabajo de desarrollo se expanda hasta abarcar todo el tiempo disponible para él.
Capítulo 6: Laetril
No existen los remedios mágicos ni las soluciones que multiplican la productividad.

Parte II: El entorno de la oficina
Factores externos a las personas que afectan a la productividad.
Capítulo 7: La política de mobiliario
Las políticas de mobiliario no parecen estar pensadas en pro de las personas (y, por tanto, tampoco de su productividad).
Capítulo 8: "Es imposible hacer nada aquí de 9 a 5"
Factores como el ruido o el espacio están más correlacionados con la productividad que la experiencia o el lenguaje de programación.

El capítulo 8 expone datos muy interesantes sobre un estudio que los autores han realizado durante años. Dan un ejercicio a dos candidatos de cientos de empresas, y relacionan los resultados con factores ambientales.

Capítulo 9: Ahorrar dinero con el espacio
La cantidad y calidad del espacio para el trabajador es fundamental.
Interludio
: Medición de la productividad y OVNIs
Medir la productividad es difícil, pero puedes medir algo que al menos te permita saber tu posición respecto a la competencia.
Capítulo 10: Tiempo mental contra tiempo de cuerpo presente
Para que el tiempo se aproveche al máximo el cerebro debe entrar en un estado llamado "de flujo", al que cuesta llegar pero del que es muy fácil salir por culpa de interrupciones. Para maximizar la productividad hay que maximizar la proporción de "tiempo de flujo" respecto al "tiempo de cuerpo presente".
Capítulo 11: El teléfono
Un mundo sin teléfono sería algo fantástico, pero como no parece posible, hay que conseguir minimizar el impacto de las llamadas: silenciar el timbre (o al menos bajar el volumen), utilizar sistemas alternativos, etc.
Capítulo 12: El retorno de la puerta
El entorno de oficina tradicional, de dos, tres o cuatro personas, con paredes y puertas, se ha perdido, equivocadamente, en favor de entornos diáfanos, con mucho ruido y sin privacidad.

En este capítulo se expone un interesante estudio sobre la música y el trabajo. Si bien la parte lógica/matemática del trabajo no se ve afectada, la parte creativa se ve anulada si estas escuchando música.

Capítulo 13: Realizando pasos de paraguas
Nota: para los curiosos, podéis consultar el significado de 'paso de paraguas' ('umbrella step'), que no tiene traducción directa.
En este capítulo se exponen varios conceptos de arquitectura y decoración de interiores para hacer un mejor entorno de trabajo: situación de las ventanas, de los muros, de los espacios compartidos... El resumen más correcto, aunque impreciso, sería decir que "hay que construir como se lleva haciendo desde hace miles de años".


Parte III: La gente correcta
Cómo (y por qué) conseguir a los mejores, mantenerlos, y aprovecharlos al máximo.
Capítulo 14: El factor Hornblower
Nota: 'Hornblower' aquí se refiere a Horatio Hornblower, protagonista de una serie de novelas de C.S.Forrester sobre las guerras napoleónicas.
La gente es diferente, y eso es bueno. No hay que potenciar la similitud y la entropía, sino todo lo contrario. A menor entropía (entendida como igualdad), más trabajo hecho.
Capítulo 15: Contratar un malabarista
En las entrevistas de trabajo no basta con preguntar a los candidatos, hay que ver sus habilidades en la práctica.
Capítulo 16: Feliz de estar aquí
El coste de la rotación es muy elevado (más de 5 meses de trabajo), hay que conseguir mantener a la gente que la gente quiera quedarse.
Capítulo 17: Sistema autoreparable
Cuando se automatiza un sistema humano, por ejemplo al aplicar una Metodología, se pierde gran parte del valor humano. Concretamente, cuando el valor de una Metodología es hacer algo uniforme, mejor sería conseguirlo mediante formación, herramientas, y revisión por parejas.

Parte IV: Crecer equipos productivos
Nota: he traducido 'growing' como 'crecer', aunque no suene demasiado bien, para mantener la metáfora agrícola.
Ya tienes la gente, ahora tienes que hacerla trabajar en equipo.

Capítulo 18: El todo es más que la suma de las partes
Tienes que conseguir hacer que el equipo esté totalmente cohesionado en pos de un fin común.
Capítulo 19: El Black Team
El Black Team es el paradigma de equipo cohesionado. Fue un equipo de testers de IBM, temido por los desarrolladores por su eficacia, aún cuando todo el equipo inicial había cambiado.
Capítulo 20: "Equipocidio"
No es fácil determinar qué debes hacer para conseguir un gran equipo, pero sí hay varias cosas que no debes hacer: gestión defensiva, burocracia, separación física, fragmentar el tiempo de la gente, reducir la calidad del producto, establecer hitos imposibles y control de camarilla.
Capítulo 21: Cena de espagueti
El mejor jefe es aquel que consigue gestionar sin que parezca que hace nada.
Capítulo 22: Open Kimono
La mejor gestión es aquella en la que se confía plenamente en los miembros del equipo y en la que la autoridad se ejerce de forma natural, no mediante imposiciones.
Capítulo 23: Química para la formación de equipos
Para que una organización siga una estrategia correcta de formación de equipos, debe cuidar lo siguiente: culto a la calidad; proporcionar realimentación positiva; sentimiento de élite; alentar la heterogeneidad; preservar los equipos exitosos; proporcionar dirección estratégica, no táctica.

Parte V: Debería ser divertido trabajar aquí
El trabajo no debería ser algo aburrido, una carga, algo negativo... Debería ser divertido, interesante, enriquecedor...
Capítulo 24: Caos y orden
La tendencia natural en el trabajo es ir hacia el orden, pero introducir deliberadamente elementos novedosos, aumentando el caos, disminuyendo así la entropía, es positivo.
Capítulo 25: Electrones libres
Hay gente que no encaja en puestos específicos, pero que aportan gran valor a la empresa. No siempre es necesario regirse por estrictas jerarquías.
Capítulo 26: Holgar Dansk
Introducir los cambios parte de la iniciativa individual. Si algo es sensato, hazlo, que será más fácil de lo esperado, encontrarás ayuda.

Valoración personal
Peopleware es un libro excepcional. No se limita a obviedades, y no se limita a exponer problemas. Entra en muchos temas en profundidad, incluso aportando datos concretos, y aporta soluciones (por ejemplo, enumerando alternativas al uso de Metodologías). Es un libro imprescindible, que nunca envejecerá, y útil no sólo para jefes. Provocador y agitador a todos los niveles. Hay muchísimas cosas aplicables constantemente. Yo ya me estoy haciendo una lista...

Posted by Juan Ignacio Sánchez Lara 17:40 Enlaces a esta entrada  



WTF como ejercicios en entrevistas y en formación

A estas alturas del año ya habréis visto el código responsable del cuelgue masivo de los Zune:

    while (days > 365) {
if (IsLeapYear(year)) {
if (days > 366) {
days -= 366;

year += 1;
}
} else {
days -= 365;
year += 1;
}
}
Este código no creo que entre en la categoría de WTFs, a todo el mundo se le puede patinar un igual. Sin embargo, me viene de perlas para uno de los trabajos que voy a tener en los próximos días: preparar ejercicios de programación para formación y contratación (¿por qué será que recruiting me parece más preciso?). En un post anterior en el que hablaba de mi opinión sobre la aptitud y actitud profesional, Julio César Pérez comentaba lo siguiente
La pregunta estrella era implementar una funcion recursiva que calculara el factorial de un numero entero en cualquier lenguaje. Sólo el 10% la hicieron bien y todos los candidatos eran como mínimo ingenieros.
Ya me habían mirado raro a veces por opinar que las entrevistas hay que orientarlas en ese sentido, pero desde que supe que Google pide programar en una pizarra me he sentido reafirmado: las entrevistas deben ser prácticas.


Contexto
Trabajo en un entorno parcialmente universitario, por lo que una de nuestras razones de ser es la ocupación de estudiantes, con las ventajas e inconvenientes que esto conlleva.

Requisitos
Necesito una forma de...
  • poder evaluar en una entrevista de trabajo los conocimientos (si hablamos de gente con experiencia) o la aptitud (si hablamos de becas) de una persona.
  • facilitar la autoformación del personal, nuevo o no, que se va a incorporar a proyectos con nuevas tecnologías.
Alternativas de implementación
  • Para las entrevistas, recopilar una serie de WTFs y trozos de código, tanto correctos como no, y preguntar al entrevistado por ellos.
  • Para la formación, plantear ejercicios cortos con tareas de no más de una o dos horas, en el que se busque escribir código lo más impecablemente posible. Una vez completado el ejercicio, alguien revisaría el código escrito para pulir entre los dos todo lo mejorable.
Esto último de la revisión, aunque algo exigente (ocupa a dos personas en código de prueba) me parece fundamental. En mi opinión, pensar que una persona aprende a programar símplemente programando es falso. Conozco gente que programa mal y lo seguirá haciendo toda su vida, porque ni lee código de otros, ni libros, y nadie le corrige sus errores. Especialmente en entornos de formación, la figura del revisor me parece fundamental.
  • Calidad de código en el motor de integración contínua como formación: tanto instalar plugins de Eclipse como generar informes de calidad de código pueden ser positivos para aprender. Si se presta atención a los warnings de FindBugs, PMD o Metrics se puede aprender mucho (¡a la vez que mejoras la calidad!).
PD: aquí, al hablar de "código WTF" me refiero a código con una elevada medida de "WTF" como en la siguiente viñeta:

Posted by Juan Ignacio Sánchez Lara 8:28 Enlaces a esta entrada