Los sistemas tienen vida y debemos respetarla :)

Luego de mi última publicación y de algunas conversaciones al respecto, confirmé que:

  1. Un post no cubre todo lo que puede pasar por nuestras cabezas
  2. No hay verdades absolutas
  3. Siguen –y seguirán– existiendo los dueños de la verdad

Lo que también me quedó claro es que de cierta forma hemos perdido sentido o peor aún, hemos olvidado la naturaleza de un proyecto de desarrollo de software.

Sí, es cierto que hace mucho escribí sobre lo que se entrega al finalizar un proyecto, pero luego de reflexionar sobre ello, creo que vale la pena aclarar que las soluciones o productos que se entregan, respetan un ciclo de vida, el cual desde mi punto de vista se descompone en actores, procesos y actividades.

Para esto, consideré las siguientes premisas:

  1. Todo proceso conlleva a un conjunto de actividades.
  2. Un actor puede estar involucrado de manera general a un proceso o de forma particular a una o más actividades.
  3. Para efectos prácticos, aplicación, sistema, producto y solución representarán lo mismo 🙂

Hasta el momento, mi propuesta se refleja en este diagrama:

ciclo-vida-aplicaciones

Continue reading

En serio ¿Qué es DevOps?

Esta semana conversaba con un amigo sobre cómo el mercado ha transformado un gran concepto en un aspecto netamente comercial que a su vez ha generado nuevos roles, herramientas y cosas que de alguna u otra forma, estamos agregando a nuestro CV.

Si bien es cierto el título del post es algo pretencioso, es lo que pienso y digo cada vez que converso sobre este tema.

Las pocas veces que he conversado con expertos en la materia (quienes por “extrañas” razones, no lo mencionan como la clave de su hoja de vida), además de notar cierta molestia en ellos, me encuentro con dos cosas que pueden parecer obvias:

  1. DevOps no es un conjunto de herramientas.
  2. DevOps es una cultura, una filosofía.
devops-culture-cartoon

Fuente: LinkedIn

Continue reading

Visual Studio for Mac – Preview 3 – sigue siendo Xamarin Studio

A pesar de que Visual Studio for Mac me tiene algo decepcionado, hoy lo abrí luego de mucho tiempo y como todavía sigue en modo Preview (ni siquiera en Beta, como mi blog :D), no me sorprendió que al abrirlo me haya salido el updater 🙂

Visual-Studio-for-Mac-Updating

Mientras pasaba de Preview 1 a Preview 3, me puse a leer las notas del release y además de corregir bugs propios de una versión preview, se incluyen mejoras en la compatibilidad con F#, los proyectos de Visual Studio –aquí se refieren a la versión oficial–, MSBuild, unit testing y soporte a .net core. Esto último me tiene confundido pues estaba seguro de que ya estaba.

Continue reading

Deuda humana

Hace unas semanas –luego de años intentándolo– pude compartir mi opinión sobre la deuda técnica. Algunos amigos me comentaron que veían que el post estaba incompleto y es cierto, no cubrí muchas cosas que tengo en mente (como por ejemplo, cómo medirla, qué herramientas usar o cómo evitarla) pero creo que para suerte de todos nosotros, podemos encontrar abundante información e internet.

Algo muy parecido a esta deuda, es lo que entre conversaciones de amigos denominamos Deuda Humana (DH). Aquí una breve historia que nos ayudará a entender el caso:

Juan es un jefe de proyectos que no pierde oportunidad para menospreciar a su equipo. Pasa el tiempo y poco a poco, algunos miembros de este empiezan a llegar cada vez más tarde, pedir un cambio de proyecto o incluso llegan a cambiar de trabajo.

Pasado un tiempo Juan descubrirá que aquellos que dejaron el equipo –o el trabajo– mostrarán resultados desde favorables hasta sobresalientes.

Independiente al impacto generado, las personas que dejaron el equipo se muestran más motivadas y ese puede ser el inicio del cambio en el nuevo trabajo en el que se encuentren.

Continue reading

Deuda técnica en el 2017

Si bien es cierto nunca he escrito sobre la deuda técnica, reconozco que cada cierto tiempo reviso o empiezo un nuevo borrador al respecto y lo dejo –con mucho dolor– en la lista de apuntes sin publicar.

Hoy por la noche voy a borrar aquellos apuntes y tengo un sinsabor que aumenta con el paso de los años.

Antes de continuar con ello y para quitarme el clavo, aquí algunos apuntes:

  1. Ward Cunningham indica que la deuda está asociada a la programación/reprogramación/corrección que harás más adelante, pues hoy –o ayer– no hiciste un programa sin seguir las recomendaciones, estándares o buenas prácticas de programación y/o arquitectura.
  2. McConnellFowler clasifican las causas como deliberadas, por desconocimiento o incluso ingeniudad.
  3. Por mi parte y considerando que más que software se entrega una solución, pienso que la deuda se debe analizar en todo sentido, en cada capa, etapa, proceso, modelo o secuencia utilizada para la creación del producto.
    • Esto significa que también se debe hacer una mención al hecho de cómo se definen las necesidades de los usuarios o cómo es que se compila, distribuye o instala el software resultante.
    • Tampoco se debe olvidar el prototipado/maquetado de la solución. El cual a veces es olvidado y otras es tan sobrevalorado que hasta llegas a odiarlo.
  4. La deuda se debe mitigar de a pocos ni bien se vaya identificando. Sería ideal eliminarla pero casi nunca es así.
  5. Para finalizar, creo que para no confundir, la deuda técnica debería cambiar de nombre o al menos de versión, pues la realidad ha cambiado y con tantos nuevos jugadores, debería existir algo así como una “Deuda Técnica 2.0”

Continue reading