Gerald Marvin Weinberg. La simplicidad y la comprensión del problema

Cuando se entiende un problema es mucho más sencillo encontrar una solución simple, en caso contrario se tenderá a soluciones más complejas y/o a una mayor carga de tareas de proceso (en cualquiera de los casos se requiere mucho más esfuerzo).

Soluciones más complejas porque al no entender completamente el problema tenderemos a atacarlo por donde sabemos, descartando posibilidades más simples.

Soluciones con una mayor carga de proceso porque se espera que con ello se adquiera el conocimiento que falta y para dar una sensación de que el proyecto sigue progresando aunque eso no implique un avance real o proporcional en la comprensión del problema.

Ya sea por el incremento de la complejidad o por el aumento de la carga de proceso, nos estamos alejando del ideal de la solución más simple y cuanto más lejos estemos de él más probabilidades existen de que el proyecto no satisfaga las expectativas del usuario y se aleje del presupuesto y plazos iniciales.

Hay una reflexión de Jerry Weinberg sobre los gestores y las consecuencias de que no entiendan el problema que es perfectamente aplicable a lo que he comentado, ya que es extrapolable a cualquier perfil dentro del proyecto: «Cuando los gestores no entienden el trabajo tienden a compensarlo con la apariencia de trabajo (más horas, más papel,…)».

Robert Sutton. El conocimiento está ahí fuera

Podemos reflexionar sobre nuestros conocimientos y a partir de ahí generar más conocimiento pero siempre tendremos un límite y tendremos que recurrir a fuentes externas (otras personas o libros) para seguir progresando.

Y es que el conocimiento está ahí fuera y prácticamente me atrevería a decir que está en cualquier sitio. Las barreras las ponemos nosotros mismos cuando creemos que no es así y pensamos que pocas personas o pocas fuentes (en general) pueden aportarnos algo.

Gran error pensar así porque estamos perdiendo la oportunidad de confrontar nuestras ideas con el conocimiento y experiencia de terceras personas solo porque tienen un punto de vista diferente o porque entendemos que no tienen el nivel suficiente como para que digan algo interesante.

He aprendido mucho de personas con más conocimiento y experiencias que yo pero no más que con personas con menos conocimientos y experiencia.

Los puntos de vista diferentes desgastan cuando se comparten áreas de trabajo pero también nos permiten crecer porque es bueno que lo que creemos consolidado sea puesto en tela de juicio ya que nos da la oportunidad de conocer otros puntos de vista y corregir, matizar o mejorar los nuestros. En un contexto donde todo el mundo piensa igual se pierde diversidad y el grupo se hace más débil.

Robert I. Sutton es profesor de ciencia de la gestión y comportamiento organizativo en la Universidad de Stanford y autor de publicaciones sobre la materia.

Me parece muy interesante su siguiente cita sobre este tema: «Decir cosas inteligentes y dar respuestas inteligentes es importante. Aprender a escuchar a otros y hacer preguntas inteligentes es más importante».

Importante reducción del uso de Internet Explorer y Windows sigue dominando

Este es el octavo artículo que publico con la evolución en el uso de navegadores y sistemas operativos utilizando como referencia sitios web españoles dirigidos a un público general que tienen un importante número de visitas como para que los resultados obtenidos con las métricas de Google Analytics sean lo suficientemente representativos.

En artículos anteriores mostraba los datos de dos sitios web, en este caso solo voy a mostrar los datos de uno de ellos (el que en los artículos anteriores lo nombraba como sitio web 2) ya que no he conseguido acceso a estadísticas fiables del otro.

Sigo publicando estas estadísticas porque creo que es interesante ver la evolución que va teniendo el uso de los distintos navegadores y sistemas operativos.

