Principios SOLID

Estos principios, que supongo ya conoceréis todos, están orientados a los que se inician en la programación orientada a objetos. Después de todo, el sentido común ya nos orienta a este tipo de prácticas, pero es gracias a su recopilación, que los que empiezan pueden aplicarlas.

Ayer un compañero me comentaba: «Oye Roberto, a veces las nuevas incorporaciones las formamos mucho y bien en tecnologías, en frameworks y lenguajes de programación. Pero no les enseñamos realmente a programar». Pensaba en la afirmación, y efectivamente, saber programar es algo mucho más complejo que saber un lenguaje o un framework. Es por eso que me he acordado de este post que llevaba mucho tiempo sin completar.

Por si algún despistado no conoce los principios SOLID, vamos a revisarlos.

Robert C.Martin, introdujo a principios de la década del 2000 este concepto. SOLID corresponde a 5 principios en los que fundamentar la orientación a objetos:

• S: Single responsibility.  Principio de responsabilidad única. Cada objeto, debe dedicarse a una sola cosa. Si os fijáis, es una ampliación del concepto clásico de programación en el que un método o función debe tener un único propósito.
• O: Open-closed. Las clases u objetos han de estar abiertas para su extensión, pero cerradas para su modificación. Este principio está directamente relacionado con la herencia en Orientación a Objetos.
• L: Liskov substitution principle (principio de substitución de Liskov). Este principio promulga que todos los objetos deberían ser sustituibles por instancias de sus subtipos sin afectar al funcionamiento del programa. Es decir, que no debemos reimplementar los métodos en las clases heredadas, sino utilizar los de las clases base.
• I: Interface segregation principle (principio de segregación de la interfaz). Este principio afirma que es mejor muchas interfaces cliente específicas, que tener una sola interfaz de propósito general. Este principio busca el desacoplamiento entre clases.
• D: Dependency inversion principle (principio de inversión de la dependencia), donde Robert C.Martin nos indica que se debe depender de abstracciones, no de implementaciones. Por ejemplo, la técnica o patrón de inyección de dependencias sigue este principio.

¿Y tú, tienes en cuenta los principios SOLID a la hora de programar?

 

7 Fallos habituales en una sprint review

Una sprint review parece sencilla. Pero como siempre, podemos caer en la dejadez, dejar de trabajar con rigor, cayendo en una serie de fallos habituales que os comento. Al final del post os dejo un vídeo que satiriza una sprint review. Pero empecemos con los 7 fallos habituales en una sprint review:

1.Expectativas de trabajo completado fuera del plan original.

Es muy típico esperar que se lleven a cabo tareas «extra». Después de todo ¿no es eso ser ágil? Entonces, ¿porqué no incluir pequeños cambios o tareas adicionales, durante el sprint? Creo que todos ya sabemos que un sprint precisamente está pensado para acometer de la mejor manera posible, las historias de usuario planificadas. Nada menos, pero tampoco nada más.

2.Confundir estimaciones con compromisos.

Esto es también muy habitual. Una estimación no es más que eso. A veces las estimaciones son erróneas, y un sprint trata de acometer todo el trabajo planificado, pero a veces simplemente no es posible. Deja la historia de usuario sin completar para el próximo sprint, no sin antes asegurarte de ver porqué te equivocaste al estimar, no sea que en realidad haya más trabajo oculto del que creías.

3.Expectativas no realistas

Podemos tener expectativas no realistas de ausencia de errores, corrección de errores existentes, funcionalidades pretenciosas, hitos inalcanzables, etc.

4.El product owner que no actúa como tal.

El product owner puede que vea la funcionalidad por primera vez en la propia sprint review. Eso significa que no ha dado feedback durante su desarrollo, y que su labor de product owner no ha sido tal.

5.No mantener informado al equipo.

La comunicación y la información son claves. El equipo debe estar puntualmente informado de todo, pero especialmente de revisiones hechas sobre los objetivos del sprint.

