La deuda técnica

Seguro que todos hemos trabajado en algún proyecto en el que, ya sea por restricciones de tiempo, recursos o conocimientos, no se tomaban las decisiones correctas en todo momento. En el número de este mes de la revista Communications, Eric Allman escribe sobre esa situación, definida, en 1992, por Ward Cunningham como «deuda técnica«.

El desarrollo de un proyecto de ingeniería conlleva balancear constantemente tres variables: tiempo, funcionalidad y recursos. Se deben elegir dos pero jamás se podrán tener los tres. En el momento en que necesitemos los tres estaremos incurriendo en una deuda.

La deuda técnica puede aparecer de muchas formas diferentes: la escritura de un algoritmo más lento del necesario en producción pero que se implementa más rápidamente, el retraso del mantenimiento del hardware por recortes de presupuesto, posponer la escritura de la documentación hasta el final del desarrollo por escasez de personal que la redacte, omitir abstracción necesaria en la programación del sistema por no tener tiempo para comprender el código escrito por otros desarrolladores, etc.

El problema fundamental de la deuda técnica no es la deuda en sí, ya que en muchos momentos es aconsejable adquirir deuda, por ejemplo cuando se acerca el fin de vida del producto, o incluso imposible de evitar, como cuando se realiza un prototipo, sino no saber gestionarla. Pocos proyectos incluyen en su planificación el tiempo necesario para devolver esta deuda y acaban ahogados por los intereses de la misma.

El motivo principal de que la devolución de la deuda técnica no se planifique en los proyectos, y por lo tanto que no se devuelva, es el desconocimiento de los niveles superiores de gestión de las consecuencias que puede acarrear esta deuda sobre el proyecto.

La solución este problema, al igual que ocurre con la deuda financiera, es entender hasta el último detalle del compromiso al que estamos llegando y, desde los niveles más bajos, entender y hacer entender los riesgos. Una vez entendidos los riesgos hay muchas formas de devolver la deuda: desarrollos internos de mejora, releases de asentamiento y estabilización pactadas con el cliente, etc.

Conclusión: no es malo adquirir deuda técnica si todos los niveles dentro del proyecto entienden los riesgos que están asumiendo y se planifica de forma correcta como devolverla. Si no se entiende deuda técnica y no se planifica su devolución, se está condenando a los proyectos al fracaso por la asfixia de sus recursos, que consumirán más tiempo intentando pagar los intereses provocados por la deuda que en el avance del proyecto.

Gestión: 10 formas de NO motivar a tu equipo

No, no me he equivocado al escribir el título, esta es una entrada sobre cómo NO motivar a tu equipo.

¿Y por qué el ‘no motivar’ cuando lo habitual es hablar de lo contrario?

Pues porque sobre motivación tenemos ya entradas en otros blogs (aquí, aquí o aquí) con buenos consejos sobre cómo gestionar nuestros equipos, pero sobre la desmotivación no es habitual hablar, cuando siempre he creído que tan importante es hablar sobre cómo hacer las cosas bien, pero también importante conocer qué es lo que NO debemos hacer para evitar cometer errores.

