Climens Codelog

El otro día llegué a un interesante post sobre qué preguntarle a nuestro futuro empleador en una entrevista. Después de leerlo me di cuenta de que si en una entrevista llego a preguntar todo eso y encima valoro las respuestas que me dan, no sé sin encontraría trabajo en el inframundo del desarrollo de software (si trabajas en un sitio que cumple, por ejemplo, 8 de los 12 puntos, por favor ¡contrátame!), por lo menos en España.

Lo importante en definitiva es que se basa en The Joel Test: 12 Steps to Better Code (versión en español). Son 12 sencillas preguntas que esconden toda una filosofía de buenas prácticas deseables en cualquier entorno de desarrollo. También googleando he encontrado un excelente artículo sobre estas 12 preguntas aplicadas al desarrollo web. Estas son:

1. ¿Usas control de versiones?
2. ¿Puedes tener listo el producto en un solo paso?
3. ¿Compilas el producto a diario?
4. ¿Tienes una base de datos de errores?
5. ¿Solucionas los errores antes de escribir nuevo código?
6. ¿Tienes una planificación actualizada?
7. ¿Tienes unas especificaciones?
8. ¿Tienen los programadores un entorno de trabajo tranquilo?
9. ¿Tienes las mejores herramientas que puedes comprar?
10. ¿Tienes testers?
11. ¿Escriben código los candidatos durante su entrevista?
12. ¿Haces pruebas de usabilidad de "vestibulo"? (O sea, a cualquiera que pase por allí y esté dispuesto)

Aunque en realidad se podrían hacer muchas más, si se realizan la mayoría de ellas probablemente se esté trabajando de forma decente. Si no, la cosa se puede poner complicada: posiblemente vives diariamente en un infierno incomprensible.

Ahora toca la parte complicada. ¿Qué nota sacamos en mi empleo actual? Vamos a ver

1. Sí, desde hace un tiempo y por supuesto para nuevos desarrollos. Subversion que no es ni el mejor ni el peor pero tiene herramientas chulas como TortoiseSVN y VisualSVN. Además está bastante extendido y se encuentra fácilmente soporte y ayuda.
2. No, de momento. Es algo necesario y está planificado. Supuestamente con MsBuild o Nant lo podemos conseguir.
3. Sí. Para el producto actual usamos TeamCity con cierto éxito, gratuita para pequeños grupos. Eso sí, faltan aun los scripts completos del paso 2.
4. Sí, usamos Redmine y una herramienta interna (bastante inservible, la verdad), aunque no se si el Redmine me acaba de gustar del todo. En fin, mientras tengamos todos los errores registrados bueno es.
5. Más o menos. A veces el tiempo apremia, pero se debería hacer. La compilación del paso 3 comprueba los tests unitarios, lo que no significa que encuentre todos los bugs, obviamente.
6. Sí, lo intentamos, aunque a veces vamos dando palos de ciego sin saber muy bien el rumbo.
7. Eso creo. El flujo de generación de especificaciones es bastante malo, por lo que muchas veces no son lo suficientemente rigurosas ni explícitas.
8. Depende de la oficina. En la que yo estoy es excelente.
9. No. Siempre hay pegas para adquirir herramientas pero estamos mejorando.
10. No oficialmente. Se prueban las cosas bastante mal y sin rigor.
11. No, lo que me atañe y voy a ver qué puedo hacer al respecto. De momento me leere la Guerrilla Guide to Interviewing a ver qué saco de interesante.
12. No. Parece que ahora quieren contratar a unos expertos en usabilidad para guiarnos, aun así dudo que se realicen pruebas de este tipo

Así que mi JoelScore(tm) es de unos 6/12. Aprobado raspadillo y por los puntos 1, 3 y 4, lo cual no es por tirarme flores, pero creo que he contribuido bastante a instaurar estas herramientas y procesos. A ver si el año que viene llegamos a 8 o 9/12, lo que estaría bastante bien.

En resumen, aconsejo a todo el mundo que trabaja en este mundillo que lea las preguntas, que lea lo que significan las preguntas y se autoanalice para ver en qué estado está y qué puede hacer por mejorarlo.

NIH: Del inglés Not Invented Here. Según la Wikipedia, es un término usado para describir una cultura sociológica, corporativa o institucional que evita el uso de productos, conocimientos o estudios existentes debido a sus orígenes diferentes. Normalmente se usa de forma peyorativa.

Últimamente he estado involucrado en la programación de un sistema de gestión de tickets de posventa para la empresa dónde trabajo y quizás es uno de los ejemplos más claros del tiempo que puede llegar a perderse si uno es un fiel seguidor de la cultura NIH.

Este proyecto, que empezó como una paginita sencilla se ha convertido en uno de los pilares del servicio de posventa de la empresa por lo que, al ganar usuarios también ha ganado problemas. Pero el tema fundamental es: con la gran cantidad de software de este tipo, tanto comercial como libre que hay, ¿de qué sirve hacer un desarrollo interno para eso?

La respuesta, claramente, está en la cultura del NIH. Entre todos habremos dedicado quizás 150 horas o más a este desarrollo, que aun dista bastante se ser óptimo, pero por lo menos es usable. Pero si pienso por ejemplo en 150 horas, por 50€ la hora, tirando por lo bajo haciendo la media del precio por hora de desarrollo que se suele facturar de media (algunas horas valen más que otras ;-)), dan un total de 7,500€ que se podían haber dedicado a otros menesteres.