6.Ver la review como una oportunidad para buscar culpables, en lugar de aprender y educar.

Esto es también muy típico en proyectos que se inician por primera vez en SCRUM u otras metodologías ágiles. Cuando algo falla, debemos investigar los motivos y buscar soluciones…no culpables.

7.Confundirlo con una retrospectiva.

Efectivamente, los conceptos de sprint review y sprint retrospective son bastante diferentes. Mejor dejaremos el detalle de su comparativa en un post dedicado a ellos y a sus diferencias.

La línea de Base y los cambios en producción

Muchos me diréis que a qué viene esto ahora a cuento. Pues me sigo encontrando muchos casos en los que hay programadores que no terminan de entender el concepto de línea base. Además, este concepto es fundamental para entender los cambios en el ciclo de vida del software, desde el entorno de desarrollo, hasta el de producción. Y no, no me refiero a permitir o no hacer cambios directamente en producción. De eso creo que ya hemos hablado. Me refiero a controlar los cambios en cualquier entorno mediante el concepto de línea base.

¿Qué es la línea base?

La línea base es un concepto de la gestión de la configuración (otro día hablaremos de ella). La línea base se define en el IEEE 600.12/1990 como:

Una especificación o producto que se ha revisado formalmente y sobre los que se ha llegado a un acuerdo, y que de ahí en adelante sirve como base para un desarrollo posterior y que puede cambiarse solamente a través de procedimientos formales de control de cambios.

La línea base es un contrato. Un contrato igual que lo es una API, o el WSDL de un servicio web. La línea base establece en qué puedo confiar, porque es algo acordado (ni siquiera tiene porqué ser bueno, probado, excelente o definitivo). Hablamos de una versión de cada uno de los componentes software, que en conjunto, se ha acordado que es correcta en su conjunto. Pero sin suponer esto que cumpla los requisitos, ni las pruebas…simplemente es un hito.

Cuando trabajas con Subversión, TFS o Github, tenemos los conjuntos de cambios, tags o Changesets. Esas etiquetas o paquetes de cambios identifican el software en su conjunto, y son como una foto. Sí, como una foto del software en un momento y situación determinados del tiempo.

Aquí la idea no es versionar. No es un control de cambios. Es tener la posibilidad de devolver todo el código a un momento del tiempo en el que sabíamos que algo funcionaba (o no), pero al menos conocíamos su estado en conjunto. Esto es muy importante para controlar el estado de los entornos, para poder devolver un entorno (pruebas, desarrollo, calidad, preproducción, formación, producción), a un estado conocido.

Si la línea base es una foto, instalar una línea base es devolver a un entorno a un estado conocido, es un viaje al pasado.

Por ese motivo, jamás deberemos tocar el código en producción, ni en pre-producción, ni en otro entorno que no tengamos debidamente controlado con el correspondiente gestor (SVN, Github, TFS…). Porque si tocamos el código, hemos perdido la partida. Ya no podremos tener control de hacer una nueva «foto», y empezaremos a perder el control de los cambios, de los entornos, del desarrollo.

Y claro que podemos coger ese código, hacer un checkout en desarrollo y poner ese código después para recuperar el estado del entorno de desarrollo. Y claro, también existe Santa Claus, y Blancanieves, y los siete enanitos. Si no lo hicimos en un principio, si nos hemos dejado seducir para tocar el código en producción y «jugárnosla», hemos perdido el control y ha dejado de jugar a nuestro favor todos los beneficios de la integración continua, testing automático, etc, etc.

Alguna vez he oído decir que tocar el código en producción es como dejarse seducir por el lado oscuro de la fuerza. Tentador…pero no sólo es algo que esté mal…es algo cuyo precio vas a pagar tarde o temprano.

No borres tus huellas, vaquero