Por ello, os dejo 10 puntos a tener en cuenta para NO motivar a tu equipo:

  1. Vigila y desconfía. Muchos gestores son incapaces de mostrar un mínimo de confianza por su equipo, lo que les lleva a desconfiar continuamente de ellos, de lo que hacen, de si dicen la verdad o les engañan… llegando incluso a casos absurdos en los que empiezan a llegar antes que sus propios equipos para controlar a qué hora llegan y a qué hora se van.
  2. Maximiza los errores. Si alguien se equivoca, encárgate de que sea lo más público posible y de pregonar a los cuatro vientos quién y en qué se ha equivocado. Incluso si son cosas nimias y sin mucha importancia, trátalos como si fuesen grandes errores, nada como un poco de vergüenza pública para generar malestar e iniciar la ‘Política del Miedo’.
  3. El Miedo genera respeto, o al menos así lo creen muchos, por desgracia, que creen que el respeto es algo que viene con el cargo y que no hay nada como infundir miedo (sobre todo en tiempos de crisis) para que la gente de su equipo se abstenga de intentar engañarles o trabajen mucho más por miedo a quedarse en la calle.
  4. No marques objetivos claros. La gente se esforzará más en su trabajo si no están seguros de qué les has pedido o en qué medida su trabajo es importante, prestando más atención a lo que hacen si creen que pueden llegar a ser el siguiente objetivo de la bronca. Además se supone que todos son profesionales y como tales deben actuar, no como niños que esperan la aprobación paterna.
  5. Comparte Información, pero solo la negativa. Cuanto menos sepan más intranquilos estarán, cuanto más intranquilos mayor tensión, a mayor tensión menos se acomodan. Si además les sumas el bombardeo continuo con mensajes negativos sobre ‘lo difícil que están las cosas’, o que ‘no hay dinero para el proyecto’, o el infalible ‘a final de año no estaremos todos aquí’, no solo evitarás que se acomoden sino que además sus expectativas serán menores y se esforzarán mucho más por mantener su puesto de trabajo.
  6. Los éxitos son tuyos, ¿por qué darles algo a ellos? Está claro, ¿quién maneja el grupo? ¿quién lo gestionan? ¿quién manda?… entonces, los logros son tuyos y de tus superiores, que sois quienes debéis disfrutarlos. A ellos, como mucho, con algún correo de felicitación genérico e impersonal debe ser suficiente. Algo más personal podría hacer que se relajaran o creer que son ellos las piezas importantes del equipo y no tú.
  7. Relaciones impersonales. Una empresa no es un club de amigos, la gente va a trabajar y no a trabar amistades ni relaciones. Y qué mejor ejemplo que empezar dando ejemplo con tu comportamiento hacia ellos. Una actitud distante evitará incómodas familiaridades, o que se crean que pueden perder el tiempo impunemente delante tuya hablando de cine, fútbol o cualquier tema no profesional.
  8. Tu opinión importa, la suya menos. Tú eres el jefe, tú eres quien les evalúa y por ello debes de ser objetivo, en la mayor parte de los casos. Y qué mejor forma de serlo que evitando que te mareen con sus opiniones, en las que siempre son víctimas pero nunca se quieren responsabilizar de algo, y si lo hacen es para darte pena. El Feedbackestá sobrevalorado y al final genera más quebraderos de cabeza que beneficios. Y no digamos si se trata de opinar sobre qué hacer en el proyecto, dejar que todo el mundo tenga voz y voto al final lleva a que cualquiera crea saber qué se debe hacer.
  9. Elegidos. Si tienes suerte, encontrarás dentro de tu equipo, o las habrás traído contigo, que te son afines y piensan como tú en todo. En esos casos no tengas miedo de mostrar tu predilección por ellos, tu favoritismo y dejar claro al resto del equipo que ellos son quienes obtendrán acceso a los beneficios que ellos no compartirán. Si el resto quieren obtener los mismos beneficios, que aprendan de ellos y compitan por conseguirlos.
  10. El sprint continuo. Mantener una presión continua, hacer que todos se esfuercen al 120% cada día (por supuesto sin compensación alguna) hará que puedas adelantar tus fechas de entrega por delante de los demás, lo que te hará destacar sobre el resto de grupos con los que compitas. Si dejas que se relajen, llegará un momento en el que bajarán el ritmo y corras el riesgo de ver peligrar tus futuras ascensos.

Obviamente estos 10 puntos representan todo lo que NUNCA debemos hacer si lo que queremos es motivar a nuestros equipos. Quizás alguno de ellos pueden ofrecernos una momentánea mejora en el trabajo, en forma de adelanto en el avance o un incremento de disciplina, por lo que muchas veces resulta terriblemente tentador tirar de ‘galones’.

