Cuanto peor equipamiento tenga el desarrollador mejor rendimiento tendrá la aplicación

Cable - La Foto de ayer Según el test de Joel para el desarrollo de software, el desarrollador debe tener las mejores herramientas que se puedan pagar.

La experiencia me dice que en algunos casos esta regla es contraproducente para la calidad del producto resultante.
Mientras se desarrolla, la velocidad de ejecución de los procesos se miden en el tiempo que siente el desarrollador.

  • Si en la máquina del desarrollador va bien, el código esta bien.
  • Si en la máquina del desarrollador va lento, él mismo, se preocupará de hacer que vaya bien.

Muchas de las incidencias que conozco relacionadas con el rendimiento de las aplicaciones son derivadas de que las conexiones y rendimientos de las máquinas donde se programa son superiores a donde se ejecuta en producción.

Lo ideal es que el desarrollador ejecute sus pruebas con la peor máquina donde pueda correr en producción, de esta manera nos aseguraremos que en ejecución siempre funcionará muy rápido.

Esto es aplicable a procesador, tamaño de pantalla, memoria, velocidad de conexión al servidor, etc.

Un caso que conozco en Velneo que demuestra esta teoría, son las optimizaciones del protocolo VATP. Cuando se estaba desarrollando por parte de Juan Muñoz-Cobos y su equipo, se contaba con de una infraestructura de comunicación penosa, una latencia de 1 segundo. El resultado es un protocolo de comunicaciones muy optimizado y preparado para las peores circunstancias.

Cuando el desarrollador trabaja con un muy buen equipamiento suele ser más habitual escuchar “No se porque va lento, en mi equipo va bien” 😉

La nube aporta mejoras en el desarrollo de software

Durante los últimos meses la nube entra por todos lados, cada rincón de la empresa de software es susceptible de viajar a la nube.

Hay muchos ámbitos donde puede aportarnos soluciones mejores y más económicas.

Pruebas

Una de las áreas donde el Cloud esta ayudando es el área de pruebas, ya que permite arrancar una máquina limpia de manera rápida, ejecutar las pruebas y eliminarla.
Todo el trabajo de instalación de sistemas operativos desaparece. El coste de una hora de una máquina incluyendo licencias de sistema operativo  suele ser inferior al euro. Hacer eso en local lleva mucho más tiempo y dinero.

Esclavos en la nube

Si usas integración continua con Jenkins, es muy cómodo tener los esclavos en la nube. Estas máquinas son las encargadas de realizar la compilaciones, verificaciones,  pruebas funcionales, etc. En nuestro caso usamos múltiples esclavos para los diferentes sistemas operativos y sus diferentes sabores.

El ahorro más importante viene en que podemos arrancar las máquinas esclavas a demanda, ahorrándonos el coste de tenerlas siempre encendidas. También es muy sencillo cambiar los recursos de las maquinas en función de las necesidades.

Más madera

Otro de los puntos fuertes son las pruebas de carga, estos proveedores te permiten contratar monstruos de la computación. Se pueden montar pruebas de carga con varios equipos de 64 núcleos con cientos de Gigas de RAM. Es posible probar el rendimiento en grandes infraestructuras por unos pocos euros.

Seguridad

En cuanto a la seguridad de las máquinas, es eficaz mantener una política dura en la configuración del firewall del proveedor de Cloud, con lo que no tendremos problema en la configuración o reconfiguración individual de cada máquina virtual.

Como alternativas tenemos experiencia en Amazon Ec2 y Arsys Cloud builder, pero existen decenas de proveedores que pueden ofrecer un buen API para la gestión de las máquinas.

En casa de herrero, comida de perro

Hasta unas semanas internamente solíamos decir “en casa de herrero, cuchillo de palo“, cuando nos referiamos al hecho de que seguíamos usando algunas aplicaciones internas desarrolladas con Velneo 6.x.

Estas aplicaciones con más de 10 años de vida y con una exitosa trayectoria necesitaban una renovación para beneficiarse de las últimas tecnologías.

Gracias al impulso de mi compañero Domi, durante estas últimas semanas se ha dado un importante paso a la sustitución por aplicaciones desarrolladas con Velneo V7.

Llevábamos años usando aplicaciones desarrolladas con Velneo V7 en combinación con algunas antiguas con éxito, pero ya llegaba la hora de que comiéramos nuestra propia comida de perro de una forma general.