Esta entrada en mi blog la dedico a todos aquellos que borran sus huellas en el trabajo. Los que sólo guardan los ficheros en su última versión. Los que no versionan los documentos. Los que cuando tienen un fichero incompleto lo destruyen al comenzar uno nuevo.

Son los amigos de lo imperfecto. Tal vez sea la obsesión de aparentar perfección, o no mostrar debilidad, tan habitual en algunas empresas.

No se trata de guardar un registro de todo lo que hacemos, sino más bien de protegernos de nosotros mismos. Después de todo, la mayoría de herramientas de versionado de código nos protegen de nuestras ganas de cambiar el código en exceso, permitiéndonos recuperar una versión previa que funcionaba o que simplemente queremos revisar. Si estamos de acuerdo en el caso del código fuente…¿qué pasa con la documentación?

La documentación es parte del proyecto.

Debemos cuidar la documentación, tal y como hacemos con el código. De nada servirá esto a los que entienden que la documentación se hace «después del código».
Cómo me duele ver en los diseños técnicos o funcionales, código fuente o pantallas que se han obtenido de la versión final.
Los documentos  hay que versionarlos y cuidarlos como cualquier otro resultado de nuestro trabajo.

La necesidad del versionado.

Algunas ventajas de tener la documentación versionada en un repositorio:

• Documentación alineada con cada versión del código.
• Es fácil identificar los cambios en los objetivos, del mismo modo que el versionado del código permite identificar los cambios en los resultados.
• Acceso centralizado. Al estar la documentación versionada y centralizada, todo el mundo accede a la última versión.
• Notificaciones de versionado. Muchos repositorios de documentos avisan de nuevas versiones. Esto es útil porque el equipo de desarrollo puede estar informado de cualquier cambio en una Historia de Usuario, un Requisito (o como lo queráis llamar).
• Permite escalar proyectos. Es muy sencillo trabajar con post-its para documentar requisitos, pero escalarlo a un equipo de 50 personas en 10 países, no es sencillo. En un repositorio documental, incorporar a un nuevo equipo en otro país es tan simple como darles acceso.
• Utilizar un repositorio permite ahorrar reuniones: todo el mundo puede estar al tanto de que se está cociendo una nueva versión de los requisitos, o de que se han modificado 5 de las 10 historias de usuario de nuestro producto. Esto no significa que no sean útiles las reuniones. Simplemente se trata de que las herramientas hagan el trabajo más simple.

¿Y qué hacemos en un proyecto pequeño?

Si tu proyecto es muy pequeño, puedes hacer el versionado de forma manual. Guarda el archivo como «requisitos_v02» y ya está. También puedes integrar la documentación como parte del código, y que tu herramienta (Subversion, Git, etc), se encargue del resto.
De todas formas, es útil seguir con la documentación, las mismas técnicas que un repositorio de código:

• Check-out: Avisa de que el documento lo vas a modificar. Que la gente tenga claro que hay una nueva versión en curso. Eso les hará organizarse mejor y centrarse en las áreas que menos cambios vayan a tener. Pocas cosas molestan más que ver cómo llega un gran cambio sobre algo en lo que hemos dedicado varias semanas con sus larguísimas jornadas. Y más cuando hay otras tareas que podríamos haber avanzado en su lugar. Avisa de la fecha prevista para terminar la nueva versión.
• Check-in: Avisa de cada nueva versión. Que la herramienta (o tú mismo mediante un correo), notifique al equipo de una nueva versión de lo que sea (requisitos, análisis, etc). Hazlo ágil y simple. Tanto para el que lo lee, como para tí que lo escribes y que lo vas a tener que actualizar.

Actitud y respeto, fuentes del problema.

Al final, es una cuestión de respeto profesional, de velar por que nuestras acciones ayuden en lugar de interferir al resto del equipo. De intentar prever las consecuencias de nuestros actos, no limitarnos a soltar nuestro (llámalo código, documento o lo que sea), y darnos la vuelta para no ver los resultados.

