Archivo por meses: mayo 2012

Antipatrones

Un antipatrón es una mala solución de diseño, que termina llevando a una mala solución.

Para entendernos, estamos hablando de escoger una solución incorrecta para un problema, empujados por esa acuciante necesidad (que cada vez veo más a menudo) de recurrir con premura a soluciones ya implementadas porque nos encontramos con un problema ‘parecido’ a otro que en su día resolvimos de esa forma.

De momento, os dejo un pequeño extracto de los que podéis encontrar en la Wikipedia.

De Gestión:

  • Productividad a toda costa: La empresa busca la productividad a costa de la calidad del software y de la calidad de vida de sus empleados[…]
  • Negociador de jaula de acero (cage match negotiator): Se aplica cuando un coordinador, gestor o responsable aplica una filosofía de “éxito a cualquier precio”.
  • Estrellas nacientes (rising upstart): Se aplica a quienes, teniendo potencial, no son capaces de respetar la progresión profesional establecida, y pretenden sortear los plazos y requisitos de aprendizaje y madurez.
  • Humo y espejos (smoke and mirrors): Mostrar cómo será una funcionalidad antes de que esté implementada.

De Diseño Software:

  • Blob: Véase Objeto todopoderoso.
  • Sistema de cañerías de calefacción (stovepipe system): Construir un sistema difícilmente mantenible, ensamblando componentes poco relacionados.
  • Acoplamiento secuencial (sequential coupling): Construir una clase que necesita que sus métodos se invoquen en un orden determinado.
  • Problema del yoyó (yo-yo problem): Construir estructuras (por ejemplo, de herencia) que son difíciles de comprender debido a su excesiva fragmentación.
  • Singletonitis: Abuso de la utilización del patrón singleton.
  • YAFL (yet another layery otra capa más): Añadir capas innecesarias a un programa, biblioteca o framework. Esta tendencia se extendió bastante después de que se publicase el primer libro sobre patrones.

De Programación:

  • Doble comprobación de bloqueo (double-checked locking): Comprobar, antes de modificar un objeto, si es necesario hacer esa modificación, pero sin bloquear para comprobarlo, de manera que dicha comprobación puede fallar.
  • Lava seca (lava flow): Código muerto e información de diseño olvidada permanecen congelados en un diseño cambiante. Esto es análogo a un flujo de lava en el que se van endureciendo pedazos de roca. La solución incluye un proceso de gestión de la configuración que elimina el código muerto y permite evolucionar o rehacer el diseño para acrecentar la calidad.
  • Programación por excepción (coding by exception): Añadir trozos de código para tratar casos especiales a medida que se identifican.

Metodológicos:

  • Martillo de oro (golden hammer): Asumir que nuestra solución favorita es universalmente aplicable, haciendo bueno el refrán a un martillo, todo son clavos.
  • Reinventar la rueda (reinventing the wheel): Enfrentarse a las situaciones buscando soluciones desde cero, sin tener en cuenta otras que puedan existir ya para afrontar los mismos problemas.
  • Reinventar la rueda cuadrada (reinventing the square wheel): Crear una solución pobre cuando ya existe una buena.

 

Y muchos más que podéis revisar en la entrada de la Wikipedia.

Obviamente nadie está a salvo de cometer errores y acabar cayendo en alguno de los muchos que se enumeran.

Yo mismo he caído en más de uno en alguna ocasión, pero solo conociéndolos y siendo conscientes de nuestros errores podemos ponerle remedio y evitarlos en el futuro.

 

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.