El primer artículo fue publicado el 12 de enero de 2009 y contiene los datos entre el 30/06/2008 y el 31/12/2008. El segundo artículo fue publicado el 22 de julio de 2009 y contiene los datos entre el 01/01/2009 y el 30/06/2009. El tercer artículo fue publicado el 26 de enero de 2010 y contiene los datos entre el 30/06/2009 y el 31/12/2009. El cuarto artículo fue publicado el 31 de julio de 2010 y contiene los datos entre el 01/01/2010 y el 30/06/2010. El quinto artículo fue publicado el 11 de enero de 2011 y contiene los datos entre el 30/06/2010 y el 31/12/2010. El sexto artículo fue publicado el 11 de julio de 2011 y contiene los datos entre el 01/01/2011 y el 30/06/2011. El séptimo artículo fue publicado el 5 de enero de 2012 y contiene los datos entre el 30/06/2011 y el 31/12/2011.

En este artículo, se muestran los resultados recogidos entre el 01/01/2012 y el 30/06/2012 y se comparan con los resultados informados en los siete artículos anteriores (aparecen entre paréntesis, en orden cronológico de más reciente a menos reciente).

Como conclusiones más significativas, señalar las siguientes:

1) La trayectoria descendente en el uso de Internet Explorer sigue siendo más o menos lineal si bien en este último semestre ha caído a casi ocho puntos (algo por encima de entre los seis y los siete puntos que solía caer al semestre).

En el artículo anterior en el que analizaba estas estadísticas comentaba que de seguir así era posible que en dos o tres años Microsoft perdiera la hegemonía en los navegadores.

Con estos nuevos datos si Internet Explorer y Chrome siguen con su tendencia en el plazo de un año (o tal vez menos) nos encontremos con que la hegemonía de Microsoft en los navegadores es historia.

Como podemos ver en las estadísticas de Navegador + Sistema Operativo son los mismos usuarios de Windows los que están estableciendo esa tendencia.

2) La pérdida de cuota de Internet Explorer la recogen principalmente Chrome (5’5 puntos) y Safari (1’5 puntos). Firefox sigue con su suave trayectoria descendente.

3) En cuanto a los sistemas operativos, Windows sigue siendo el dominador si bien este semestre ha caído aproximadamente lo que solía caer en un año completo. En cualquier caso su cuota sigue siendo aplastante. Resulta interesante la cuota que alcanzan los sistemas operativos de Apple, la suma de las mismas es del 8’55% del total situándose como la segunda opción.

Sitio web

Navegadores.

– Internet Explorer: 37’73% (45’56%) (52’21%) (58%) (62’19%) (69’06%) (72′08%) (74′71%)
– Chrome: 25’52% (19’92%) (14’37%) (10’07%) (6’15%) (3’43%) (1′69%) (0′71%)
– Firefox: 24’51% (25’52%) (27’22%) (27’3%) (27’69%) (24’27%) (23′7%) (22′47%)
– Safari: 7’31% (5’92%) (4’93%) (3’66%) (2’85%) (2’22%) (1′73%) (1′45%)
– Android Browser: 3’54% (1’72%)
– Opera: 0’58% (0’52%) (0’59%) (0’51%) (0’69%) (0’67%) (0′54%) (0′43%)

Sistema Operativo.

– Windows: 84’74% (88’25%) (90’98%) (92’97%) (93’57%) (94’93%) (95′58%) (96′3%)
– Macintosh: 4’54% (4’41%) (4’20%) (3’46%) (3’34%) (2’91%) (2′46%) (2′19%)
– Android: 3’67% (1’80%) (0’50%) (0’18%) (0’05%)
– Linux: 2’35% (2’06%) (2’29%) (2’12%) (2’50%) (1’68%) (1′66%) (1′34%)
– iPhone: 1’45% (1’56%) (0’86%) (0’59%) (0’28%)
– iPad: 1’93% (1’16%) (0’48%) (0’24%)
– iOS: 0’63%
– BlackBerry OS: 0’24% (0’14%) (0’09%) (0’06%)
– Symbian OS: 0’22% (0’32%) (0’21%) (0’17%) (0’11%)

Combinación Navegador + Sistema Operativo.