Muchas veces oigo a la gente quejarse de lo mismo repetidas veces: «para qué documentar si nunca voy a tener la documentación actualizada». Es deprimente, ya que muestra un grave problema de actitud. Hazlo o no lo hagas, pero no lo intentes. Deja ya esa actitud derrotista, por favor. ¿Somos ágiles y por tanto capaces de abrazar los cambios en el código? ¿Y sin embargo no somos capaces de hacer lo propio con la documentación? Claro que van a llegar cambios, es algo inherente en el software. El problema está en que no documentamos, sino que escribimos novelas.

Yo no sé si hay falta de programadores, pero de lo que estoy seguro de que sobran novelistas, y faltan buenos analistas o arquitectos que documenten los objetivos técnicos y funcionales. Menos verborrea, y más UML, casos de uso, historias de usuario.

MasterDev, el MasterChef del software

Hala, por fin se ha acabado en España la versión infantil o «Junior» de un conocido concurso internacional de televisión llamado «MasterChef».

Yo, personalmente, os propongo hacer uno parecido llamado «MasterDev». Los objetivos de este nuevo concurso serían más o menos los siguientes:

• Los concursantes, tendrían una sección inicial del programa en el que se mostraría el lado humano: cómo han convivido, cómo han aprendido las últimas técnicas de programación, frameworks, lenguajes, etc. Se les vería su día a día encerrados en «la casa», donde tendrían sus momentos de roce, tensiones internas, se formarían grupos…
• Por supuesto, habría un apartado de «expulsados» en el que los concursantes elegirían a los 3 nominados. De entre ellos, uno sería expulsado por votación del público.
• Finalmente, el plato fuerte del programa sería el desarrollo «en directo» de una aplicación, basada en los requisitos y exigencias de los chefs (bueno, en este caso, scrummasters o similar). En este apartado, unos famosos programadores harían de estrellas invitadas y propondrían los casos de uso/historias de usuario a desarrollar. Serían los jueces que elegirían a los mejores programadores cada semana. Éstos «Master-Dev» podrían salvar a uno de los nominados, tal y como se hace en otro conocido concurso: «Gran Hermano». Durante esta parte del programa, se nos estaría mostrando a los programadores llevando a cabo las tareas encomendadas, con la tensión de ver el reloj. Para darle mayor realismo, podría ser un reloj marcando la hora de salida del  trabajo, lo que aportaría una tensión increíble.
• Finalmente, el momento culmen del programa sería cuando los jueces irían diciendo los puntos fuertes y débiles de cada programador, y se elegirían los «Master-Dev» de la semana.

No sé lo que os parece, pero yo creo que no tendría la misma tensión que el programa original «MasterChef». Ver 20 minutos a una serie de programadores, sentados en sus sillas, tecleando como si les fuera la vida en ello, no se si sería digno de ocupar el prime-time de las principales cadenas de televisión.
En el cine, «Swordfish» (2001) ha sido una de las películas en las que más tensión se ha podido observar mientras se mostraba a un programador (Hugh Jackman) tecleando en sus teclados y observando con pasión sus múltiples monitores. Sin embargo, veo difícil el llevar esto a la televisión, especialmente recordando el motivo que hace que Hugh Jackman salve su vida cuando es sometido a presión por John Travolta (sí, se trata del trabajo realizado por cierta señorita). Por cierto, ver a Hugh Jackman programando un peligroso virus simplemente «pegando» cubos entre sí en pantalla, es un puntazo. No tendría la misma tensión si «Swordfish» tuviera un diálogo más realista:
– «A ver…mierda. Me he dejado un punto y coma»
– «Compilo…y a ver….15%….40%….mierda. Dos warnings y 1 error. Pues vaya.»
– «A ver…busco el error en google, pero ¿esto que es?»
– «Ah ya lo tengo. Venga, cambio el tipo de la variable….añado el parámetro que faltaba…»
– «Compilo…y a ver…15%…40%…(dios que lento)…60%…mierda. Otro error.»

