ÑaaS (Ñapa as a Service)

ñapa-as-a-serviceHoy os traigo una delicatesen que un buen amigo me ha proporcionado. Como ilustra la figura adjunta, la ñapa es una de las lacras de esta profesión del desarrollo de software, y por desgracia, hay quien la ofrecen como servicio de forma habitual.

Quiero pensar que el autor de la imagen, al escribir “Programming the spanish way”, no hablaba en serio. Me niego a pensar que la forma habitual de programar en España sea la Ñapa.

Para los lectores de otros países, o que me lean mediante el traductor automático, vamos a ofrecer una traducción del término “Ñapa”. No os molestéis en buscar en la RAE (Real Academia Española de la lengua). El término Ñapa no aparece allí. Sin embargo, es harto conocido al menos en España

ÑAPA: chapuza, mierda, parche, remiendo. En informática, dícese del trabajo mal remunerado y peor ejecutado, que consiste en construir un simulacro de aquello que espera ver el cliente, con el mínimo esfuerzo, y totalmente alejado de lo que una mente sana entendería como adecuado.

Eso es una ñapa. Este término está muy relacionado con otros que ya he blogueado (y algunos que aún no he terminado de escribir) como: cantamañanas, o vendemotos, o vendedor de humos (smokeseller para los amigos). Es gracias a esta fauna de la selva informática, a quienes debemos agradecer la existencia de las ñapas.

También hay que agradecerlos a los clientes, que también los hay, que son capaces de cambiar de opinión cada poco tiempo para disfrute de los programadores. Esos programadores que se encuentran que después de docenas o cientos de horas construyendo aplicaciones, éstas dejan de tener sentido debido a “un pequeño cambio”.

Y me rio, me parto de la risa ácida que me entra de forma visceral e insostenible, cuando me salta el iluso de turno con su “esto se arregla siendo ágil”. Amigo, esto no lo arregla SCRUM, ni CMMI ni nadie. Cuando el cliente decide que lo más importante no es identificar el impacto de un cambio, ni priorizarlo. Solamente llevarlo a cabo. Aunque haya que tirar a la basura semanas y semanas de duro trabajo para rehacer desde cero miles de líneas de código.

La ñapa o chapuza, es una enfermedad del software (podéis leer más enfermedades del software que he ido recopilando en esta categoría, como la comentitis, singletonitis, excusitis, cacheitis, patronitis… ). Y esta enfermedad es difícil de erradicar. Desde mi experiencia, lo más importante no es la metodología, no es ser más o menos ágil. Sino ser consecuentes y tener la mente fría. Identificar el impacto de las cosas, y asumir que los cambios existen, y que la forma más rápida de llevarlos a cabo es precisamente…no ponerse a ellos de forma inmediata. Sino ponerlos en cartera y ver cómo se relaciona con otros cambios solicitados, los desarrollos en curso, etc, etc.

Gracias José Antonio Herrero por la imagen.

Anuncios

Libros gratis y de calidad para este verano