– Internet Explorer + Windows: 37’68% (45’56%) (52’20%) (58%) (62’19%) (69’06%) (72′07%) (74′7%)
– Chrome + Windows: 24’63% (19’18%) (13’82%) (9’68%) (5’93%) (3’4%) (1′69%)
– Firefox + Windows: 21’54% (22’66%) (23’89%) (24’41%) (24’39%) (21’62%) (21′12%) (20′24%)
– Android Browser + Android: (3’54%) 1’72%
– Safari + Macintosh: 3% (2’82%) (2’75%) (2’18%) (2’05%) (1’73%) (1′43%) (1′22%)
– Firefox + Linux: 1’96% (1’77%) (2’16%) (1’79%) (2’14%) (1’47%) (1′55%) (1′23%)
– Safari + iPhone: 1’32% (1’43%) (0’79%) (0’53%)
– Safari + iPad: 1’81% (1’12%) (0’46%)
– Safari + iOS: 0’58%
– Firefox + Macintosh: 0’98% (1’08%) (1’15%) (1’09%)
– Chrome + Macintosh: 0’54% (0’49%) (0’29%)
– Opera + Windows: 0’49% (0’45%) (0’54%) (0’47%)
– Safari + Windows: 0’25% (0’26%) (0’41%) (0’35%)
– Chrome + Linux: 0’33% (0’25%) (0’27%) (0’22%)

Mark Beeson. Equipo de proyecto. Compromiso

Es lo que necesito en la gente que trabaja conmigo. Una persona comprometida incluso con menos conocimientos y experiencia que otros generalmente permite obtener mejores resultados a nivel individual y colectivo (siendo más importante lo segundo que lo primero teniendo en cuenta que los proyectos son el resultado del trabajo de muchas personas).

Cuando te falta compromiso te falta el cariño necesario en las tareas que realizas y te vuelves descuidado. Cuanto te falta compromiso piensas en ti y no en esos compañeros que sí están poniendo interés para que el trabajo salga adelante, los cuales merecen un respeto que no estás ofreciendo.

En el momento en que alguien pierde el compromiso hay que cortarlo de raíz (ver artículo: teoría de las ventanas rotas).

Soy consciente de que el compromiso se construye día a día y que el primero que tiene que comprometerse y ser un ejemplo es quien más responsabilidad tiene en el proyecto. No puedes pedir compromiso si no lo tienes y eso es un problema muy grande de muchos gestores que solo se preocupan de dar instrucciones sin ejercer un liderazgo real.

Con respecto al compromiso me gusta el punto de vista que le da Mark Beeson, donde lo asocia al hambre por conseguir retos (no todo el mundo tiene la misma predisposición al compromiso, tiene una visión del trabajo más allá de ejecutar las tareas que tienes encomendadas o le afecta igual un trabajo bien o mal hecho): «Cuando estoy formando un equipo, busco a gente que le encante ganar. Si no los encuentro busco a gente que odie perder. Quiero gente a mi alrededor que tenga pasión».

Bob C. Martin. Hacer un buen código no es una pérdida de tiempo

Es importante programar al mayor nivel posible que nuestro conocimiento y experiencia nos permita. Esa debe ser la base a partir de ahí solo queda seguir aprendiendo y seguir adquiriendo experiencia para a partir de ese punto desarrollar software de mejor factura técnica.

Ahora bien, ni el conocimiento ni la experiencia son las que pulsan las teclas, somos nosotros y si no sumamos actitud a nuestra aptitud, el software que se desarrolla estará por debajo de nuestras posibilidades y por tanto estamos añadiendo deuda técnica extra que podía ser perfectamente evitable.

Es cierto que a veces no es tanto cuestión de aptitud sino el contexto en que el que trabajas donde lo mismo la presión y las prisas provocan que se priorice la ejecución de las tareas a cómo realmente se están ejecutando. Estas circunstancias condicionan el trabajo y provocan una bajada en nuestro listón potencial de calidad, pese a eso hay que intentar ajustar el software a ese nuevo listón y considerar todo lo que esté por debajo de él deuda técnica extra que añadimos al producto.