Tal vez se le podría dar algo más de emoción. Y no, no me refiero al trabajito que le hacen a Hugh Jackman en SwordFish para motivarle. Me refiero a comentarlo como si fuera….no sé…un partido de fútbol:
– Atención, John recibe el código, lo compila yyyyyyyyy Uyyyyyy. Un erroooor. Sí señores, un error ha entrado de llenoooooooo. Neumáticos Martinez, los mejores. Compreeeee neumáticos Martínez (no podía faltar la publicidad en una retransmisión deportiva).
– Señoras y señores, qué tensión! John todavía no ha corregido su error, y Anthony ha compilado con éxito atencióoooooon que ha compiladoooooo.
– Cuidado, cuidado, que un tercer programador está a punto de terminar, es Juan. Recuerden que Juan no había destacado en otros programas, pero ha terminado sólo 1 segundo y 3 décimas por detrás de Philips. Cuidado, todavía no han hecho checkin! Beba Rock-cola, burbujeante, maravillosa!
– Increible! Philips ha perdido el código! Error de aplicación, eso lo deja fuera del concurso! Qué tensión, John está terminando de depuraaaaaar yyyyy gana Juan!  Por tan sólo unas líneas de código por delanteeeeee.

¿Y vosotros? ¿Os gustaría ver un «MasterDev» como concurso?
En fin. Feliz año nuevo.

Update: Gracias a Julián Gómez por la idea de cambiar el titular, y por leerme. Me había quedado muy simplón como «MasterDev» sin más.

Programación eXtrema (XP)

EXtreme Programming (en adelante, XP), 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.

Las buenas prácticas de XP

XP establece unas serie de buenas prácticas entre las que encontraremos:

• Planning Game: Este método de estimación de la siguiente iteración.
• Entregas pequeñas: pequeñas e iterativas, las entregas en XP permiten la construcción y despliegue de forma rápida.
• Metáfora: produce una descripción simple y entendida por todos de lo que hay que construir. De esta forma, se guía a los desarrolladores sin entrar en complejos documentos funcionales. La metáfora es fácil de comprender por el cliente y el equipo, y proporciona suficiente información para guiar la arquitectura del proyecto.
• Programación estándar: Los programadores escribirán el código fuente de acuerdo con estándares de programación y buenas prácticas que favorezcan la comunicación. En este sentido, la buena práctica no tiene que malinterpretarse y generar una gran cantidad de documentación sobre cómo escribir código fuente.

La metáfora: ventajas

• La metáfora ayuda a entender los elementos básicos y sus relaciones
• Mediante ejemplos, es posible completar la definición funcional sin entrar en compleja documentación.
• Proporciona una visión de la arquitectura, sin entrar en el detalle.
• Establece un mecanismo sencillo de elaborar el producto y comunicar los objetivos.

La metáfora: inconvenientes

• Por desgracia, una metáfora no da detalles y profundidad a la explicación de lo que hay que construir.
• Los ejemplos asociados a la metáfora, pueden ser confusos, y no deben ser tomados de forma literal.
• La metáfora, no es realmente una arquitectura.
• La metáfora, no es sólo para los programadores, clientes o jefes de proyecto.

¿Todavía quieres ser programador?

Hace cosa de un mes, estaba leyendo uno de mis blogs favoritos. Jeff Atwood es todo un elemento, una figura reconocida en la red. Y sin embargo, consiguió sorprenderme (otra vez). Y no es porque no sea un tema conocido y de candente actualidad. Me gustó su enfoque. Y es que como tantas otras ocasiones, Jeff daba en el clavo.

Yo, personalmente, me ocupo de recibir y guiar en su inicio a las nuevas incorporaciones que suelen llegar a mi oficina. Es algo esporádico, y que no suele gustar a mis compañeros. Bueno, en nuestro entorno, es difícil encontrar a gente que en general les guste hablar en público. Pero sigamos. A esas nuevas incorporaciones, les trato de contar brevemente lo que pueden necesitar, sobre la empresa y nuestro sector. Pero también me encuentro muchas veces (y no sólo en mi empresa actual, sino más bien en todas), programadores que no tienen claro cuál es su futuro.