Pero lo cierto es que ‘convencer’ es un arma mucho más poderosa que ‘imponer’, al igual que ganarse el respeto y conseguir que tu equipo te siga porque te vean como un líder siempre está por encima de ejercer de ‘Dictador’.

Por ello, si te ves identificado en alguno de los puestos (aún más si lo haces en varios) quizás sea una buena idea repasar los enlaces que tenéis más arriba para repasar cómo conseguir motivar a vuestros equipos.

Aunque siempre hay casos y excepciones, y momentos en los que ser ‘más duro’ se hace necesario para tratar con determinadas personas. Y es que al fin y al cabo, cada persona es un mundo y por eso mismo no se puede tratar ni gestionar a todos por igual.

Virtualización (I) – Introducción & Hypervisor

Si hay un tema que en los últimos años ha ido en auge y poniéndose de moda, este ha sido el de la Virtualización y el Cloud Computing.

Primero en entornos empresariales, y desde hace unos años entornos PC para permitir que cualquier usuario doméstico pueda disfrutar de las ventajas que proporciona.

Por ello, con esta primera entrada dedicada al tema, intentaremos ofrecer una visión sobre qué es, para qué utilizarlo e incluso una guía de cómo adentrarnos en este mundillo.

1. Introducción.

La virtualización consiste en la emulación por software de un recurso físico, que puede ser una plataforma física, un dispositivo de almacenamiento o un recurso de red.

Mediante la virtualización, podemos gestionar los recursos hardware de una máquina (RAM, disco, interfaces de red, CPU…) y repartirlos entre las distintas máquinas virtuales que podamos crearnos y tener arrancadas en un equipo.

La forma de llevar a cabo esto es a través del uso de Máquinas Virtuales, que se crean y gestionan a través del software específico de virtualización ya sea en entornos PC o para entornos Servidor.

En el entorno PC el software de virtualización nos permite emular máquinas físicas, siempre con características inferiores a las de la máquina que las aloja, donde podemos instalar el mismo u otros Sistemas Operativos. De esta forma, podemos emular dentro del mismo PC segundas máquinas totalmente funcionales, con las que hacer pruebas, probar software no compatible con el sistema anfitrión, como si dispusiéramos así de más máquinas o para asegurarnos de que cualquier prueba no pueda afectar al sistema que las aloja.

Para los entorno Servidor, los objetivos principales de la virtualización son:

  • Poder crear múltiples entornos controlados y aislados, que coexistan de forma independiente.
  • Aprovechar el HW de servidores potentes, que de otra forma se verían no utilizado, al disponer múltiples máquinas sobre la misma plataforma hardware anfitriona.
  • Resolver el problema de acoplamiento entre Sistema Operativo y Hardware.
  • Proporcionar mayor flexibilidad, ya que las máquinas virtuales puede ser movidas de una máquina física a otra según las necesidades existentes en cada momento.
  • Mejorar la disponibilidad de las máquinas, ya que en caso de fallo hardware se pueden desplegar en un nuevo servidor de una forma más rápida.
  • Reducir los costes de mantenimiento, al haber menor número de servidores físicos.

¿Y cuál es el Software responsable de proporcionar esta funcionalidad en uno u otros entornos?

Al software se le conoce como Hypervisor y actualmente existen dos tipos que nos proporcionan formas distintas de llevar a cabo la virtualización.

Actualmente la virtualización se realiza mayoritariamente sobre plataforma x86, lo que ha llevado a Intel (Intel VT) y AMD (AMD-V) a optimizar sus procesadores incluyendo instrucciones orientadas a optimizar la virtualización.

2. Hypervisor

El Hypervisor es la plataforma software que nos permite crear y gestionar las máquinas virtuales, que pueden alojar distintos sistemas operativos ejecutándose de forma aislada sobre la misma plataforma hardware.