Después si la metodología de desarrollo, nuestra visión sobre lo que debe ser el producto software y las prioridades del proyecto lo permite habrá un tiempo para refactorizar pero como siempre digo esa actividad se debe realizar siempre sobre un software sobre el que se haya puesto el mayor empeño posible en hacerlo bien.

Al final toda la deuda técnica añadida al software son intereses sobre el desarrollo (y el mantenimiento) que tenemos que pagar, por lo que si hoy sale barato (desarrollar software sin tener en cuenta su mantenibilidad) que por cierto está por ver si realmente sale barato, mañana será caro, muy caro.

Me gusta mucho la siguiente cita de Bob Martin al respecto (traducción libre): «Hacer código de calidad no lleva tiempo. No hacer código de calidad sí que lleva tiempo».

Desarrollo de software. Contra la indefinición, feedback, pero no gratis

El usuario, el grupo de usuarios o el Product Owner pueden tener en mente a grandes rasgos qué es lo que quieren pero lo normal es que les cueste tomar decisiones sobre el detalle e incluso no tengan clara la definición de una determinada funcionalidad.

También hay que tener en cuenta que hay usuarios más decididos que otros (lo cual no es ni bueno ni malo en sí, sino una actitud) que necesitan más tiempo para tomar las decisiones o bien necesitan pasar de lo abstracto a lo concreto para tener más claro el problema.

Al final, en uno u otros casos, es el feedback el que finalmente termina ajustando el producto a las expectativas del usuario.

Ahora bien, el feedback no es gratis ya que si se ha desarrollado una funcionalidad o un boceto de la misma, realizar modificaciones sobre la misma tiene un coste. Por eso digo siempre que las iteraciones deben realizarse con intención y que cuanta menos intención tenga y más peso tenga el prueba y error, más iteraciones se necesitarán y más coste tendrá el desarrollo.

No obstante hay que tener en cuenta un aspecto importante, hablo de coste pero es interesante verlo más como una inversión que como un gasto, porque siempre será mejor darle varias vueltas a una funcionalidad importante para dejarla conforme a las expectativas del usuario que obtener un resultado final que no sirva o no sea útil (nos hemos gastado menos dinero pero al final resulta más caro).

Si al usuario le cuesta detallar lo que quiere tendremos que apoyarnos en lo concreto y aplicar todas las técnicas que sean adecuadas para incrementar la intención de la iteración, como por ejemplo un prototipado rápido, teniendo en cuenta que será el resultado de la iteración el que le permitirá obtener un feedback de mayor valor. En estas circunstancias es fundamental que el usuario sea absolutamente consciente (y el responsable final del área usuaria) que cada evolución tiene un coste y para ello además de haberlo hablado (y escrito) antes de empezar a trabajar, es necesario que sepan cuanto les cuesta cada iteración y el saldo restante en el proyecto.

Bob C. Martin. Un mal diseño

Para Bob C. Martin un software que presenta algunos de los siguientes defectos tiene un mal diseño:

1) Rigidez: Es complicado realizar cambios porque cada cambio afecta a otras partes del sistema.
2) Fragilidad: Cuando realizas un cambio, partes insospechadas del sistema empiezan a fallar.
3) Inmovilidad: Es difícil reutilizar código en otra aplicación porque no puede ser separado de la aplicación en la que se está usando.

Es importante incidir en que Martin se está centrando en aspectos de diseño y de arquitectura y no en aspectos de programación (pese a que al final estos problemas se hagan evidentes en el proceso de desarrollo y en las actividades de mantenimiento o evolución del sistema), por ese motivo los defectos que plantea están relacionados con factores como la modularidad, el alto acoplamiento, la baja cohesión y la alta complejidad ciclomática (entre otros).