Normalmente, todos tienen claro que quieren más en su futuro laboral: más dinero, más categoría profesional…Pero no tienen claro cómo es el negocio del desarrollo de software y la programación, y por tanto, tienen dudas. El mundo del cine, prensa y televisión nos vende como un negocio lleno de oportunidades, con gran cantidad de puestos de trabajo, y porqué no…¡guay!

Pero los jóvenes que llegan a trabajar recién licenciados, empiezan una carrera como informática, o incluso otras diferentes como matemáticas o físicas. Y me da la sensación de que no tienen claro en qué se han metido. Y no me refiero a que sea malo. Simplemente, que al ser una profesión nueva y en constante evolución, creo que no hay información realista disponible sobre el sector, enfocada a los pre-universitarios. O incluso a los universitarios.

Normalmente, en este sector, los recién titulados empiezan programando. Simplemente porque hay mucha más oferta en programación en por ejemplo … administración de sistemas o diseño de circuitos.

El problema, es que la programación no tiene porqué gustar a dichos recién titulados. Y se nota en las preguntas que hago del tipo:

• ¿Sabes qué es un ciclo de vida?
• ¿Has oido hablar de la ingeniería del software?
• ¿Cuántos tipos de pruebas conoces?
• ¿Has automatizado pruebas funcionales?
• ¿Has programado en algún lenguaje?

Y por desgracia, las respuestas son decepcionantes. Y seguid sentados los que defendéis que tan sólo deben programar informáticos, y que el intrusismo por aquí, y que el resto no saben programar, y bla bla bla. Digo seguid sentados, porque las respuestas son igualmente decepcionantes para los que vienen de carreras como informática (técnica o superior). No digo que la universidad no sirva para nada. Digo simplemente, que hay una brecha significativa entre lo que prepara la universidad, y la realidad de las empresas y el mercado.

Y aquí es donde viene la pregunta. ¿De verdad te gusta programar? ¿Quieres ser programador? Porque te tiene que gustar. Porque lo tienes que disfrutar. Y porque de esa manera es como puedes mantenerte actualizado, y sobrevivir a proyecto tras proyecto (y empresa tras empresa).

Jeff Atwood va un poco más allá en su blog, y plantea una pregunta con trampa: «¿Todavía quieres ser programador?«. Y es que Jeff plantea que por desgracia, hay que tener en cuenta que esta profesión, no todo el mundo es capaz de aguantarla toda su vida. ¿Quieres seguir siendo programador a los 30…40…50…60? Alguno comentará que no hay problema, que a los 2 o 3 años te hacen analista, y en otros tantos, jefe de proyecto. Sí…claro. Y yo soy Mickey Mouse.

En esta profesión, como en muchas otras, no todo el mundo puede ascender para siempre de forma continuada. La carrera profesional está ahí, pero cada 100 nuevos recién titulados no pueden ser mañana 100 jefes de proyecto. No es posible. Así que hay que prepararse en nuestro sector para una pregunta clave, que Jeff sabe plantear en su blog con acierto: «¿Todavía quieres ser programador?». Porque a cierta edad (no hablo de 40 o 50 años, sino mucho antes), la ganancia en productividad de la experiencia, se ve contrarrestada por otros factores. Y no nos engañemos, hay gente que simplemente, no tiene esa pasión y esas ganas de investigar y estar al día: volver de trabajar tras una jornada agotadora y ponerse a leer lo último (lenguaje, herramienta, metodología, etc.), probarlo, etc, etc.