Algunos me pueden decir que he sido simplista. Bien, quitemos por ejemplo el coste de un software comercial, digamos 1,500€ siendo de los más caros, aun quedan 5,000€. Claro, habría costado de configurar, ajustar, personalizar... pongamos unas 50h o incluso 100h y sería el mismo coste.

Al final, habríamos tenido una herramienta impresionante (por ese precio hay gestores de posventa comerciales que hacen maravillas) configurada a nuestro gusto. Y es que está muy bien vivir del software a medida pero: ¡es carísimo! Así que la próxima vez que alguien plantee un desarrollo interno, hacedle ver que el ROI quizás no es demasiado positivo (eso a los jefazos les gusta, que hablemos en términos económicos).

Curiosamente, navegando he visto que no es un asunto exclusivo del software, la prestigiosa revista Nature (me hacía ilusión, en la prensa siempre lo ponen) tiene publicado un artículo sobre el NIH en investigación médica. Incluso hay un bonito libro sobre NIH en la industria aeroespacial. Si al final no somos tan distintos, reinventar la rueda para que sea propia es muy humano, aunque no es lo mismo competir por ser el más innovador que reinventarla por gusto.

Actualización 26/03/08: He encontrado un excelente artículo sobre el tema: Why we use Ant (or :NIH). via El síndrome NIH.

En uno de los blogs que leo habitualmente, Freelance Switch (aunque no soy freelance hay cosas interesantes), encontré un artículo dónde se listan algunos consejos para evitar distracciones en el trabajo que me han parecido dignos de mencionar.

1. Apaga las notificaciones de email. Y también el messenger, Twitter o cualquier medio de comunicación que requiera nuestra atención inmediata. La idea es establecer un momento para revisar estas cosas pero que no nos interrumpan continuamente. Aún así es complicado porque puede que la propia cultura de nuestra empresa nos impida hacer tal cosa (p.e. chat interno...)

2. Apaga Internet. Vale, es el mayor sumidero de tiempo que existe, así que si no te hace falta para la tarea que estás haciendo... desconecta. En mi caso es complicado porque muchas tareas requieren el uso de Internet para realizarlas, pero si que es verdad que hay que controlar las páginas que se visitan o puede distraer bastante.

3. Utilidades. Hay utilidades para limitar el acceso que hacemos a Internet. Por ejemplo Invisibility Cloak o Kiwi Cloak permiten restringir el acceso a ciertas páginas durante cierto horario o Time to Go, que temporiza el acceso a Internet y lo bloquea cuando llevamos demasiado tiempo. A mi personalmente no me gustan demasiado estas medidas coercitivas y no suelo perder el tiempo navegando, pero pueden ser útiles si no te puedes controlar.

4. Auriculares. La música nos puede ayudar a abstraernos el entorno y centrarnos en nuestras tareas. Además permite ignorar lo que no queremos escuchar aunque lo estemos oyendo. Me gusta bastante esta técnica, pero el volumen ha de ser bajo para que por lo menos nos enteremos cuando nos hablan o si no resulta bastante molesto para los compañeros. Yo suelo escuchar last.fm, porque no suelo conocer mucho las canciones pero me permiten ponerme un estilo que me gusta.

5. Signo de No Molestar. Comentan de hacer un signo de 'No Molestar' y ponerlo en nuestro lugar de trabajo cuando nos queremos concentrar. Yo no sé en qué tipo de oficina esto estaría bien visto, pero puedo asegurar que no en dónde yo trabajo.

6. Elimina basura del sitio de trabajo. Todo aquello que no necesites en este momento fuera de la vista y de la mesa. Explican la famosa técnica de Getting Things Done (o su versión en español, Organizate con Eficacia) de David Allen, recoger todos los papeles que hay por ahí, meterlos en la bandeja de entrada y procesarlos uno a uno. Delegar, poner en la lista de tareas o si cuestan menos de 2 minutos, hacerlos inmediatamente. Así establecemos acciones concretas para esos papeles colgados y viviremos mucho mejor.

7. Elimina basura de tu ordenador. Quita todo lo que no necesites del escritorio a una carpeta para revisar luego. Quita las notificaciones que no necesites. Cierra los programas que no hagan falta. En fin, que te concentres en lo que tienes que hacer y no crees más distracciones.

8. Maneja las interrupciones. Muchas veces no podemos evitar que se nos interrumpa en medio de nuestro trabajo y con la posibilidad de romper completamente nuestra concentración y ritmo. En general hay que intentar retardar dicha interrupción hasta el momento en que la podamos atender. Anóta de qué se trata y cuando puedas lo harás. Si vienen a tu mesa, dí que irás cuando puedas y si no hay más remedio, apunta lo que estás haciendo para que luego sea menos traumático.

9. Usa programas mínimos. Al escribir o programar usa programas que no distraigan. Editores de texto simples pero a la vez completos son mejores que monstruos como el Word. Concéntrate en la tarea y luego ya darás formato o mejorarás lo que estás haciendo. Comentan editores como DarkRoom, JDarkRoom o WriteRoom o algunos online como Writer o Google Docs. No es una mala idea, probadlos a ver si os funciona. Yo incluso añadiría Vim o su versión más amigable Cream for Vim.

10. Tiempo para distraerse. Programa tiempo para distracciones. 10 minutos cada hora para revisar el correo o leer los feeds o a lo mejor cada 30 minutos si estamos en una tarea que requiere mucha concentración. Es importante para no agotarnos antes de tiempo.

Via > Freelance Switch