Un buen diseño se valora cuando has trabajado con sistemas que no lo tienen, en los cuales realizar cualquier tarea de mantenimiento se encuentra con una resistencia que hace que los costes se disparen, sin que por ello se garantice que el producto va a pasar a producción con menos errores que los que tenía antes.

¿Debe ser la única misión del testing encontrar bugs?

La respuesta a esta pregunta dependerá de si eres programador o tester y de la experiencia que hayas tenido en modelos de trabajo en los que intervienen ambos tipos de perfiles.

Como he leído en más de una ocasión: el objetivo del testing no es encontrar incidencias sino de proporcionar información sobre la calidad del producto (algo que cubre un dominio mucho más amplio de actuaciones).

Alcanzar ese objetivo no es fácil porque requiere un cierto background previo:

– Que los programadores consideren a los testers y los testers a los programadores como parte de un mismo equipo que busca un mismo fin: el desarrollo de un software de calidad que satisfaga las expectativas de los usuarios. Esto requiere tirar muros para conseguir una mayor cercanía (no necesariamente física, aunque si lo es, mejor).

– Un mismo fin no se ve de igual manera si existen diferentes niveles de implicación: Todos somos, dentro de nuestro rol, importantes para alcanzar los objetivos del proyecto y por tanto nuestro nivel de implicación para conseguirlo debe ser el mismo.

– Que los objetivos de calidad del software estén consensuados entre todas las partes y sean acordes a la naturaleza del producto y al contexto del proyecto. Además se debe dar la posibilidad a que sean modulados en función de los cambios que a buen seguro se producirán a lo largo del proceso de desarrollo.

– Que los mecanismos y métricas para medir el grado de cumplimiento de los objetivos sean conocidas y objetivas.

– Que los procesos no obstaculicen un modelo de trabajo que requiere flexibilidad y comunicación continua (sin comunicación este modelo no funciona).

Heinz von Foerster. Opciones y flexibilidad

Hace poco me encontré con la siguiente cita de Heinz von Foerster : «Actúa siempre para incrementar el número de opciones».

Lo contrario a incrementar el número de opciones es incrementar el número de restricciones y por tanto acotar nuestra capacidad de ser flexibles y en consecuencia limitar nuestro margen de actuación a la hora de adaptarnos al cambio.

Me parece una reflexión muy interesante tanto para un enfoque ágil en los proyectos de desarrollo de software como prácticamente en cualquier ámbito de la vida.

Cuando tomamos decisiones (algo que hacemos casi constantemente) estamos actuando a favor o en contra del número de opciones que tendremos con posterioridad a la misma. En determinados momentos tendremos que tomar decisiones más restrictivas ya que no siempre es posible tener abierto todo el rango de posibilidades. Sin embargo, pese a esto, resulta interesante que las restricciones no vayan más allá de lo que realmente se necesita, con el objeto de no eliminar innecesariamente opciones o posibilidades que después nos pudieran resultar de utilidad.

Brian Marick. Trabajar solo, trabajar sin red

Me parece muy interesante la siguiente cita de Brian Marick: «Trabajar solo es trabajar sin red». La cita la realizó reflexionando sobre el «pair testing» si bien es aplicable, en mi opinión, a todos los campos del desarrollo de software.

Respeto a quienes quieren trabajar solos, es su decisión y tiene sus ventajas y sus inconvenientes. Todo empieza y termina en ti y detrás tuya no hay nada ni nadie, es como dice Brian Marick, un salto sin red.

Sin embargo en el contexto de un equipo de proyecto hay que pensar en términos de equipo y no en términos individuales. Tienes tus tareas pero no eres ajeno a la dinámica de un equipo, formas parte de un engranaje y la maquinaria no funciona si cada componente lo hace a su aire.

La reflexión de Marick es extrapolable a los resultados de una determinada versión del producto, si lo revisa otro equipo o se revisa de nuevo el trabajo estaremos dando una oportunidad a detectar deficiencias y a reducir la incertidumbre sobe el resultado final.