Hay muchas posibilidades en nuestro sector, pero hay que saber moverse. Hay muchas posibilidades en las que aplicar nuestro conocimiento adquirido tras años y años programando, y disfrutando (o sufriendo) en múltiples proyectos y en múltiples empresas y clientes. Tanto si en el fondo no te gusta tanto programar como pensabas (o como decías), tanto como si llevas tanto programando que empiezas a estar ya saturado, existen opciones como:

• Gestión.
• Testing.
• Calidad.
• Analista
• Analista funcional
• Escritor técnico/documentación
• Implantador de software.
• Ventas

En muchos de estos roles, encontrar gente realmente conocedora de los entresijos de hacer software, es muy difícil. Así que ¿porqué no aprovechar tu experiencia y conocimientos adquiridos en algo más? ¿No es eso mejor que quedarse estancado en tu carrera, siguiendo con una programación que realmente nunca te gustó, o dejó de hacerlo hace mucho?

Y tú…¿todavía quieres ser programador?

La culpa no es del usuario

Hoy vamos a ver quién tiene la culpa de los fallos del software.
Me acabo de encontrar una referencia a mi antigua entrada «Cuando la culpa es del usuario«, en la que yo bromeaba sobre quién tiene la culpa de los fallos en el mundo del software. Yo pensaba contestar o comentar en aquél blog, pero al final, había que registrarse y he desistido. Sin embargo, al ver los argumentos a favor y en contra, he pensado que hay que darle otra oportunidad a mi antigua entrada, y recuperarla, esta vez de forma algo más seria.

¿Quién tiene la culpa de los fallos del software?

Vamos a verlo con un ejemplo. Supongamos que hacemos una casa: planos, diseño, ejecución de la obra…todo. Y el usuario entra en la casa a vivir. Hemos construido la casa en base a las funcionalidades habituales: comer, desayunar, ir a dormir, ir al baño, entradas de luz, etc. Además, hemos cumplido las normativas existentes: seguridad, anchura y altura de puertas y ventanas, acceso de luz, aislamiento térmico, etc.

Supongamos que el usuario hace algo imprevisto como intentar salir por la ventana (y es un 8º piso). Si se muere, ¿está claro que es su culpa, no? Pero si le dejamos abierta la puerta al cuarto de alta tensión y no ponemos ninguna medida de seguridad…si se electrocuta y muere…quizás la culpa SEA NUESTRA.

Ahora supongamos que hace otras cosas como entrar por el garage en vez de la puerta de entrada, o tiene la absurda (o no tan absurda?) idea de comprar un sofá o una cama y éstos no caben por la puerta. Puede también querer mirar por la ventana, y encontrarse conque ésta da a la pared del siguiente edificio al que el nuestro se encuentra pegado (vamos, que sólo va a ver y tocar pared). ¿Quién tiene la culpa de esto?

Volvamos al mundo del software y veamos unos pocos casos más tecnológicos:

• El usuario entra en una parte no permitida del sistema. No podemos impedir que alguien obtenga una contraseña. Hasta ahí es cierto. Pero es nuestra responsabilidad como desarrolladores de software, que no sea posible acceder a partes del sistema restringidas, con una clave no autorizada. Esto me hace mucha gracia, porque tenemos la chulería de exigir que Windows sea super-mega-seguro…pero luego hacemos aplicaciones con más agujeros que un colador. Y entendemos que necesitamos un tiempo razonable para probar y corregir nuestros agujeros de seguridad (somos humanos, verdad?), pero no tenemos la misma tolerancia cuando en vez de desarrolladores, somos usuarios. Exigimos que el programa o sistema operativo que falla, se corrija DE INMEDIATO (los que lo programan no deben de ser humanos, sino robots). Y gratis. Y….vamos, que está claro que sabemos pedir…pero no dar. Exigimos derechos desproporcionados a los deberes que asumimos.
• El usuario juega con el sistema. Pues que juegue. Es el usuario. ¿Que lo rompe o cuelga haciendo alguna tarea prohibida? Para eso están los logs. ¿Que mete datos estúpidos o incorrectos? Para eso están los logs y el sentido común. Por supuesto, también están las validaciones de datos. Si permitimos «XXX» como fecha de nacimiento, probablemente la función de cálculo de Edad fallará.
• El usuario tiene que sacar su trabajo, que no es precisamente saber de la tecnología interna del programa. No tiene porqué saber si es puro Java, o JQuery…o lo que sea.