Nuestra filosofia es una combinación de Open Apps con adaptaciones con herencia.

Algunas de las Open Apps que estamos usando son :

El cambio no solo sirve para renovar las aplicaciones, sino que nos estamos mudando a la nube con todas las aplicaciones del grupo. Usamos un servidor en el Cloud de Velneo con lo que nos hemos liquidado todos los gastos de servidor, licencias, copias de seguridad, sais, AC, etc.

Normalmente tenemos una media de 75 enganches a 15 instancias distintas. Y hemos conseguido la felicidad de los maqueros y los linuxeros de la empresa que trabajan con las aplicaciones corporativas directamente desde su sistema operativo preferido.

Nuestro objetivo con este cambio no puede ser otro que “Evolucionar en tecnologías para innovar en software” 😉

Control de cambios para Velneo 6.x con Perforce

Perforce como herramienta de control de cambiosCuando se trabaja en equipo es muy cómodo tener un lugar centralizado donde almacenar y gestionar las distintas modificaciones en tus desarrollos.

Los SCM o herramientas de control de cambios permiten centralizar y gestionar los cambios de un proyecto software.

Existen muchas herramientas para gestionar el control de cambios ( Git, Subversión, etc ). Nosotros llevamos usando Perforce durante años.

Ventajas que más nos gustan de Perforce:

  • Solución muy visual (P4V) que permite iniciarse rápidamente en la gestión de cambios
  • Multiplataforma
  • Servidor muy robusto
  • Fácilmente integrable con Jenkins
  • Configuración Cliente/Servidor por TCP
  • Muy útil para gestión de cambios en mapas de velneo 6.x, documentos, imágenes o cualquier tipo de archivo

Actualmente para pequeños equipos de desarrollo existe una versión gratuita para 20 usuarios / 20 workspaces, lo que permite disfrutar de la herramienta con todas sus funcionalidades.

Es importante crear una correcta estructura de tu repositorio (Branches (ramas) y Trunk (tronco) ) que te permitan controlar todas las versiones y parches para ayudar a tener un buen ciclo de desarrollo

Video de explicación de Perforce

Ventajas del doble monitor

Trabajar con dos pantallas / monitores aporta muchas mejoras en el trabajoEn la empresa buscamos las mejoras herramientas para favorecer la máxima productividad y uno de los elementos que mayor impacto ha tenido ha sido la implantación del doble monitor.

Durante los últimos años se han ido implantando en diferentes departamentos y cada tipo de perfil le ha sacado beneficios en los distintos trabajos que realiza.

Por otro lado, las personas necesitan un proceso de adaptación al pasar de uno a dos monitores, al igual que si usaramos un solo brazo durante toda la vida, el día que nos implantan otro brazo, resulta difícil adaptarnos a la nueva situación y tardaríamos un tiempo en sacar todo el potencial.

Muchas de las tareas que se realizan a lo largo de la jornada pueden mejorarse con doble monitor:

  • Programar y depurar aplicaciones.
  • Escribir artículos mientras te documentas.
  • Realizas pruebas mientras introduces la incidencia.
  • Das soporte al cliente desde una pantalla mientras documentas la consulta.
  • Desarrollas tus tareas mientras chateas con tus compañeros para resolver dudas.

El coste actual de los monitores es reducido, además, la clave es que sean dos, no necesitan ser de gran formato o gran calidad.

Solemos poner pantallas de distinto tamaño, estéticamente no queda súper-cool, pero ayuda al desarrollador a probar el interfaz con distintos tamaños cómodamente.

Hay muchos estudios oficiales que indican que los dos monitores mejoran la productividad, en nuestro caso la experiencia nos ha confirmado que ha sido una buena decisión.

Enlaces:
http://research.microsoft.com/apps/mobile/News.aspx?post=/en-us/news/features/vibe.aspx
http://research.microsoft.com/apps/mobile/Publication.aspx?id=69718
http://www.codinghorror.com/blog/2008/03/does-more-than-one-monitor-improve-productivity.html

El coste de un bug

bicho-bugCuando se desarrolla software se comenten errores (bugs), esto forma parte del trabajo. Cada uno de estos errores tiene un coste, normalmente cuando más tarde se detecta, más caro nos cuesta solucionarlo.