6758_Prog_WinStor_Apps_HTMLOtro año más, Eric Ligman ha publicado en su blog una entrada con más de 150 libros para que podamos ponernos al día en las últimas tecnologías (Windows 10, Azure, SharePoint, HTML, CSS, JavaScript, CRM, Office 2013, Lync, Windows Server….

No solo son totalmente gratis (sin pedir el email, ni ningún tipo de información, sólo descarga desde la propia página), sino que además, se encuentran en los principales formatos de ebook: pdf, mobi, epub, etc.

¿Quién dijo que formarse es caro?

Buena lectura, y feliz verano.

El fin de los mensajes de error

error-messageLeía en linkedin un artículo de opinión (Error Messages are Evil), y mi sorpresa ha sido mayúscula al encontrar que se había formado todo un terremoto de respuestas, una pequeña polémica. Y mi sorpresa ha sido aún mayor al encontrar a gente joven entre los que responden en contra de la opinión del autor. En el artículo, el autor (Don Norman), defendía que los mensajes de error son el mal, y mostraba como ejemplo un mensaje de error ofrecido por una aplicación.

Yo esperaba que los usuarios más jóvenes apoyaran por fin estos conceptos de usabilidad, pero parece que al menos entre los lectores del artículo, no era así.

Y sí, estoy de acuerdo, los mensajes de error son malignos. Realmente, hay que erradicarlos. Ya lo comentaba hace tiempo Alan Cooper, uno de los maestros del UX en “The inmates are running the asylum”. Los mensajes de error tradicionales violan las reglas de la usabilidad:

  • Hacen sentir estúpido al usuario, al culparle por no saber usar el software.
  • Distraen del objetivo del usuario, que no es usar el software, sino obtener resultados.

¿Por qué decimos al usuario lo que hay que hacer DESPUÉS de que lo haga? ¿Porqué asumimos que es un error algo como un texto mal introducido? ¿Porqué no nos centramos en guiar al usuario a cumplir sus tareas en lugar de obsesionarnos en que use “correctamente” nuestro software?

Pues porque al desarrollar software, caemos en la trampa del egoísmo. Sólo pensamos en nosotros mismos, de forma que cuando el usuario no hace lo que nosotros queremos/esperamos…es SU culpa! Malditos usuarios…

Bueno, no puedo irme sin recomendaros no sólo el artículo de opinión en sí, sino esa gran obra  pionera en el mundo del UX (User Experience) que es “The inmates are running the asylum”.

Metodología XP – Introducción

extreme programmingHoy me apetece hablar de la metodología XP (eXtreme Programming). Personalmente, me gusta porque es de las primeras metodologías ágiles con la que tuve contacto, allá por el año 1999. Al igual que en otras metodologías ágiles, es una metodología adaptativa y centrada en las personas. XP agrega buenas prácticas que abarcan más allá de la gestión de proyectos definiendo aspectos más técnicos y cercanos al desarrollo software. El autor o precursor de esta metodología fue Kent Beck, y está basada en 5 valores fundamentales:

  • Respeto: todos los miembros del equipo muestran respeto por el trabajo de cada uno de los demás.
  • Simplicidad: la he puesto en segundo lugar, porque aunque en teoría leeréis que lo simple y la búsqueda de lo simple es la base de XP, me niego a verlo por detrás del respeto.
  • Comunicación: cada una de las tareas del equipo se consideran una forma de comunicación, desde el código, pruebas unitarias, etc.
  • Feedback: XP fue una de las primeras metodologías en incorporar el feedback del cliente. De hecho, el cliente se considera parte del equipo de trabajo.
  • Valor: se refiere principalmente al valor o valentía necesarios para realizar algunas de las prácticas ágiles que XP incorpora. Como el comenzar a programar lo antes posible, o valentía para que el código sea refactorizado y no haya deuda técnica desde el principio, etc.

Como metodología, XP es muy ligera, o más bien podríamos decir, poco estructurada (“ligera” podría considerarse como un término despectivo en el mundo del desarrollo del software). Lo que sí hace XP es incorporar una serie de técnicas o buenas prácticas. Algunas prácticas fundamentales de XP:

  • Programación por parejas: es el punto más controvertido, ya que propone que sean dos personas las que se dediquen a programar. Una persona escribiendo y otra revisando (se pueden alternar). De todas formas, el código se discute antes y durante la escritura. Aquí se practica el famoso “cuatro ojos ven mejor que dos”.
  • Desarrollo por iteraciones: el código se construye mediante iteraciones que van sumando valor o funcionalidad al resultado final.
  • Simplicidad: el axioma “KISS” (Keep It Simple, Stupid), se aplica con regularidad.
  • Refactorización: el código se refactoriza regularmente para que la calidad de código sea notoria, y se evite la deuda técnica. Recordemos que refactorizar, tal y como hemos indicado ya en este blog, nos puede llevar a la refactoritis, una enfermedad de la que ya hemos hablado anteriormente en este mismo blog.

Windows 10 y la gestión de pruebas beta

Hola a todos,
Supongo que muchos ya conoceréis el concepto de Alfa y Beta en el mundo del software. Pero es importante destacar, y en ello ISTQB lo diferencia claramente:

  • Pruebas Beta es un software que se da a probar al cliente en su casa. Vamos, que se lo lleva a su casa, o su oficina, y lo prueba.
  • Pruebas Alfa es un software por el contrario, que se prueba en un entorno controlado por el equipo fabricante, en las instalaciones del fabricante.

Y digo esto porque es muy típico confundir con el concepto de pruebas Alfa y Beta con la versión Beta y la versión Alfa (o pre-Beta) de un software.

Me acabo de acordar porque precisamente estos días, me he instalado Windows 10 en versión Beta, a través del Microsoft Insider Program.

Desde el punto de vista de la gestión de proyectos software, es muy interesante este concepto, ya que permitiría, bien llevado, a llevar el agilismo a extremos insospechados. Un cliente puede usar una aplicación (o en este caso, el sistema operativo), y a través del análisis de su uso del software, se podrían detectar funcionalidades mejorables, funcionalidades más usadas, etc. Por supuesto, en el caso de Windows 10, tenemos el caso del feedback tipo “esta aplicación no me ha funcionado”, o “esta página web no se ha visto bien”.

No digo que Microsoft esté haciendo Windows 10 añadiendo funcionalidades ad-hoc a nuestros gustos. Simplemente, que estamos cada vez más, ante una forma de trabajar adaptativa (ágil), permitiendo a posibles usuarios/clientes el ver prototipos tempranos, más o menos terminados.

Otro caso, también de Microsoft, es Windows 10 para móviles. Todos los usuarios de algunos modelos seleccionados, pueden instalarse una versión bastante avanzada (pero aún no terminada), para obtener feedback del uso, pulir defectos, detectar incompatibilidades, etc.

Por supuesto que todo esto ya existe, y tenemos aplicaciones web (recordemos que GMail ha sido una gran parte de su historia una versión Beta: más exactamente algo más de 5 años entre 2004 y 2009) que se ofrecen a los usuarios de manera muy temprana. Sin embargo, la aproximación que ha tomado este fabricante me parece valiente, y a la vez arriesgada, ya que una mala gestión del modelo de betas podría afectar gravemente a su imagen, si por ejemplo todos los ordenadores o todos los móviles dejasen de funcionar, o si los móviles comenzasen a hacer llamadas de forma autónoma y arbitraria.

Aquí desde el punto de vista de las pruebas y de la ingeniería del software, vemos como se presenta una disyuntiva, y hay que buscar un equilibrio entre la estabilidad del producto (por muy beta que sea), y la necesidad de hacerlo probar a un público lo mayor posible para obtener feedback. Desde luego, es necesario tener un gran control de las pruebas realizadas, y obtener métricas que nos permitan estimar (de forma aproximada, claro), el número de defectos y su gravedad en caso de liberar nuestro producto inacabado.

¿Y vosotros? ¿Os atreveríais a hacer público un software inacabado siguiendo un modelo de pruebas Beta? ¿Cómo gestionaríais los riesgos de hacer público un producto sin terminar?

Deloitte presenta resultados encuesta sobre uso del móvil

Estamos en una era digital. Eso está claro. Sin embargo, no podemos dejar de lado que cada día los usuarios estamos más y más enganchados a los dispositivos móviles.

Como desarrolladores de software, esto nos afecta por una doble vía: por un lado los hemos de tener en cuenta a la hora de crear aplicaciones y productos que realmente son del agrado del público y satisfacen sus requisitos (que los “enganchen”, vamos). Por otro lado, y por desgracia, también nos vemos afectados por esa misma “fiebre” de los dispositivos móviles. Eso nos puede hacer imparciales, y es un factor a tener en cuenta.

Recientemente, se han presentado los siguientes resultados, discretos diría yo, que muestran el número de veces al día que se consultan los móviles, entre otros interesantes datos.

Aquí se muestra cómo los jóvenes entre 18 y 24 años llegan a consultar su móvil hasta 53 veces al día (de media). Evidentemente, hay casos en que estas cifras se superan ampliamente, pero estamos hablando de valores medios.

En la figura siguiente, vemos los tiempos medios que los usuarios tardan en consultar su móvil desde que se despiertan por la mañana:

Los datos provienen del estudio que ha presentado la consultora Deloitte.

Fuente: http://www.deloitte.co.uk/mobileuk/smartphones-wake-up-and-plug-in/

El trabajo autónomo: ¿solución o problema?

Es el sueño de muchos: el trabajar como autónomos. Y sin embargo, pocos se atreven. A la dificultad se une el desconocimiento, el temor de emprender por cuenta propia una senda que por otro lado es radicalmente opuesta a la seguridad que nos proporciona el trabajar por cuenta ajena, recibiendo órdenes concretas en un horario concreto.

Estaba leyendo un artículo en prensa relacionado, y me ha precido retomar este interesante tema. Sin embargo, me voy a centrar el agunas afirmaciones que se hacen, y que para la desgracia de nuestro sector profesional, no me parecen del todo acertadas si las contemplamos desde el punto de vista de la industria del software. Como excusa, diremos que por el contenido y el tono generalista del artículo, no se han centrado ni mucho menos en el mundo del desarrollo/mantenimiento de aplicaciones.

  • Crece el número de profesionales autónomos. Por supuesto, ante el creciente desempleo, no queda otro remedio que buscar trabajo mediante el auto-empleo.
  • Los nuevos emprendedores surgen principalmente en el sector servicios. Pues claro, como que es el sector que aunque ha sufrido la crisis, lo ha sufrido en menor medida. Si te quedas en paro, y te planteas ser autónomo…¿no lo harás en un sector que es menos castigado por la crisis? Aquí estamos mezclando causa y efecto.
  • Responden a una demanda del mercado de personas con experiencia. El mercado siempre quiere personas con experiencia. La diferencia es que antes de la crisis, estas personas con experiencia eran caras, y ahora no lo son.

Al final, no me queda claro si el trabajar como autónomo es una solución o un problema. Lo que sí es cierto es que el mercado en general, pero también en nuestro sector en particular, es cada vez más precario y estacional. Trabajar por proyectos, por encargos, por picos de trabajo, está siendo cada vez más habitual. Pocas empresas son capaces de asegurar a sus empleados crecimiento, y al mismo tiempo, aseguramiento de la empleabilidad.