En fin, habría muchos más ejemplos que ahora mismo no tengo tiempo de abarcar. Pero sí me gustaría comentaros un caso real de un colega de profesión ha tenido, y que creo que va a ser representativo.

Caso real.

• Se trata de una aplicación web.
• En uno de los cambios de especificación, se añade soporte para iPad.
• La aplicación se prueba, y funciona correctamente en varios navegadores, tanto en Windows como en dispositivos iPad (hasta en Android!)
• Cuando llega el usuario, descubre que cierta funcionalidad, sólo está disponible con ratón: al pasar el ratón por encima de los elementos de la página, aparece una información específica de cada elemento. Esto, se introdujo por diseño para disminuir la información de pantalla. Y está genial. Pero un iPad no tiene ratón.
• Resultado: enfado del usuario y rediseño de la aplicación.
• ¿Quién tuvo la culpa?

Conclusiones:

Para acabar, resumamos las conclusiones de lo que hemos visto, y de lo que la experiencia me ha hecho ver en todos (y son muchos) estos años:

• El usuario no tiene culpa alguna de los errores que se producen.
• Es nuestra responsabilidad poner «paredes» y «puertas y ventanas» a la aplicación para permitir el acceso o no a las funcionalidades.
• Es nuestra responsabilidad cumplir las normas y estándares existentes, así como adaptarlos no sólo al tipo de usuario, sino al entorno (hardware y sistemas software con los que interactúe).
• Es nuestra responsabilidad identificar posibles interacciones del producto con otros productos, y ponerlo  como funcionalidades (si funciona) o restricciones (si no funciona).
• Es nuestra responsabilidad probar. Y probar todo, o asumir los riesgos de lo que no se prueba. Leía recientemente un post donde un compañero de profesión decía que no se puede cubrir todo con las pruebas. Y es cierto. Pero eso no significa que nos tapemos los ojos e ignoremos los riesgos.
• Automatizar es la clave: debemos hacer pruebas unitarias, y automatizar también las funcionales en la medida de lo posible. En el caso real que se ha mencionado, el problema no era del usuario, era de que no se hicieron todas las pruebas en todos los entornos. Si probar todo en tu PC cuesta 2 días…añadir un nuevo entorno (iPad), costará el doble (bueno, es una primera estimación).

eBooks gratis de Microsoft para este verano

Ahora que estamos en verano, y que algunos tenemos vacaciones (y merecidas, eh?), traigo un larguísimo listado de ebooks gratuitos de la mano de Microsoft y recopilados por Eric Ligman (Director responsable de Partner Experience en Microsoft):

Enlace 1
Enlace 2

Gracias al excelente blog de Eric Ligman por esta recopilación!!

Entre otros temas ampliamente tratados:
– Windows Phone 7
– Office 2010
– Office 365
– Sharepoint
– Visual Studio
– Microsoft Virtualization
– SQL Server
– Windows Server
– Windows Azure
– Cloud development
– Microsoft Dynamics
– Kerberos configuration
– Microsoft LightSwitch
– Lync
– ASP.NET
– Windows 7
…y muchos más.

Nueva Dotnetmania

La revista DotNetMania, ahora es DotNetMania+
Han migrado de web, a una nueva url: http://www.dnmplus.net/

Además, por tiempo limitado, tendrán sus contenidos abiertos, aunque ya están preparando ofertas para suscriptores.

Se trata de un portal orientado a programadores, arquitectos en tecnologías .Net, e incluyen novedades, artículos, cursos, vídeos, entrevistas, todo ello enfocado al mundo .Net.