Estos son algunos de los momentos en los que la empresa puede detectar y solucionar estos errores :

  1. En el propio desarrollador
    Un buen desarrollador con años de experiencia comete menos errores, el código que realiza se protege de los bugs. Estos programadores cobran más, pero su código es más fiable.
  2. En la integración continua
    Dentro de la integración continua se pueden usar diferentes sistemas para detectar bugs ( Pruebas unitarias, pruebas funcionales, análisis estáticos de código, etc )
    Dentro de la integración continua es muy útil tener automatizadas todas estas pruebas automáticas que detectan fallos de desarrollo y nos da garantías de que los cambios subidos no rompen nada.
    Coste*: 1 hora del desarrollador ver el log y arreglar el problema 
  3. En el equipo de desarrollo
    Ya sea por revisión por pares o por programación por parejas, se pueden detectar los bugs antes de que el código salga del departamento de desarrollo.
    Coste*: 2 h. del desarrollador que encuentra el problema y de quien lo soluciona 
  4. En el departamento de pruebas
    Si el error llega hasta el departamento de pruebas, este equipo tiene que ocuparse de detectarlo y entender como ocurre y como hacerlo reproducible. Otro elemento importante es describirlo al desarrollador que suele ser un punto de conflicto,  la comunicación debe ser muy eficaz para que el desarrollador pueda entenderlo y solucionarlo.
    Coste*:  1h. para encontrarlo y documentarlo + 1 h. en entenderlo + 1 h. para solucionarlo 
  5. Los betatesters
    Si el bug no se ha encontrado dentro de los equipos de desarrollo y pruebas, el producto con el error llega al betatester que si lo encuentra, deberá comunicarlo al departamento de pruebas, la solución a este bug debe pasar por varios departamentos e incurre en trabajo de mucha gente.
    Por otro lado, la solución al error, puede romper otro elemento, con lo que esa versión debe pasar de nuevo todas las fases previas.
    Coste*: 1h. del betatester + 1 h. para encontrarlo y documentarlo + 1 hora en entenderlo + 1 hora en solucionarlo 
  6. El usuario final
    Si el bug llega al usuario se sentirá frustrado porque la nueva versión no hace lo que debe. Del mismo modo quizá no informe correctamente al equipo. Si lo hace, debemos tener un canal por el equipo de soporte para ello. Este tipo de bugs generan mucho trabajo y mala imagen, incluso en ocasiones pueden generar un parche, con el enorme coste que esto provoca.
    Coste*: 1 h. del cliente final + 1 h. persona de soporte + 1 hora persona de pruebas + 1 h. para entenderlo + 1 h. solucionarlo 

Sacar un parche para muchos clientes no tiene precio 😉

*Coste: Es un tiempo medio, cada error es un mundo, unos se solucionan en minutos y otros en días.

Revisión por pares

Como bien comenta jgarzas, en su post Beneficios del pair programming, que dos desarrolladores compartan el editor y hagan el desarrollo de forma conjunta puede aportar un plus de calidad a nuestro proyecto.

Del mismo modo, la puesta en marcha es complicada, por la sensación de pérdida de productividad.

Hace tiempo pusimos en práctica la revisión por pares, consiste en definir unos pares de desarrolladores donde cada uno verá el trabajo realizado por su compañero el día anterior.

Un script nocturno en la herramienta de integración continua captura del control de cambios el resumen de las modificaciones realizadas el día anterior por su compañero. Con la información se compone un email y se envía a cada par correspondiente.

El desarrollador lo primero que hace en el día es ver y entender lo que ha realizado su compañero, ante cualquier duda respecto al código, al formato o los comentarios, el desarrollador le consulta a su par e inician un diálogo para aclarar dudas.

Con la revisión por pares conseguimos una serie de beneficios:

  • Aprendizaje de trucos y el buen hacer de los compañeros
  • Amplio conocimiento de todo el proyecto
  • Solución a problemas de estilo de código
  • Solución a problemas de código detectado por un compañero
  • Unificación de criterios en la forma de desarrollar

No es tan eficaz como la programación por pares, pero ayuda al trabajo en equipo.

Es llevar a la práctica la ley de Linus en un equipo de desarrollo de una forma que no invertimos mucho tiempo en la revisión.