Su nombre viene del hecho de que se considera que su ejecución se realiza un nivel por encima del software supervisor, ofreciendo una plataforma hardware virtual a los SSOO huéspedes.

Es importante tener claro esto, puesto que una de sus funciones es aislar a los SSOO del hardware real y controlar el acceso a dichos recursos.

Y dentro de los Hypervisores existentes, podemos distinguir entre dos tipos, en función de cómo se ejecutan.

2.1 Tipo 1: nativounhosted o bare metal

Los Hypervisores de este tipo se ejecutan directamente sobre el hardware, con el apoyo de un SO preparado para poder iniciarse y acceder a los recursos hardware.

Dentro de este tipo podemos encontrar VMware ESXi (gratis), VMware ESX (de pago), Xen (libre), Citrix XenServer (gratis), Microsoft Hyper-V Server (gratis).

2.2 Tipo 2: hosted

En este caso, el Hypervisor requiere de un SO completo ya instalado y en ejecución.

Aquí podemos encontrar Oracle: VirtualBox (gratis), VirtualBox OSE (libre), VMware: Workstation (de pago), Server (gratis), Player (gratis), QEMU (libre), Microsoft: Virtual PC, Virtual Server.

Como podéis ver, cada tipo implica distinto funcionamiento y distintas necesidades a la hora de virtualizar, dependiendo de qué es lo que necesitemos en cada momento.

Así, el tipo 2 sería más apropiado para virtualizar en el PC de nuestra casa, pudiendo de esta forma alojar otro SO dentro de un Windows o un Linux, sin tener para ello que hacer nada más que instalar VirtualBox o VirtualPC.

Sin embargo, el tipo 1 sería más apropiado si lo que buscamos es preparar un servidor que alojará nuestras máquinas virtuales en un entorno empresarial, o como viene siendo habitual en la actualidad, para plataformas VPS de Hosting.

Más adelante hablaremos sobre estas opciones y veremos ejemplos de cómo montar nuestra plataforma de virtualización.

Solucionar el error: ‘MAX_FRAMES_PER_TRACE limit’

Trabajando con Spring Roo y STS, es posible que llegado el momento os encontréis de bruces con este error:

28-feb-2012 10:08:12 com.springsource.insight.intercept.trace.SimpleFra meBuilder enter
GRAVE: Frame stack exceeded MAX_FRAMES_PER_TRACE limit or has been aborted limit: 3000 frameCount: 3000 aborted: false
28-feb-2012 10:08:12 com.springsource.insight.intercept.trace.SimpleFra meBuilder enter
GRAVE: Frame stack exceeded MAX_FRAMES_PER_TRACE limit or has been aborted limit: 3000 frameCount: 1 aborted: true
28-feb-2012 10:08:12 com.springsource.insight.intercept.trace.SimpleFra meBuilder enter
GRAVE: Frame stack exceeded MAX_FRAMES_PER_TRACE limit or has been aborted limit: 3000 frameCount: 1 aborted: true
28-feb-2012 10:08:12 com.vaadin.Application terminalError
GRAVE: Terminal error:
java.lang.IllegalStateException: Imbalanced frame stack! (exit() called too many times)

Este error surge por las limitaciones de Spring Insight, la máquina virtual con el servidor de desarrollo integrado en STS, que con la configuración por defecto nos genera este error en cuanto empecemos a desarrollar una aplicación que realice muchas operaciones sobre una base de datos.

Para solucionarlo, tan sencillo como añadir en la configuración de ejecución «Run -> Run Configurations -> VMware vFabric tc Server Developer Edition v2.6» el siguiente argumento al arranque de la máquina: «-Dinsight-max-frames=200000»

Tras añadir la opción, paramos el servidor y al volverlo a iniciar y lanzar nuestro proceso, ya no debería darnos el error. En el caso del ejemplo, con el valor incrementado a 200.000 nuestro proceso no volvió a fallar en local.