La Pastilla Roja | Usos sociales de la tecnología

Mentalidad medieval

Publicado el 27 de septiembre de 2016 por Sergio Montoro

Recientemente encontré compartido en Facebook un artículo de The Economist titulado The alphabet of success sobre las guerras por el talento. Para ilustrarlo los editores han seleccionado una fotografía alegórica de un mando intermedio mitad ejecutivo hipster mitad caballero medieval. No sé si la imagen simboliza algún tipo de admiración idealizada por los guerreros de antaño o si la han colocado con doble intención (lo más probable). Pero en cualquier caso me ha servido para recordar que organizativamente seguimos en la edad media.

Según la moda actual, la misión de un director general (y de su director de recursos humanos) es crear una “misión, visión, valores” e inspirar a las personas con más talento para que se unan con fervor a la causa. Esto no difiere mucho de la misión del Rey Arturo y sus Caballeros de la Mesa Redonda buscando el Santo Grial. Por desgracia, la vida de los caballeros medievales solía ser muy dura y su esperanza de vida bastante corta. A pesar de lo cual, parece ser que llegar a caballero y morir en batalla descuartizando a uno de tus pares se consideraba un gran honor.

Si bien admiro y respeto las grandes causas, a mi me van a perdonar los monarcas pero hace ya más de tres lustros que despedí mi jefe y me hice rōnin. Ahora ya no tengo tanta estrategia como tenía de joven, coger cada oportunidad al vuelo es mi estrategia. Y me parece que no estoy solo en el empeño, pues en Europa de un tiempo a esta parte se está produciendo una verdadera epidemia de contratistas independientes que no quieren una nómina en ninguna banda salarial por ridículamente alta que esta sea. Por no hablar de EE.UU. donde la epidemia no es de contratistas sino directamente de emprendedores, y no es para nada algo nuevo.

Las aspiraciones salariales son tan elevadas que la única forma de retribuir a los empleados estrella es con opciones sobre acciones. Sin embargo, las opciones sobre acciones son un arma de doble filo. Los inversores son personas bastante avariciosas, en general, no les gusta que nadie se «forre» a su costa, ni siquiera los propios empleados que han creado la riqueza. Entonces los planes de opciones suelen estar cuidadosamente diseñados para que los plazos de adquisición de derechos sean anuales (normalmente durante un quinquenio) y, además, suele haber períodos de bloqueo en los que los empleados no pueden vender sus acciones tras haberlas adquirido. Esto en no pocas ocasiones se traduce en un medio de financiarse con los empleados, no sólo en forma de retribución diferida sino incluso obteniendo dinero líquido con las acciones adicionales que compran fuera del paquete de opciones. Eso suponiendo que las acciones suban, por supuesto, porque ya se ha visto, por ejemplo, el problemón que ha tenido LinkedIn con la caída de valor de las acciones en manos de empleados. En el siglo XX hubo empresas que forjaron millonarios. De Microsoft salieron bastantes. Y sin llegar tan lejos yo conozco empleados de Oracle que obtuvieron buenos beneficios de sus acciones en los noventa. Pero, como he comentado, los inversores han ido aprendiendo, de modo que cada vez es más difícil hacerse rico con acciones a menos que se tengan verdaderas acciones de cofundador.

Según cuenta el artículo, el director de recursos humanos de Google cree que un ingeniero «galáctico» vale 300 veces lo que un ingeniero medio. Lo cual se puede interpretar como que todas las empresas están obsesionadas por contratar al 0,3% de los candidatos. Lo paradójico de la retribución es que al 0,3% de esos empleados más buscados no les importa realmente el dinero. Creo que Vinton Cerf no sale en Forbes ni Tim Berners-Lee tampoco. Los ingenieros sobresalientes lo son porque se encuentran intensamente motivados por su trabajo, sin esfuerzo no se consigue nada, independientemente del nivel de inteligencia que se tenga. Por consiguiente, no se requieren arengas de ningún cantamañanas para mantener la llama creativa de un genio.

Alguien en recursos humanos y en la torre de marfil del consejo de dirección debería darse cuenta de que en algún momento las personas dejan atrás su ingenuidad juvenil y empiezan a preocuparse menos por ganar una fortuna y por quemar su vida intentando cambiar el mundo y en cambio se preocupan más por arreglar su propia vida, su familia, su casa, y su barrio. Muchos caballeros medievales se acaban dando cuenta de que la victoria con la cual destruyes lo que más querrías proteger no sirve para nada. También hay puestos de trabajo menos ambiciosos para sufridos pagadores de hipoteca, por supuesto, pero en ellos la gente que yo conozco a veces no es feliz y vive planeando las siguientes vacaciones, ansiando la prejubilación o simplemente pensando en acabar de pagar la hipoteca para poder cambiar de vida. Estos empleados son, precisamente, los más vulnerables a la credulidad de que el valor de sus acciones se multiplicará por cien, permitiéndoles así comprar su libertad.

Por otra parte ¿se debe crear una política de recursos humanos basada en el 0,3% de la plantilla? Al final del día se busca al empleado perfecto, que es brillante pero dócil, fiel y emocionalmente estable. Lo que sucede es que no se puede buscar un genio para cubrir un puesto. La única forma de encajar a un genio en una empresa es crearle un puesto a medida. Pero no es posible crear un puesto a la medida de todos y cada uno de los empleados. Los ingenieros veteranos (los que no son del 0,3% quiero decir) se mofan de los procesos de selección durante la hora del café. Luego los responsables de selección se quejan de que encontrar un buen candidato es como buscar una aguja en un pajar. Pero es que en el siglo XXI no se puede pretender que por darle una espada a alguien y nombrarle caballero a cambio firme un contrato vitalicio de vasallaje.

Post relacionado: El perfil del empleado perfecto.

Artículo relacionado: Trabajar en Google no es perfecto (Ainhoa Iriberri).

Publicado en Entorno laboral, Tecnología y Empleo | Deja un comentario

Computación cuántica para torpes

Publicado el 26 de septiembre de 2016 por Sergio Montoro

Dilbert on quantum computing

La computación cuántica es el tema esotérico de moda en informática teórica y práctica. Este post trata sobre ella desde el atrevimiento que da la ignorancia, pues actualmente nadie comprende la física cuántica en su totalidad, y mucho menos yo, pero sí es posible explorar sus fascinantes posibilidades. He estructurado el texto desde lo menos técnico a lo más técnico intentando evitar las ecuaciones hasta el final de modo que cada cual pueda leer hasta donde le interese.

Motivación y aplicaciones de la computación cuántica

El orígen de la computación cuántica se atribuye a Paul Benioff y Yuri Manin en 1980, y a un artículo de Richard Feynmann en 1981 en el cual sugirió que dado que es extraordinariamente difícil simular el comportamiento cuántico con ordenadores convencionales entonces una forma mejor de estudiar modelos de la realidad sería fabricar ordenadores cuánticos. Grosso modo la complejidad del problema estriba en que en un sistema cuántico las partículas y sus interacciones no pueden considerarse por separado como si fuesen bolas en una mesa de billar sino que hay que tratar todo el sistema en conjunto.
Los estudios sobre la viabilidad práctica de construir dispositivos computacionales que usen efectos cuánticos se remontan a hace ya más de una década, pero desde que recientemente Lockheed Martin, Google, la NASA y la CIA se interesaron por el producto de la empresa D-Wave, las publicaciones como Wired se han plagado de artículos sobre los dispositivos computacionales cuánticos presuntamente venideros. Quiero enfatizar el término dispositivo computacional versus ordenador porque hoy por hoy no existe tal cosa como un ordenador quántico, sólo existen máquinas que ejecutan determinados algoritmos concretos utilizando efectos cuánticos para acelerar la resolución de problemas especialmente difíciles de resolver con algoritmos clásicos.

La computación cuántica no revolucionará a corto plazo la informática en nuestros hogares pero podría catalizar avances científicos que influirían enormemente en nuestras vidas cotidianas. La razón de que la computación cuántica esté limitada a centros de cálculo es que lo más parecido que existe actualmente a un ordenador cuántico es una nevera gigante cuyo interior está a 20 milikelvis. Es por ello que el modelo de negocio de supercomputación cuántica se orienta más hacia SaaS que hacia la venta de hardware.

La computación cuántica no hará (por ahora) que nuestros emails se abran más rápido ni que los gráficos de los juegos mejoren. Pero podría servir, por ejemplo, para descubrir materiales superconductores a temperatura ambiente. O también podría usarse para encontrar un método de fabricación de fertilizantes mejor que el método de Haber que data de 1905 y en el que según las estimaciones se emplea actualmente entre el 3% y el 5% del gas natural y entre el 1% y el 2% de toda la energía producida por el hombre. Por consiguiente, encontrar un proceso industrial capaz de fijar el nitrógeno en amonio como hacen los diazótrofos supondría un gran ahorro de energía y emisiones de CO2. Pero las simulaciones de las reacciones químicas requeridas para fijar el nitrógeno ambiental son demasiado costosas computacionalmente para un ordenador convencional.

La mayoría de los ejemplos de aplicación se centran en problemas de optimización como encontrar el tratamiento de radioterapia óptimo para eliminar un tumor causando el mínimo daño colateral al paciente. Aunque existen dos excepciones notables: las aplicaciones en inteligencia artificial y el ataque a sistemas criptográficos. Esta última aplicación ha atraido mucha atención pues los algoritmos DSA y RSA con los que está encriptado la gran mayoría del tráfico de Internet son vulnerables a ataques por un computador cuántico lo bastante potente (que actualmente no existe). Por consiguiente, tanto gobiernos como grandes empresas están muy interesados en controlar la computación cuántica, o al menos una parte de ella, y ya existen muchas patentes sobre algoritmos y tecnologías cuánticas aplicadas a la computación.

Limitaciones cuánticas de los ordenadores digitales

Una de las predicciones futurológicas más acertadas de los últimos 50 años es la Ley de Moore. Enunciada en 1965 predijo que el número de transistores en un microprocesador se duplicaría aproximadamente cada 24 meses. Y se ha cumplido con una precisión sorprendente. Sin embargo, la predicción está peligrosamente cerca de un límite de posibilidades de producción.

Para meter más transistores en un microprocesador lo que se hace es reducir el tamaño de los transistores. Actualmente, los transistores más modernos se fabrican con tecnología de 14 nm (1nm = 1 mil millonésima de metro). Puede que se consigan alcanzar los 5nm en 2020. Pero a medida que se reduce el tamaño es más complicado disipar el calor y además se producen efectos de tunel cuántico debido al cual una parte de la corriente eléctrica puede saltar de un circuito a otro a través de un aislante. En la animación es posible observar cómo la función de onda de un electrón traspasa una barrera de potencial. Cuando la barrera es grande la probabilidad de que el electrón salte es a efectos prácticos cero, pero a medida que se reduce el tamaño los saltos por túnel cuántico deben realmente empezar a ser tenidos en cuenta. Como es imposible evitar los efectos cuánticos lo que hacen los ordenadores cuánticos es tratar de sacar partido de ellos.

¿Qué es la computación cuántica?

No es posible entender el estado del arte de la tecnología de computación cuántica sin entender previamente qué es un sistema cuántico. Para quién esté interesado en los fundamentos matemáticos de la mecánica cuántica la mejor introducción que yo he encontrado es la de Susskind y Friedman. También hay sendos capítulos sobre física cuántica en la monumental obra de Penrose El Camino a la Realidad. El curso sobre computación cuántica más completo que he podido encontrar es el de Michael Loceff. Sobre probabilidades cuánticas el texto de Greg Kuperberg. Y la tesis de tesis doctoral de Mario Mastriani también es bastante didáctica.

Pero empecemos pues con los fundamentos de la computación cuántica.

En un ordenador convencional la información se representa como cadenas de bits 0 o 1. En cada instante del tiempo, el estado del ordenador lo describen en su totalidad los estados de sus bits. Por ejemplo, en un sistema de dos bits, el conjunto de todos los estados tiene 4 elementos y es {00, 01, 10, 11}. El sistema cambia de un estado a otro haciendo pasar los bits por puertas lógicas. Por ejemplo, una puerta es NAND cuyas entradas y salidas son las mostradas en la tabla. NAND es una puerta lógica universal mediante la cual se pueden construir las otras puertas lógicas de dos bits AND, OR, NOR, XOR, XNOR mediante combinaciones de puertas NAND.

En un ordenador cuántico la información se almacena en qubits. La diferencia entre un bit y un qubit es que el qubit puede encontrarse en un estado intermedio entre 0 y 1 con una probabilidad respectiva para cada valor que en conjunto deben sumar el 100%. Para distinguir los estados cuánticos de los clásicos los escribiremos como |0⟩ y |1⟩ Esta notación se conoce como vectores ket, pero no nos interesa entrar ahora en lo que son matemáticamente los ket. Una forma de imaginar el qubit es como un átomo con un electrón que tiene dos niveles de energía (estados) |0⟩ y |1⟩
Modelo atómico de un qubit

En cada instante del tiempo el átomo (qubit) se encuentra en una superposición de los estados |0⟩ y |1⟩ Sin embargo, cuando se realiza una medida el estado se colapsa a un valor 0 o 1. La evolución de los estados es un proceso totalmente determinista que se puede predecir, pero la información disponible al observador son sólo las probabilidades de encontrar el qubit representando |0⟩ o representando |1⟩ en cada momento.

En la ecuación del gráfico, además, los estados están separados por una fase denotada por la letra griega phi (φ) cuyos detalles no comentaremos aquí.
Según esto, la información que almacena un sistema cuántico es mucho mayor que la que almacena un sistema digital clásico, ya que no sólo contiene cero o uno sino una descripción de la probabilidad de que cada bit se encuentre en cero o uno al realizar una medida.
En sistemas de dos o más qubits, algunos qubits podrían formar un único sistema en lo que se conoce como entrelazamiento cuántico. Si este es el caso, entonces no es posible modificar el estado de un qubit sin alterar el estado de los otros qubits entrelazados.

Para un sistema con tres qubits los estados se representarían con un vector de 8 dimensiones:

a|000⟩ + b|001⟩ + c|010⟩ + d|011⟩ + e|100⟩ + f|101⟩ + g|110⟩ + h|111⟩

donde los coeficientes a…h son números complejos y la probabilidad de encontrar al sistema en cada estado es el cuadrado de la norma de cada coeficiente complejo |a|²…|h|² La norma de un número complejo z se escribe |z| y si z = x+yi entonces la norma |z| = √x²+y²

El sistema no puede evolucionar de forma arbitraria sino que la evolución debe mantener ciertas propiedades, la más importante que la suma de probabilidades |a|²+|b|²+…+|h|² debe ser siempre igual a 1.

El criterio de DiVincenzo

En el año 2000, David P. DiVincenzo publicó un trabajo breve pero muy citado titulado The Physical Implementation of Quantum Computation en el cual enumera cinco requisitos para que un ordenador pueda funcionar basándose en efectos cuánticos:

1. Capacidad para operar con un número fucientemente grande de qubits bien caracterizados.
2. Posibilidad de inicializar el estado de cada qubit con probabilidades arbitrarias de |0⟩ y |1⟩.
3. Tiempos de vida (decoherencia) de los qubits lo bastante largos.
4. Un conjunto «universal» de puertas lógicas cuánticas.
5. Posibilidad de medir el estado de cada qubit individualmente.

Desafíos técnicos que presentan los qubits

Todos los sistemas que tratan de explotar las propiedades cuánticas de los qubits se enfrentan a las dificultades enunciada por DiVincenzo.

En primer lugar es facilísimo que el estado cuántico de un conjunto de qubits se colapse a un valor determinado debido a un fenómeno conocido como decoherencia por el entorno que se produce debido a la más mínima perturbación térmica o magnética en el qubit. Actualmente, el estado del qubit sólo puede mantenerse durante unas pocas decenas de microsegundo. Además, cuantos más qubits entrelazados hay más dificil es prevenir la decoherencia. Algunos teóricos piensan que la decoherencia de un sistema cuántico se produce de forma inevitable por efecto de la gravedad. Si eso es cierto, siempre existirá un límite de tiempo no muy largo en el que se pueda mantener el estado de un qubit ya que no es posible aislar un sistema de la gravedad.

En segundo lugar no es posible leer el estado de un sistema cuántico sin dejar el sistema en un estado desconocido. Es decir, se puede saber en qué estado se encontraba el sistema antes de la lectura pero no se puede saber en qué estado habrá quedado después de ella. Esto implica que no se pueden fabricar puertas lógicas cuánticas igual que las convencionales porque, entre otras cosas no es posible clonar el estado de un qubit.

En tercer lugar existe un serio problema de detección y corrección de errores. La corriente utilizada en los qubits implementados con superconductores es del orden de 10 microvoltios con una diferencia de energía entre el estado |0⟩ o |1⟩ de 10^-24 julios. Esto es diez mil veces menor que el nivel de energia que separa un 0 de un 1 en un ordernador digital. Por consiguiente, en un ordenador cuántico es mucho más difícil distinguir un |0⟩ de un |1⟩ Pero es que para empeorar la situación aún más recordemos que los qubits sólo están en cada estado con una cierta probabilidad. No es posible en la práctica fabricar dos circuitos superconductores que representen qubits idénticos. Ante la misma señal de reseteo, cada qubit cambia a un estado con distribución de probabilidad entre |0⟩ y |1⟩ ligeramente diferente de los otros qubits. Mediante laboriosos procesos de calibración y manteniendo los qubits lo más aislados de perturbaciones térmicas y electromagnéticas se intenta que todos los qubits se comporten igual. Pero al cabo de una sucesión de operaciones siempre quedará alguna pequeña diferencia estadística en su comportamiento. Tanto es así que en el primer D-Wave instalado para Lockheed Martin sólo están operativos 108 de sus 128 qubits.

Como colofón al problema, recordemos que no es posible leer el estado de un qubit sin destruirlo, de modo que el sistema de corrección de errores debe funcionar prediciendo y corrigiendo errores que aún no se han producido. Una posibilidad es, por ejemplo, representar cada valor 0 o 1 con tres qubits que deberían ser |000⟩ bien |111⟩ Entonces es posible averiguar si el primer bit es igual al segundo. Esto no requiere medir el estado (lo cual lo destruiría) sino sólo la diferencia entre el primer bit, el segundo y el tercero que sí es posible sin destruir el estado. Pero como la comprobación de errores también está sujeta a las leyes cuánticas es posible que se produzcan errores durante el chequeo de errores. El mecanismo de detección y corrección de errores es pues bastante complicado y absolutamente necesario.

Algunos piensan que los ordenadores cuánticos basados en puertas lógicas nunca llegarán a funcionar debido que la tasa de errores debería estar en algún lugar entre uno entre diez mil y uno entre un millón de operaciones para que la corrección de errores fuese eficaz. Por otro lado, el teorema del umbral cuántico afirma que un computador cuántico puede emular a una clásico siempre y cuando la tasa de errores se mantenga por debajo de cierto umbral. Y puede encontrarse un esbozo de cómo funciona la correción de errores en los prototipos de IBM este artículo. Por último, investigadores de Google y UCSB también han publicado resultados sobre la corrección de errores en qubits.

Tecnologías para implementar qubits

Existen tres grandes líneas de investigación financiadas por grandes empresas: la de IBM, la de Microsoft y Bell Labs y la de D-Wave y Google. También se está desarrollando una intensa investigación teórica y práctica en universidades de todo el mundo.

Las tecnologías principales que están siendo investigadas por las grandes empresas para implementar qubits son:

• iones atrapados en campos electromagnéticos
• electrodos superconductores acoplados mediante uniones de Josephson (transmon)
• qubits topológicos mediante aniones no abelianos

Existen también otras líneas prometedoras de investigación como por ejemplo:

• qubits atrapados en imperfecciones diamantinas
• codificación de qubits en fotones

La línea de investigación más audaz es la de Microsoft Station Q que está apostando por qubits topológicos basados en unas hipotéticas partículas llamadas aniones no abelianos que no son ni fermiones ni bosones y que pueden llevar unidades fraccionarias de carga. Si existen, los aniones no abelianos podrían proporcionar una forma de crear qubits extraordinariamente más resistentes a errores que los basados en iones atrapados o microcorrientes. Pero es que además de existir los aniones (lo cual por ahora no está nada claro) debería ser factible moverlos por circuitos supercondutores dispuestos en forma de trenza.

Los Bell Labs también están investigando qubits topológicos contenidos en cristales ultrapuros de arseniuro de galio.

En el caso de ser realizables, los qubits topológicos aventajarían muy probablemente al resto de aproximaciones tecnológicas al ofrecer tiempos de decoherencia en dias en lugar de microsegundos y una tasa de errores varios órdenes de magnitud inferior.

D-Wave

Las únicas máquinas de computacion cuántica comercialmente disponibles por ahora, las D-Wave, usan anillos superconductores de niobio y uniones de Josephson para implementar los qubits. El estado |0⟩ o |1⟩ lo determina la dirección dextrógira o levógira de una microcorriente en el equivalente a un anillo superconductor.

Los retículos de proceso del D-Wave están compuestos de grupos de 8 qubits parcialmente acoplados entre ellos y con los qubits de otro grupo. Inicialmente el sistema se inicializa con cada qubit en una probabilidad 50%-50% de encontrarse como 0 o 1 al realizar una medida. A continuación se puede aplicar un sesgo (bias) a cada qubit para modificar su probabilidad de encontrarse en estado 0 o 1 al medirlo.

Los acopladores permiten definir entrelazamiento entre dos qubits. El efecto del entrelazamiento es asegurar que dos bits tienen bien el mismo valor al realizar una medida bien el valor contrario. Es decir, es posible especificar que si al qubit A devuelve valor 0 al ser medido entonces el qubit B también devuelve 0. O que si el qubit A devuelve 0 entonces el qubit B siempre devuelve 1.

D-Wave coupled qubits Los D-Wave no son computadores cuánticos universales y en particular no pueden ejecutar la parte cuántica del algoritmo de Shor. Los D-Wave no son programables como un ordenador convencional. Solo permiten especificar el valor del bias y los acoplamientos entre qubits mediante matrices en Python o C. Con estos valores se crea un «paisaje» en el que el D-Wave busca un mínimo usando el algoritmo de temple cuántico descrito más adelante. El estado evoluciona desde la incertidumbre total del valor de cada qbit hasta un 0 o 1 en cada qubit medido, que representa la solución al problema especificado (gráfico derecho).

La presunta aceleración cuántica de los D-Wave ha sido objeto de un intenso debate con posiciones desde la de Matthias Troyer y otros quienes afirman que no han encontrado evidencias de aceleración cuántica hasta tests de Google que afirman que el D-Wave es hasta 100 millones de veces más rápida que un ordenador convencional en la resolución de problemas cuidadosamente escogidos. Lo que si está claro es que nadie considera la D-Wave como una máquina que sea útil en solitario. El uso que el propio fabricante propone es usar un superordenador para preparar determinados problemas de optimización y delegar su resolución en el D-Wave.

Hay una docena de videos cortos y asequibles que explican cómo funciona el D-Wave publicados por el fabricante en su canal de Youtube.

Clase de complejidad BQP

Antes de entrar a estudiar algunos algoritmos, nos detendremos brevemente a comentar la computación cuántica desde el punto de vista de la teoría de complejidad computacional. Por ahora, parece que las aplicaciones de la computación cuántica serían abordar problemas que pertenecen a la clase de complejidad BQP (bounded error quantum polynomial time) que es el análogo cuántico de la clase BPP (bounded-error probabilistic polynomial time). Hay que recordar que todos los algoritmos cuánticos son probabilísticos, es decir, devuelven la solución correcta a un problema sólo con una cierta probabilidad, que puede ser lo bastante elevada y en todo caso mayor de un tercio en todas las ejecuciones del algoritmo. Se sabe que existen problemas BQP que probablemente no son P, es decir, que no pueden resolverse en un tiempo polinómico respecto del tamaño de los datos de entrada con un ordenador convencional pero sí con un ordenador cuántico. Algunos ejemplos son la factorización de enteros que comentaremos más adelante y encontrar el polinomio de Jones. La relación entre BQP y la clase NP (no polinómicos) es desconocida aunque se cree que los problemas NP Completos no pueden ser resueltos en tiempo polinómico por un algoritmo de clase BQP.

Algoritmos cuánticos

Hay en curso una discusión teórica y técnica acerca de si la computación cuántica debería basarse en un análogo programable de puertas lógicas digitales o en otra cosa completamente diferente. Los D-Wave, las únicas máquinas comercialmente disponibles que hoy por hoy pueden reclamar el derecho de usar efectos cuánticos en sus cómputos no usan puertas lógicas sino que implementan un algoritmo concreto conocido como temple cuántico el cual comentaremos más adelante.

No sé como explicar los algoritmos sin usar formalismos matemáticos propios de la mecánica cuántica. Por consiguiente, el lector alérgico a las ecuaciones posiblemente será mejor si deja el post aquí. Tampoco puedo explicar el archimencionado algoritmo de Shor que podría servir para romper la encriptación RSA y DSA sin explicar previamente la transformada cuántica de Fourier de la que depende.

La computación cuántica funciona aplicando una función que cambia un estado a través del tiempo. Esta función del tiempo se conoce como el Hamiltoniano (Ĥ) y lo que hace es evolucionar un estado inicial |ψ₀⟩ a un estado final Û(t)|ψ₀⟩ a través del operador unitario Û tal que dÛ/dt = iĤ(t)Û(t)/ħ.
Ĥ normalmente representa la energía total de un estado y es el programa a ejecutar en un computador cuántico.

Transformada cuántica de Fourier

La transformada cuántica de Fourier es el análogo de la transformada discreta de Fourier de la cual daremos una definición constructiva. Se comienza con una función continua e integrable definida dentro de un intervalo de tiempo. Normalmente con forma de crestas y valles del estilo de una señal de audio o de radio como la de la siguiente gráfica.

Primero se hace un muestreo de los valores de la función a intervalos regulares de tiempo. En la gráfica 11 muestreos por segundo. En un intervalo de 3 segundos total N=33 muestreos. Estos muestreos expresan los valores de la función en función del tiempo. Para cada instante del tiempo conocemos el valor de la función.

Funcion sinusoidal compuesta

Ahora lo que deseamos hacer es expresar la función en el dominio de la frecuencia y no del tiempo. Es decir, deseamos expresar nuestra función como la suma de funciones sinusoidales de diferentes periodos. Lo cual se puede demostrar que es posible pero no abordaremos las razones de por qué. Para expresar en el dominio de la frecuencia nuestra función calcularemos la correlación entre ella y cada una de las funciones seno y coseno con una cantidad de ciclos desde 0 hasta N (el número de muestreos) durante el intervalo de tiempo en el que se aplica la transformación.

Seno y coseno un periodo

Función Seno

Si x₀, x₁, … x_n son los valores de cada medida entonces la transformada discreta de Fourier es una serie de N números complejos X₀, … X_n definido cada uno de ellos como

Transformada discreta de Fourier

Teniendo en cuenta la fórmula de Euler según la cual
e^ix = cos(x) + i sen(x) y que sen(-x) = -sen(x)
cada término n-ésimo del sumatorio anterior se puede expresar también como
x_n (cos(2πkn/N) – i sen(2πkn/N))
expresión en la que se aprecia explícitamente cómo se correlacionan los valores muestreados con los valores de las funciones coseno y seno.

La evaluación directa de la fórmula anterior requiere N² multiplicaciones y N(N-1) adiciones lo que computacionalmente equivale a una cota superior asintótica O(N²).

Si el tamaño de la muestra es una potencia de dos, se puede emplear un algoritmo llamado Transformada Rápida de Fourier que reduce la cota superior asintótica a O(N log N).

Hasta aquí la parte clásica de la transformada discreta de Fourier. Veamos ahora la versión cuántica. Lo primero de todo hay que tener en cuenta que la transformada cuántica de Fourier se aplica sobre todo un estado cuántico y no sobre los valores de sus medidas. En el caso cuántico la transformada toma como entrada un vector de amplitudes y produce como salida otro vector de amplitudes.

Dado el estado

Estado cuántico

Su transformada quántica de Fourier se define cómo

Quantum Discrete Fourier Transform 1

donde

No se puede acelerar la transformada discreta de Fourier clásica mediante computación cuántica. Las razones son que no es posible establecer eficientemente una distribución inicial de amplitudes de probabilidad y que las amplitudes de probabilidad no son accesibles mediante medidas. Lo que podemos hacer es una medida sobre un estado y obtener |0⟩ o |1⟩ pero no es posible determinar mediante observación cual es la probabilidad de obtener |0⟩ o de obtener |1⟩ De modo que la transformada quántica de Fourier no es útil directamente sino sólo como parte de otros algoritmos que comentaremos más adelante.

Afortunadamente, existe una forma eficiente de obtener la transformada cuántica de Fourier mediante una combinación de puertas lógicas cuánticas llamadas puerta de Hadamard y puerta controlada de desplazamiento de fase. La puerta de Hadamard realiza la transformada discreta de Fourier sobre las amplitudes de probabilidad de un qubit. Para número de amplitudes que sea una potencia de dos N = 2ⁿ, la transformada cuántica de Fourier tiene una cota superior asintótica O (2ⁿ) la cual es exponencialmente más rápida que la transformada rápida de Fourier que es O(N log N) = O (2ⁿ log 2ⁿ) = O(2ⁿ n).

Estimación del periodo de una función

Supongamos que hay N dimensiones y un estado de la forma |Φ⟩ = Σ c|l+n r⟩ donde n=0…N/r-1 y |c| = √r/N. Esto se llama un estado periódico con periodo r y elemento compensatorio l. Al aplicar la transformada cuántica de Fourier a dicho estado se evolucionará a un nuevo estado |̃Φ⟩ = Σ α_m|mN/r⟩ con m=0…r-1 y |α_m|=√1/r para todo m. El nuevo estado también es periódico con elemento compensatorio cero cuya medida será un múltiplo de N/r. Esto se puede aprovechar para elaborar un algoritmo cuántico que encuentre el periodo basado en que si se aplica repetidamente la transformación se obtendrán resultados cuyo único factor cómún será el periodo.

Algoritmo de Shor

Algunos algoritmos criptográficos, y en particular RSA, se basan en la dificultad para encontrar los factores primos de un número entero grande (1024 bits o más). No se conoce ningún algoritmo capaz de factorizar un entero grande con una cota asintótica que sea polinómica respecto del tamaño del entero de entrada. El mejor algoritmo conocido para enteros grandes en la criba general del cuerpo de números cuya cota asintótica es exponencial.

El algoritmo de Shor lo que hace es descomponer la factorización de enteros en tres subproblemas: 1º) determinar si un número es primo o no, 2º) encontrar el mínimo común denominador y 3º) determinar el periodo de una función. Los dos primeros subproblemas se pueden resolver en tiempo polinómico con algoritmos clásicos y es en el tercero donde la transformada cuántica de Fourier marca la diferencia de complejidad asintótica utilizada en conjunción con el algoritmo clásico de expansión continua de fracciones.

El algoritmo de Shor no sirve para romper cualquier método criptográfico, sólo sirve para atacar los métodos basados en factorización de enteros como los sistemas clave pública. Los sistemas de cifrado simétrico o basados en funciones hash se consideran seguros frente a la computación cuántica.

Algoritmo de Grover

Lo que hace el algoritmo de Grover es equivalente a encontrar el valor de la variable x tal que para una función 𝑓 se verifique que 𝑓(x) = y. El algoritmo de Grover tiene una cota asintótica O(N^½) y requiere O(log N) espacio adicional durante su ejecución. Intuitivamente, es equivalente a buscar a quien pertenece un número de teléfono en un listado ordenado por nombre. Sin un índice, la única forma de buscar es comprobar uno por uno el número de cada abonado lo cual requirirá en el peor caso tantas comprobaciones como abonados haya en el listado.

El problema insalvable del algoritmo de Grover, desde mi punto de vista, es que para que funcione hay que precargar toda la base de datos en qubits. Dado lo que cuesta actualmente cada qubit, es dudoso que tengamos un número de qubits suficiente para aplicaciones prácticas y, aunque lo tuviéramos, habría que precargar la base de datos entera desde un sistema externo, lo cual equivale a leerla entera con un recorrido por fuerza bruta de complejidad O(N).

El algoritmo de Grover tampoco se considera eficaz para atacar sistemas clave simétrica invulnerables al algoritmo de Shor, debido a que para aumentar el tiempo requerido por la desencriptación basta con duplicar el tamaño de la clave.

Algoritmo de temple cuántico

El algoritmo de temple cuántico, también llamado cristalización o en inglés quantum annealing, sirve para resolver problemas de optimización o de muestreo. El problema consiste en encontrar el mínimo de una función. La versión clásica de este algoritmo, conocida como temple simulado, lo que hace es provocar alteraciones térmicas en los estados para verificar si atraviesan una barrera de potencial. El temple cuántico puede aprovechar, además el efecto túnel para cruzar barreras de potencial. Por consiguiente, el temple cuántico proporcionará más aceleración cuando el perfil de la función esté compuesto por mínimos en valles separados por crestas altas y estrechas. Una analogía ingeniosa del temple cuántico puede visualizarse en este video.

4 States Sampling Veamos ahora cómo ejecuta este algoritmo el D-Wave sobre el retículo de grupos de 8 qubits acoplados que hemos presentado anteriormente. El muestreo de la función es discreto. Supongamos que tenemos dos qubits. Entonces podemos representar 4 estados. La energía para cada estado se introduce en el bias. Lo que hace el algoritmo es buscar el mínimo de la función definida por los valores de energía. El último modelo de D-Wave tiene 1.000 qubits y, por consiguiente, puede trabajar con 2¹⁰⁰⁰ estados.

El algoritmo de temple cuántico hace uso de los principios de computación cuántica adiabática. En el D-Wave se define un Hamiltoniano de Ising que se compone de dos partes: una para inicializar el estado y otra que representa el problema a resolver.

Hamiltoniano de Ising

Por el teorema adiabático, el sistema representado por el Hamiltoniano de Ising evolucionará desde el estado representado por el primer término hasta el estado de mínima energía del segundo término, que es la solución al problema.

Actualizaciones:

D-Wave upgrade: How scientists are using the world’s most controversial quantum computer (Elizabeth Gibney)

Los ordenadores cuánticos están listos para salir del laboratorio en 2017 (Davide Castelvecchi)

¿Son los campeones realmente resilientes?

Publicado el 15 de septiembre de 2016 por Sergio Montoro

Una de las cosas que me intriga sobre la (auto)biografía de los campeones es que parece que ninguno de ellos hubiese tenido jamás ni el más mínimo atisbo de duda. Como si se hubieran levantado todos y cada uno de los días de su vida, con sol, viento, lluvia o nieve, para salir a correr en pos de su objetivo. Incluso en la biografía de Nelson Mandela –quien estuvo 27 años en prisión muchos de ellos en condiciones durísimas– da la impresión de que se comportase con la certeza de que un día saldría para tomarse la revancha.

Puede que esta combinación de infalibilidad más determinación sea la cualidad de los genios. Sin embargo, las personas que yo conozco personalmente no son así. Casi todas dan dos pasos hacia delante y uno hacia atrás. Se cansan, se deprimen (algunos psicólogos afirman que la depresión es un mecanismo defensivo para dejar de hacer cosas que no conducen a ninguna parte). Incluso a los emprendedores más exitosos y curtidos que me he encontrado me confesaron que les costaba llegar a su propio nivel. Tenían una vida más similar a la de esos artistas que lo mismo un año ganan un Oscar que al siguiente están en tratamiento de desintoxicación alcohólica. Voy a intentar enumerar lo que he podido aprender de algunos campeones, y cómo sobreviven a las tempestades con algo más que únicamente su propia determinación.

Sobreasignación

Uno de mis consejos favoritos y que más me divierte repetir es la Regla Nº1 del Gasto Militar: Nunca compres un tanque si puedes comprar dos por el doble de precio. Esto se puede aplicar a casi todo en la vida, si te lo puedes permitir, claro. Tener exceso de stock puede salvar a la empresa de una crisis en los proveedores o servir para aprovechar la oportunidad de un pico inesperado de demanda. También puede ser una forma de perder muchísimo dinero en obsolescencias.

Además de su coste, el inconveniente de la sobreasignación es que resulta difícil determinar el umbral de seguridad. La gente tiende a pensar que si el requerimiento normal es X entonces una sobreasignación prudente será 2X o 3X. Pero las sobreasignaciones eficaces con frecuencia son 10X o más. Los analistas de riesgo tienden a crear el «peor escenario» en función de la peor crisis conocida en el pasado. La falacia de esta hipótesis del «peor escenario» es que cada crisis pasada fue peor que la peor de las anteriores. Debido a esta creencia errónea de que el futuro nunca será peor que el pasado es por lo que revientan centrales nucleares como Chernobil y Fukushima.

La sobreasignación ya fue descrita por Tsung Tzu en su clásico Arte de la Guerra en lo que él denominaba «lento, lento, rápido, rápido». Prepararse a conciencia durante el tiempo que haga falta y luego atacar con la velocidad de un relámpago en el momento oportuno.

Anticoraje

El sistema de start ups funciona creando un gran número de ellas de las cuales tanto como el 80% o el 90% muere antes de alcanzar los cinco años de vida. Los inversores lo saben, y les da igual porque ellos juegan apostando sobre el resultado estadístico promedio y no sobre una única empresa. Pero para el emprendedor la media es irrelevante. Existe el mito de que los emprendedores son personas que asumen riesgos. Esto es una idea equivocada del emprendizaje. Los que asumen riesgos innecesarios sólo son estúpidos e imprudentes. Los mejores emprendedores trabajan eliminando riesgos. Empiezan con una situación de gran incertidumbre y trabajan sistemáticamente para reducirla.

Si uno lee los consejos de billonarios con Warren Buffet es fácil encontrar entre los primeros consejos que antes de pensar en cómo ganar dinero hay que pensar en cómo no perderlo. La táctica habitual de los inversores es colocar el 80% de su capital en activos de muy bajo riesgo y el otro 20% en activos de muy alto riesgo. De esta forma si pierden nunca pierden más del 80% pero si ganan entonces obtienen grandes beneficios. La pega es que si todo el mundo hace lo mismo, los activos de bajo riesgo dejan de ser tales por la cantidad brutal de deuda a quienes los emite, y los juegos de azar con nuevos proyectos adquiren una probabilidad ínfima de ganancia. De hecho, la estrategia exitosa de Warren Buffet no fue esta del 80%-20% sino apostar fuerte y a medio-largo plazo por activos conyunturalmente devaluados.

Blindaje

El blindaje está relacionado con la sobreasignación y con el anticoraje, pero se extiende más allá de los recursos económicos o la evaluación de riesgos. Consiste en una protección a priori contra algo de lo que, en principio, no parece necesario protegerse. El blindaje sólo es eficaz si se instaló antes de que se produjese la catástrofe y la parte contraria desconoce su existencia pues en otro caso pensará en la forma de perforarlo.

La protección que más a menudo olvidan los emprendedores es aquella contra sus propios socios. Este blindaje es complicado porque requiere generar una situación de confianza que en realidad no existe. Sin confianza entre los socios no se puede llevar adelante un negocio, pero con confianza ciega tampoco por el hecho de la antireputación que comentaré más adelante.

Pocas si acaso alguna start up se constituye con un plan de contingencia para el caso en que la empresa quiebre. Lo cual es estúpido y temerario si se tiene en cuenta que estadísticamente el resultado más probable de una start up es el cierre por insolvencia.

Compartimentalización

La compartimentalización es una forma de blindaje. Consiste separar partes del sistema de modo que una catastrofe en una no destruya las demás. Esto casi nunca es sencillo de conseguir y las ideas modernas sobre la conciliación no ayudan en nada. Es complicadísimo competir por una medalla olímpica sin poner en serio riesgo la salud, pretender ser elegido presidente sin que sufra la vida familiar, obtener un préstamo sin tener que avalarlo personalmente o subir al Everest sin riesgo de morir por cansancio e hipotermia. La compartimentalización es uno de los desafíos más difíciles del campeón. Al actor Will Smith se lo escuché una vez enunciado como: «Si eres de esas personas que luchan por el 99% eso está bien, quédate en casa y sé feliz». Muchos emprendedores no compartimentalizan, sólo queman sus naves como Hernán Cortés en el deseo de triunfar o morir en el intento. Esta falta de prudencia no es muestra de ninguna sabiduría especial. Los que sobreviven lo hacen sólo por pura suerte lo mismo que no todos los que en una batalla corren colina arriba en dirección a las ametralladoras mueren a causa de la balacera, sino que en cantidades numerables con los dedos de una mano vuelven para recibir una medalla y quizá un monumento a su insensatez en la plaza de su pueblo.

Antirreputación

Si te preocupa lo que la gente piense de ti es mejor que no te metas a político ni a emprendedor. Algunas profesiones como médico, juez o militar no admiten pérdidas de reputación. Por eso ni médicos ni jueces ni militares van por libre sino que están estrictamente regulados. Pero no es el caso de los emprendedores. Obama trató recientemente de descalificar a Donald Trump argumentando que conocía muchos empresarios tan exitosos como él, pero que no habían dejado a su paso un reguero de despidos, impagos y gente cabreada. Pues bien, es imposible ser emprendedor de éxito sin cabrear a alguien. Por dos motivos: 1º) un porcentaje significativo de las victorias se obtienen tras una acción audaz (y a veces no muy limpia) contra el adversario, y 2ª) una buena forma de construir un sistema resistente es con piezas débiles pero redundantes y reemplazables. Esto se aplica lo mismo a un centro de datos que opera sobre discos baratos que a una empresa que opera sobre mano de obra barata, excepto que las personas tienen derechos y sensibilidades bien diferentes a los de los discos. Hasta la fecha no ha funcionado en la práctica ningún sistema social basado en que nadie pueda fallar y quedarse por el camino. Existe una creciente preocupación por la solidaridad y la cohesión social pero a la postre cualquiera es prescindible.

Por otra parte, para tener éxito en muchas ocasiones el número de detractores no cuenta. Importa mucho más tener un pequeño grupo de seguidores fanáticos (Jesucristo tenía al principio sólo 12). Si los fanáticos son lo bastante activos e influyentes persuadirán a la masa indiferente y los destrozos denunciados por los detractores se verán eclipsados a los ojos de la mayoría.

Hasta las mejores causas tienen grupos opositores como el de los Trabajadores Inocentes que Murieron en el Ataque a la Estrella de la Muerte. Y diré más, en los negocios cuanto mayor es la reputación de una persona menos hay que fiarse de ella, pues sobre las personas de reputación incuestionable se relajan los controles que serían necesarios hasta tal punto que cuando la sociedad se da cuenta del desastre que han causado ya es demasiado tarde para arreglarlo.

Adrenaholismo

En psicología se sabe que una persona puede volverse adicta a casi cualquier cosa. Muchos emprendedores son adictos a la adrenalina y al cortisol hasta el punto de que no saben qué hacer con sus vidas cuando están relajados. Oficialmente sueñan con retirarse y descansar pero en la práctica no dejan de meterse en un lio detrás de otro. Personalmente creo que algunas personas tienen una resistencia natural extraordinaria a determinadas substancias. Puede que soporten la adrenalina o los esteroides de una forma que les permite obtener una ventaja competitiva sobre quienes simplemente no pueden tolerar dosis elevadas de dichos estimulantes en su sangre.

No hay que confundir la adicción a la adrenalina con la addición a trabajo. Muchas personas adictas al trabajo lo son precisamente por la causa contraria: a duras penas soportan su vida fuera del entorno laboral. Estas personas adictas al trabajo pueden ser buenos trabajadores y profesionales de éxito pero rara vez triunfan como emprendedores.

Sobrecompensación

El ejemplo más fácil sobrecompensación es el fisioculturismo. Los profesionales no entrenan 8 o 10 horas al día. Esto agotaría al organismo. Lo que hacen es entrenar con una intensidad brutal durante cortos periodos de tiempo y luego le dan al cuerpo gran cantidad de tiempo y comida para recuperarse. El truco consiste en evitar la exposición prolongada al desgaste de manera que sea posible acumular energía para vencer de forma rápida y demoledora a los que están más cansados, cuando se presente la ocasión.

Simetría de pérdidas y ganancias

Es indeseable para el individuo una situación en la que tiene potencialmente mucho que perder pero poco que ganar. Paradójicamente este puede ser el caso de los muy ricos, los cuales a duras penas pueden enriquecerse más, pero podrían arruinarse en cualquier momento y esa idea imaginaria que les causa un stress insoportable. Fue por esto que Séneca –uno de mis filósofos favoritos– abogó por el estoicismo a pesar de ser él mismo una de las personas más ricas e influyentes del Imperio Romano de su tiempo. La solución es deshacerse de aquello que le hace a uno dependiente lo cual puede ser la propia riqueza de la que se ha caído prisionero. Es por esto que muchos multimillonarios se han desecho de buena parte de su fortuna después de obtenerla, aunque sinceramente todavía estoy esperando encontrar alguno que haya regalado el Ferrari.

Fé

Una de las características de la juventud es que en un momento dado de ella uno sufre una epifanía y cree saber hacia dónde se dirige. En realidad el iluminado no tiene ni puñetera idea pero da igual porque los que le siguen tampoco. Cristobal Colón creía que iba a llegar a la India. E igual que Colón casi todo el mundo llega a alguna parte pero casi nadie a donde pensaba que iba a llegar. Se dispara entonces un proceso de revisión crítica en el cual uno se percata de dos hechos irrefutables: 1º) cualquier conocimiento que se crea tener es sólo una burda aproximación a la realidad y 2º) el resto de los presunto expertos tampoco tienen ni putidea de lo que se traen entre manos. Con frecuencia esto se produce tras un merecido batacazo en el cual el galardonado director de cine, por poner un ejemplo, obtiene financiación para hacer la que será su obra cumbre pero con la que en los cines no consigue tras el estreno ni recuperar los costes de producción. Entonces, y sólo entonces, es cuando empieza a cuestionarse si realmente sabe algo acerca de lo que le interesa a la audiencia. La pérdida de fé consecuencia del aumento del conocimiento es extraordinariamente nociva para el emprendizaje, ya que, como hemos enunciado anteriormente, el funcionamiento del sistema depende de la inconsciencia del peligro entre los individuos jóvenes y aguerridos.

Conclusiones

Mi opinión personal es que la capacidad para mantener una trayectoria exitosa está más relacionada con la habilidad para alejarse de lo nocivo y acumular fuerzas que con la capacidad de esforzarse y superar adversidades. Se trata de conservar en todo momento la iniciativa bélica. De luchar siempre por conquistar algo y nunca por preservar algo conquistado. Incluso si se acaba en prisión, como Mandela, usar esta circunstancia como arma arrojadiza contra el enemigo, acusándole de tirano y abusón, aunque la pena de cárcel haya sido por cargos de terrorismo y conspiración para derrocar al Estado.

Creo que algunos campeones empezaron con buen pie y luego tuvieron suerte. Lo bueno de los éxitos empresariales es que sólo necesitas un grán éxito para poder vivir de sus réditos el resto de tus días. Luego puedes fallar todas las veces que quieras.

De lo que no conozco tantos casos es de personas que lo volviesen a intentar tras fallar miserablemente en su primer intento. Existen excepciones, por supuesto, hay notables hunde-empresas en serie. Personas que quebraron una empresa (normalemente con el dinero de un tercero) y luego otra, y otra, y otra… por aquello de que de los fracasos se aprende, entonces la próxima será la vencida, y así sería de no ser porque son personas que no aprenden sino que simplemente superan el fracaso con indolencia debido a una percepción distorsionada de la realidad que les permite atribuir la culpa siempre a algo o alguien diferente de sí mismos.

Mi argumento es que la victoria es una espiral hacia arriba y la derrota es una espiral hacia abajo y lo único que importa es la tendencia al alza o a la baja.

La resistencia sí que importa pero no tanto porque los individuos se fortalezcan por sobrecompensación con lo que no les mata sino porque los más débiles se quedan por el camino y al final sólo llega uno que es quien fué más hábil en administrar sus energías sin derrocharlas en empresas estériles.

Posts relacionados:

Combatiendo a tus dragones.
Pírricas Victorias Empresariales.
Saṃsāra corporativo y stress del emprendedor.

Publicado en Emprendizaje | Deja un comentario

Los adolescentes en las redes sociales

Publicado el 11 de septiembre de 2016 por Sergio Montoro

Adolescentes en redes sociales Existen no pocos padres preocupados por las relaciones de sus hijos a través de las redes sociales. Frente a mi casa hay un bonito parque con varios rincones secretos encantadores. Bueno, secretos excepto cuando miras desde mi ventana en un tercer piso. Entonces puedes ver a los adolescentes allí haciendo todas las cosas que sus padres no quieren que hagan. Existen adolescentes que no soportan relacionarse en persona con el mundo. Pero la mayoría de los adolescentes prefieren verse en persona, como los de mi parque. Si están a las once de la noche enganchados al móvil es sólo porque sus padres les obligaron a volver a casa a las diez. Las motivaciones humanas no cambian con la introducción de nuevas tecnologías, sólo encuentran nuevas formas de satisfacerse.

Segun los estudios, algo así como el 72% de los adolescentes tienen cuenta en Facebook. Entre un 40% y un 50% usan Snapchat. Las cifras para Twiter varían mucho según la fuente, entre un 8% y un 33%. Y la cifra de 33% para Google+ no me la creo, excepto porque como efecto secundario de abrir una cuenta en GMail Google puede abrirte un perfil en Google+.

Nativos (e inexpertos) digitales

No hay que caer en el error de presuponer que porque un jóven haya nacido con un smartphone debajo del brazo automáticamente sabrá cómo hacer un uso mejor de él que un adulto. Debido a la vertiginosa velocidad del progreso, las nuevas tecnologías siempre preceden a las buenas prácticas de uso de las mismas. Un adolescente con un móvil sigue siendo igual de ingénuo y vulnerable que si móvil y puede perfectamente cometer el error de hacer un uso pésimo de la tecnología a su alcance.

Contexto y audiencia

Una de los primeros desafíos a los que se enfrentan los adolescentes en las redes sociales es la falta de visibilidad sobre la audiencia a la que se están dirigiendo. Si están en el parque pueden fácilmente cambiar de conversación –o apagar la yerba– cuando ven de lejos acercarse a un adulto. Pero en las redes sociales nunca pueden estar seguros de quién les estará leyendo, y los adolescentes casi siempre se traen algo entre manos de lo que no quieren que los adultos se enteren. Este es uno de los motivos –hay más– por el cual los críticos de Facebook dicen que está perdiendo tracción entre los adolescentes y por el cual Facebook trató de comprar Snapchat por 3.000 millones de dólares en noviembre de 2013 para captar a los millennials.

El problema de la audiencia no afecta sólo a los adolescentes, por supuesto. A los adultos también les afecta. A pesar de que Mark Zuckerberg declarase que Facebook quiere ayudar a sus usuarios a quitarse la máscara, la realidad es que la red social decide por su cuenta qué contenidos mostrar a cada usuario y censura lo que le aparece oportuno; incluyendo, por ejemplo, unos pechos femeninos, es decir, si te va el top-less playero y compartir fotos con tus amigos naturistas o hacerte fotos con una copa de vino en la mano, entonces Facebook no es para ti.

El desdoblamiento de personalidad digital es un problema no resuelto en las redes sociales. Existe, en mi opinión, una obsesión excesiva en las redes sociales por desvelar la identidad real del usuario. Esto es hasta cierto punto comprensible por razones de seguridad. Es razonable que debido a que la red social y el usuario firman un contrato de uso, ese contrato sólo puede ser válido si es posible identificar a ambas partes. Lo que no se sigue de forma inmediata es por qué la red debería informar al resto de los usuarios sobre la identidad real de cada uno. No es necesariamente malo que las personas usen avatares. Tampoco implica que tengas una personalidad múltiple. Una persona puede tener cuenta en Facebook y en LinkedIn y en Twitter y en Instagram y mostrará en cada una aspectos diferentes de si misma. También podría tener más cuentas en redes donde pueda expresar su fervor religioso o su orientación sexual sin ofender a ningún idiota. Algunas personas necesitan escapar temporalmente de la realidad porque dicha realidad es verdaderamente asfixiante. En estos casos los avatares pueden tener un uso terapéutico permitiendo a la persona acercarse libremente a lo que quiere ser.

Gamers y espacios propios

Merecen una mención aparte las interacciones sociales que se producen entre los jugadores de videojuegos (gamers) especialmente los MMOG (Massively Multiplayer Online Game). Cuando la gente habla de redes sociales piensa en Facebook o en Twitter, pero en los MMOGs también se produce una intensa interacción social. No todos los jugadores de videojuegos son en absoluto el arquetipo de muchacho gordito y tímido, hay hombres y mujeres de todas las edades y tipos. Tampoco es cierto que siempre diseñen avatares diferentes de ellos mismos. En ocasiones el avatar no tiene nada que ver con el usuario pero algunos jugadores diseñan avatares que son lo más parecidos a como son ellos mismos en la realidad. Una característica diferencial de los MMOGs es la forma en la que permiten crear un espacio propio. En Facebook los usuarios están avocados a interactuar con personas que conoces de acuerdo a las normas de su comunidad. En Twitter pueden buscar grupos de interés no locales e interactuar por afinidad cultural en lugar de por proximidad. Pero en un MMOG las posibilidades de alterar el entorno y crear una dinámica grupal propia son prácticamente ilimitadas. Las interacciones entre los jugadores pueden llegar a ser muy complejas requiriendo colaboración múltiples para pelear o alcanzar determinados objetivos. Los MMOG tampién pueden propiciar la convocatoria de encuentros presenciales. Según un estudio de Nicholas Yee el 15% de los varones y el 5% de las féminas quedan en alguna ocasión para conocerse en persona lo cual a mi me parece un porcentaje elevado teniendo en cuenta que no existe limitación geográfica, en principio, para la residencia del jugador.

Intimidad

La disponibilidad de nuevas tecnologías desde edad muy temprana ha causado que para los adolescentes sea natural hablar de temas íntimos a través del chat. Los adultos piensan que los temas delicados hay que tratarlos siempre en persona –si son muy delicados de hecho no sólo en persona sino en una sauna todos en pelota picada para que nadie lleve micros–. Pero los adolescentes perciben que el smartphone es un medio más para comunicarse como otro cualquiera, y de ahí el éxito de las conversaciones de Snapchat que se autodestruyen tras ser leídas.

Uso pervasivo del móvil

Una diferencia entre adultos y adolescentes es que esto últimos han crecido con el móvil. Para ellos atenderlo es algo tan natural escuchar la radio mientras cocinas, es decir, con frecuencia no le están realmente prestando demasiada atención. Esto contrasta con el uso típico que le dan los adultos quienes bien están absortos con el celular bien lo tienen boca abajo en la mesa con el timbre en modo silencio. Para los adolescentes es normal ver un partido mientras chatean.

Necesidad de aceptación social

El objetivo social de los adolescentes casi siempre es parecer «molones» en el entorno adecuado. Era así en los bailes de fin de curso de antaño donde para las chicas era cuestión de vida o muerte llevar el vestido adecuado. Y sigue siendo exactamente lo mismo en las redes sociales. Todo va de «molar», ser cool, tener flow.

Esta necesidad de aceptación se manifiesta en dos interacciones fundamentales en las redes sociales: quien hace clic en 👍 Me Gusta y quien escribe comentarios. Entre los adolescentes la competición por ver quién obtiene más Likes y, por consiguiente, es más molón, puede acarrear una presión insoportable para los menos populares, especialmente entre las chicas. Respecto de los comentarios, en general, a ningún usuario le gusta descubrir que le ha leído alguien que no esperaba y, además, ha puesto un comentario que va en contra de su opinión o resulta vergonzante. Pero si además la redactora del comentario es la hermana mayor o la madre eso puede suponer para el adolescente la muerte por vergüenza y cabreo por falta de netiqueta. En general, lo que a nadie le gusta en las redes sociales es perder el control de una conversación que ha iniciado, lo cual es fácil si existe un grupo organizado de bullies.

Privacidad

La privacidad de los adolescetes require de un compromiso prácticamente inalcanzable. Por una parte todos, absolutamente todos los adolescentes quieren privacidad. Aunque no estén haciendo nada malo, a ninguno le gusta que los adultos metan las narices en sus asuntos. Por otra parte los tutores tienen no sólo el derecho sino también la obligación de estar al corriente de lo que están haciendo los menores de edad en tanto en cuanto son responsables legalmente de ellos.

Otro asunto peliagudo es el relacionado con publicar fotografías de menores sin su consentimiento. Personalmente opino que lo mejor es no publicar nunca fotografías de terceras personas en Facebook. Para compartir fotos hay sitios mejores como Flickr donde se pueden designar personas autorizadas y compartir sólo con ellas las imágenes.

Cyberbullying

El bullying es uno de los aspectos más controvertidos y creo que al mismo tiempo peor entendidos de las relaciones sociales en niños y adolescentes. No existe un acuerdo total acerca de lo que es bullying pero, en general, se acepta que se da cuando en una dinámica confluyen tres factores: agresión, repetición y desequilibrio de poder físico o psicológico.

Recientemente, algunos estudios han mostrado que el cyberbulling es un fenómeno mucho más frecuente entre chicas. Con un 70% de víctimas acosadas por otras chicas. Mientras que en el bullying físico sólo el 47% de las víctimas son mujeres.

El bullying frecuentemente no es considerado con la suficiente seriedad por el claustro y la dirección de muchos colegios. O a veces todo lo contrario, en una política de tolerancia cero se vuelven todos locos si se produce un caso. Además, yo personalmente opino que la teoría moderna de la víctima, el agresor y los testigos es incompleta y probablemente incluso inapropiada como remedio. Según esta teoría (que algunos afirman que tiene resultados milagrosos) la clave para erradicar el bullying consiste en hacer a los espectadores conscientes de su contribución pasiva a la agresión y, una vez que se han dado cuenta, moverles a actuar en grupo para prevenir ataques del agresor. Esta teoría falla por tres lados: 1º) no explica nada acerca de las causas originarias de la agresión, 2º) da por sentado que la agresión es de un individuo a otro cuando de hecho puede que todo el grupo sea el agresor, y 3º) pone sobre un grupo de niños o adolescentes el peso de una responsabilidad preventiva que posiblemente no estén preparados para asumir.

Las políticas de uso de las redes sociales no tienen medidas específicas contra el bullying. Las sugerencias contra el acoso de Facebook básicamente dicen que si alguien te está atacando bloquees su cuenta y ocultes sus actualizaciones. Pero ¡rayos! si eres un adolescente ¿qué haces? ¿ocultas a toda tu clase y te das de baja de la red? Según los community standards también es posible denunciar al agresor y su comportamiento «no será tolerado», aunque no me queda claro qué implica «no tolerar» más allá de borrar algún comentario o foto.

Las causas del bullying suelen encontrarse en problemas familiares en la casa del agresor, stress, afán de poder, personalidad desordenada, complejo de superioridad o simple placer sádico en el caso de que el bully sea un sociópata, pero la gran mayoría de los bullies no son sociópatas sino las primeras víctimas de sí mismos. Además, el agresor es sólo uno de los implicados, el otro es la víctima quien también puede tener su propio conjunto de problemas que la hagan vulnerable a los ataques: inseguridad, vergüenza, segregación racial, limitaciones físicas, etc. Si no se actua sobre estas causas originarias del bullying entonces el cambio en la dinámica grupal es sólo un remedio sintomático.

El bullying tampoco es sólo un niño quitándole el bocadillo a otro todos los días en el patio. Muy frecuentemente toma la forma de rumores, risitas encubiertas, motes y comentarios jocosos sobre el acosado en los que participa una pandilla entera. Las personas, jóvenes y adultos, se envalentonan y se vuelven más agresivas en masa, entonces el bullying se produce por una dinámica de grupo y no por acción aislada de un individuo. En algunas ocasiones el acosado incluso puede asumir el papel de payaso del grupo y aceptar las vejaciones porque eso le proporciona cierta forma de protagonismo.

Las redes sociales implican, no obstante, buenas noticias para los defensores de la teoría de la víctima el agresor y los espectadores. En la red lo que ha sucedido es visible y perdura. Por consiguiente, fijar los hechos y mostrar lo que ha pasado es más fácil que tras una agresión verbal de la que no ha quedado ninguna constancia fidedigna excepto por las versiones diversas de los testigos.

Drama

Una peculiaridad de los adolescentes que rara vez se da entre los adultos –o al menos yo no la he encontrado en primera persona– es el drama. Los adolescentes pueden organizar una representación dramática para llamar la atención y obtener popularidad.

Peligros online

Por último, me he dejado premeditadamente en el tintero y no quiero entrar a comentar el tema de los peligros online: pederastas, timadores, ladrones, etc. Cualquier sociedad es más peligrosa de lo que debería y el ciberespacio no es diferente. «Cómo protegerse online» podría ser el título de otro post entero además de que no me queda claro si hay sólo que proteger a los adolesentes o también protegerse de ellos.

Posts relacionados:

Cómo y porqué la gente se vuelve adicta al móvil.
Cómo Internet modifica nuestras capacidades intelectuales y sociales.
Sobre la dinámica social en los sitios de dating.

Publicado en Usos sociales de la tecnología | 3 comentarios

Cómo sacar partido al stack big data de Apache

Publicado el 10 de septiembre de 2016 por Sergio Montoro

Hubo un tiempo en que todos los proyectos de la Fundación Apache podían encontrarse listados en su página de inicio. Hoy en día los proyectos 172 que hay en el directorio ya no les caben en la home y se encuentran listados en una página aparte. Hay tantos proyectos que es difícil aclararse, incluso siendo programador. Además los nombres de los proyectos no es que ayuden precisamente a identificarlos (Hadoop es el nombre del elefante de goma que tenía el hijo de su creador). En este post voy a comentar de forma asequible para el lector no técnico los principales productos de Apache relacionados con Big Data. No voy a entrar en generalidades conceptuales sobre Big Data, las cuales daré por sentadas o en caso contrario recomiendo el libro Big Intelligence de Antonio Miranda.

Esquemas de datos, consistencia y disponibilidad

Antes entrar en productos y tecnologías, no obstante, sí quiero hacer hincapié acerca de una diferencia fundamental entre las tecnologías relacionales clásicas y el enfoque de Big Data. Esta diferencia es si se graban los datos contra un esquema de datos ya existente (como el de una base de datos relacional) o si los datos entrantes no deben forzosamente adaptarse a priori a ningún esquema predefinido ni cumplir restricciones de integridad referencial. Cuando se impone que los datos entrantes cumplan las restricciones de un esquema se introduce una penalización en el tiempo necesario para grabarlos y, potencialmente, también una gran cantidad de bloqueos en las tablas de datos. Las operaciones de chequeo llegan a ser demasiado costosas para un sistema que recibe una enorme cantidad de datos entrantes y, por consiguiente, la solución de Big Data es simplemente diferir las comprobaciones y la normalización de datos. Adicionalmente, otra ventaja de trabajar sin esquema previo es que todos los datos entrantes se graban sin modificar a bajo coste y a largo plazo lo cual permite crear nuevas formas de explotación en caso de ser necesarias en el futuro.

El otro gran desafío de las arquitecturas distribuidas es el enunciado por el Teorema CAP que establece que en un sistema distribuido no es posible garantizar la consistencia, la disponibilidad y la tolerancia al particionado simultáneamente. Aunque existen vias de escape si se prohibe actualizar o borrar cualquier dato una vez grabado. Varios productos Big Data funcionan de hecho con esa restricción permitiendo crear nuevas versiones de una fila en una tabla o de un documento pero nunca modificar ni borrar una fila o documento anterior.

Tipos de datos que hay que almacenar y explotar

En casi cualquier aplicación de negocio o científica hay ocho tipos de datos que precisan ser almacenados y explotados. Cada uno de estos tipos de datos tiene características especiales que requieren diferentes tecnologías de almacenamiento, recuperación y explotación.

1. Imágenes y documentos (electrónicos o escaneados).

Las imágenes y documentos pueden ser muy grandes pero poco o nada se sabe normalmente acerca de su contenido. Se almacenan bien en sistemas clave-valor estilo Amazon S3 o Berkeley DB, bien en gestores documentales especializados como Jackrabbit. Para la búsqueda de imágenes y documentos en un sistema clave-valor es posible emplear un indexador “full-text” separado como Solr (la versión distribuida de Lucene). Solr tiene adaptadores que le permiten leer e indexar directamente OpenDocument y muchos otros formatos.

2. Formularios.

Los formularios son lo que los usuarios rellenan en pantalla cuando quieren registrarse en un sitio web, realizar una solicitud o publicar en Facebook. Lo que caracteriza a los formularios es que puede haber muchos diferentes que además cambian con el tiempo. Y no está para nada garantizado que los usuarios vayan a introducir información de calidad (hasta 68 formas diferentes de declarar la nacionalidad española he encontrado yo en una columna de una base de datos procedente de un campo de texto libre en un formulario). Las aplicaciones que manejan procesos por etapas casi siempre necesitan almacenar formularios a veces compartidos por distintos usuarios si se trata de procesos de negocio. Los formularios no son, en general, adecuados para una explotación directa. Por ejemplo, supongamos que se trata de un proceso de registro en una web de comercio electrónico. En el formulario de alta se le pedirán al cliente sus datos personales y una dirección de envío, todo ello en la misma pantalla. Sin embargo, la base de datos necesita almacenar los datos personales por un lado y la dirección por otro, ya que la dirección podría cambiar en el futuro y, por consiguiente, es preciso mantener un histórico de direcciones. El producto de Apache más adecuado para almacenar formularios es CouchDB. Se trata de una base de datos sin esquema que almacena documentos en formato JSON. Bueno, en realidad cada documento incluye su propio esquema (derivado de los campos JSON). CouchDB es NoSQL con replicación multimaster e interfaz CRUD a través de HTTP. Es decir, es fácil comunicarse con CouchDB desde Javascript mandando y recibiendo objetos JSON a través de HTTP. CouchDB está escrito en Erlang, lo cual no tiene absolutamente nada de malo, pero, como no es una elección habitual para el lenguaje base, también hay otra implementación 100% JavaScript que puede correr sobre Node.js

3. Entidades.

Las entidades son con lo que trabajan las bases de datos relacionales clásicas: persona, compañía, empleado, dirección, etc. Las entidades se almacenan en tablas y, para ser eficaces, deben evitar la duplicidad de datos (esto se conoce como normalización) y mantener integridad referencial entre ellas (la provincia en una dirección debe existir en una tabla de provincias y pertenecer al pais elegido). En Apache se puede encontrar una base datos relacional llamada Derby, pero es sólo para sistemas empotrados con baja huella de memoria o fines de testeo. Casi todo el mundo usa MySQL o PostgreSQL como base de datos relacional en producción.

Merece la pena hacer una mención aparte para las entidades que representan productos de un catálogo pues son un caso muy particular debido a que cada producto puede tener un conjunto de muy atributos diferentes, por ejemplo una cámara digital versus un jersey. Además, para cada producto puede haber variantes en tallas y colores. Hay básicamente cuatro posibilidades para almacenar los atributos de los productos: 1ª) se pueden almacenar en una tabla relacional atributo-valor (lo cual es ineficiente), 2ª) se pueden almacenar en una base de datos orientada a columna (de las cuales hablaremos luego), 3ª) se pueden almacenar en un campo BLOB o CLOB de la base de datos relacional, o quizá algo más sofisticado como un HStore de PostgreSQL, 4ª) se puede usar una base de datos sin esquema como CouchDB y permitir que cada producto lleve su propio conjunto de atributos.

Otro caso de uso muy típico es el almacenamiento de entidades con relaciones jerárquicas (donde una entidad contiene otras). Este desafío técnico a mi me parece curioso porque aunque las primeras bases de datos empezaron siendo jerárquicas, como IMS, el modelo relacional simplemente no es adecuado directamente para almacenar jerarquías. Los dos métodos comunes para almacenar jerarquías en bases de datos relacionales son la lista de adyacencia y los conjuntos anidados en cuyos detalles técnicos no voy a entrar pero puede encontrarse una buena explicación aquí. Debido a que los árboles son un tipo de grafo, es posible utilizar eficientemente una base de datos de grafos para almacenar jerarquías, lo cual veremos a continuación.

4. Grafos.

Almacenar un grafo en una base de datos relacional no es realmente nada difícil. Solo se necesita una tabla de nodos y otra de vértices. En SQL para un grafo dirigido :

CREATE TABLE nodos ( id INTEGER, CONTRAINT pk_nodos PRIMERY KEY(id) )

CREATE TABLE vertices ( id_nodo_inicio INTEGER, id_nodo_fin INTEGER )

El problema de esta implementación es que para obtener la lista de nodos sucesores de uno dado hay que hacer:

SELECT id_nodo_fin FROM vertices WHERE id_nodo_inicio=?

Lo cual parece trivial pero hay que tener en cuenta que incluso estando la tabla vertices bien indizada esta consulta se ejecutará en un tiempo que será log(n) siendo n el número de filas en la tabla vertices. Entonces si el grafo es grande se sobrecargará rápidamente la base de datos.

Lo que hace esencialmente una base de datos orientada de grafos es almacenar los sucesores de cada nodo pegados al propio nodo de manera que el tiempo de recuperación de los sucesores de un nodo permanezca siempre constante independientemente del crecimiento en tamaño del grafo.

Puede ser conveniente separar el almacenamiento de la explotación de grafos. Una posibilidad es almacenar los grafos en tablas como las ejemplificadas y precargarlos enteros en memoria para explotarlos. Esto es lo que hace Apache Giraph. Los nodos y vértices se almacenan en Hadoop pero el grafo se carga en la memoria de los nodos de un cluster. El modelo de programación de Giraph sigue el Pregel de Google. Giraph es la herramienta que Facebook utiliza para analizar el grafo de sus usuarios.

Titan, otra herramienta de procesamiento de grafos, no es de Apache pero hace uso de Cassandra o de HBase para almacenar los grafos. La diferencia práctica con Giraph es que Giraph está más orientado a OLAP y Titan a OLTP.

Además de los sistemas de almacenamiento, en Apache se pueden encontrar otros dos toolkits con algoritmos sobre grafos: Tinkerpop y Spark GraphX.

5. Series temporales.

Las series temporales expresan como cambia una variable función del tiempo. Un ejemplo sencillo son las predicciones meteorológicas por localidad. La primera dificultad para almacenar y tratar series temporales es que el modelo entidad-relación no incluye ninguna noción de temporalidad. Supongamos que tenemos una tabla de empleados y otra de empresas. Entonces en una base de datos relacional es trivial crear una clave foránea desde empleados a empresas que garantice que la empresa referenciada siempre existira. Pero no existe ninguna forma directa de expresar que el empleado Fulanito de Tal trabajó para Cual empresa entre 1994 y 1999. Hay que crear una tabla de histórico de empleos donde el sistema gestor de bases de datos relacional tampoco garantiza que no se solapen los empleos.
Para el caso concreto de las series temporales como las meteorológicas es posible emplear una base de datos orientada a columna como Cassandra. En una base de datos orientada a columna cada fila puede contener un número diferente de columnas y, además una cantidad muy grande de ellas, entonces es posible utilizar el nombre de la localidad como clave de la fila y crear una columna cuyo nombre sea de de cada instante del tiempo en el cual se tomó una medición y la celda contenga el valor de la medición.

6. Logs.

Los logs son toda la actividad que hay que grabar por cuestiones de auditoría de seguridad, trazabilidad de usuarios o depuración del sistema. La moda para recopilar logs es Kafka un sistema distribuido escrito en Scala que prioriza el rendimiento sobre la garantía de grabación de los logs en caso de fallo. Los logs son fáciles de recopilar cuando se trabaja con una sóla máquina. Simplemente hace falta un archivo y una cola de escritura asíncrona. Apache Tomcat trae de serie un recopilador de logs asíncrono que puede activarse fácilmente. El problema con los logs aparece cuando se pretende combinar los procedentes de varios servidores, especialmente si se desea que estén grabados en un orden estricto (usualmente temporal). Lo que Kafka hace es encolar localmente en cada servidor los mensajes de log, y luego los publica en un cluster al cual los procesos que extraen información de los logs pueden suscribirse.

6. Eventos.

En ocasiones es necesario que la aplicación reaccione en un tiempo corto como respuesta a un evento externo. O que sea capaz de aceptar una avalancha de eventos externos. Para la recolección de eventos es posible usar Apache Flume. Y para el procesamiento en tiempo casi real es posible usar Flink o Storm.

Big Data Stack

8. Informes.

Los informes son normalmente de tres tipos: 1º) listados operativos (transferencias bancarias realizadas ayer), 2º) resúmenes de KPIs (Key Performance Indicator), 3º) resultados OLAP (OnLine Analytical Processing) para modelos predictivos, simulación, etc.
La creación de informes consta de dos etapas. Primero se hace un proceso de extracción, transformación y carga (ETL) en el cual se leen los datos del almacén NoSQL y se graban en otro almacén apropiado, típicamente cubos OLAP para el análisis multidimensional. El proceso ETL puede ser bastante costoso y complicado computacionalmente motivo por el cual requiere un análisis refinado de los tiempos necesarios para mover los datos teniendo en cuenta la velocidad de la electrónica de red y de los discos. El proyecto de Apache para hacer OLAP sobre Hadoop es Kylin donado por eBay.

Principales productos big data en Apache

Hadoop

Las plataforma base de almacenamiento distribuido en Apache es Hadoop, un sistema distribuido de archivos.

La forma más sencilla de entender conceptualmente Hadoop es pensar que es como un disco virtual que por detrás está compuesto realmente de montones de discos esparcidos por un cluster de servidores. Las tecnologías de virtualización hacen que una misma máquina física pueda ejecutar varias máquinas virtuales. Pues bien, Hadoop hace exactamente lo contrario: muestra varias máquinas físicas como una única máquina virtual.

El sistema de archivos de Haddop se conoce como HDFS. Por razones técnicas, HDFS no maneja bien archivos pequeños. El espacio minimo que un archivo HDFS ocupa se suele fijar en una cantidad entre 64Mb y 256Mb. HDFS permite crear, eliminar, leer secuencialmente y añadir datos a archivos, pero no se puede modificar el contenido de un archivo excepto copiándolo en local y subiendo a HDFS una nueva copia.

Hadoop también incluye un ejecutor de procesos llamado YARN (Yet Another Resource Negotiator). YARN se diseñó originalmente para ejecutar MapReduce pero luego evolucionó hacia la ejecución de procesos en general proporcionando facilidades para que los procesos ejecutados se encuentren lo más próximos posibles a los datos, a ser posible en la misma máquina o si no al menos en el mismo rack.

La principal pega del API de Hadoop es que originalmente sólo funcionaba con Java y, además, carece de abstracciones para representar otros objetos que no sean sus «archivos ballena».

Al igual que sucede con las distros de Linux, es posible utilizar directamente el software de Hadoop disponible en la web de Apache, pero muchos clientes utilizan una distribución comercial con soporte y software adicional bajo licencia principalmente porque configurar y mantenar operativo un cluster de Hadoop no es para nada sencillo técnicamente. La distribución con mayor cuota de mercado es Cloudera, seguida de HortonWorks, MapR, Amazon Elastic MapReduce e IBM Infosphere BigInsights.

HBase

HBase es una base de datos maestro-esclavo orientada a columna implementada sobre Hadoop siguiendo el modelo de Google Bigtable. En HBase cada fila en una tabla debe tener una clave primaria. En principio, no existen índices secundarios, de modo que en esencia se trata de un sistema clave-valor pero con algunos «extras» importantes.

Cada tabla en HBase se compone de un conjunto de familias de columnas. Las familias de columnas deben definirse de forma estática cuando se crea la tabla pero luego cada fila puede contener un número diferente de columnas en cada familia de cada fila. Todas las columnas de una familia se almacenan juntas y ordenadas por nombre. Además, pueden existir múltiples versiones para los valores de cada celda, ordenados según una marca temporal (timestamp). El calificativo de tabla en las bases de datos orientadas a columna es, por consiguiente, equívoco, ya que sugiere algo similar a una tabla relacional o a una hoja Excel cuando en realidad consiste en una estructura distribuida de datos que dada una clave devuelve una colección de mapas (familias) nombre-valor.

Volviendo al caso de almacenamiento de grafos, recordemos que el problema de almacenarlos en una base de datos relacional es que para encontrar los sucesores de cada nodo es preciso realizar una consulta en una tabla cuyo tiempo de ejecución depende del tamaño del grafo y del número de sucesores. En HBase (u otra base de datos orientada a columna como Cassandra) los sucesores pueden obtenerse eficientemente como todas las columnas de una familia en una fila recuperada por clave primaria (el identificador del nodo de origen). Debido a que todas las columnas de una familia se almacenan juntas, los sucesores de un nodo pueden recuperarse en una única operación en lugar de tener que escanear la tabla con las relaciones nodo-origen – nodo-destino.

A diferencia de las bases de datos relacionales, HBase no permite especificar claves foráneas, tampoco existen índices secundarios ni se pueden definir transacciones. Las operaciones de lectura y escritura son atómicas a nivel de fila pero HBase carece de un mecanismo para garantizar que dos filas serán actualizadas de forma coherente. Los índices secundarios pueden crearse mediante una funcionalidad llamada coprocesadores, que también sirve para emular disparadores y procedimientos almacenados, pero programar contra el API de los coprocesadores no es fácil. Las transacciones y el soporte SQL pueden montarse por encima con otro proyecto de Apache llamado Phoenix. No obstante, el uso de Phoenix implica una penalización en rendimiento y escalabilidad ya que hay que añadir un gestor centralizado de transacciones a un sistema cuya escalabilidad depende de que funcione de forma distribuida. Además, yo creo que el uso de SQL es innecesario y equívoco en el caso de las bases de datos orientadas a columna.

HBase almacena los datos ordenados por clave primaria, por tanto, ofrece un redimiento óptimo para recuperar datos por rango de valores de la clave primaria. Un ejemplo podría ser el almacenamiento de emails siendo la clave primaria un identificador de usuario seguido de una marca temporal, y dos familias de columnas, una para las cabeceras y otra para el cuerpo del mensaje. Esto permitiría recuperar eficientemente los últimos n mensajes de cada usuario. Los índices secundarios, no obstante, habría que montarlos manualmente por separado.

HBase proporciona interfaces Java y Thrift y también un shell JRuby.

Hive y Pig

Para superar las limitaciones funcionales de Hadoop en el tratamiento de datos aparecieron Hive y Pig. Hive lo que permite básicamente es tratar archivos de texto un dialecto de SQL (HQL) como si fuesen tablas de una base de datos relacional, pero sin precargar los datos en un SGBDR. El esquema de los archivos tratados se almacena como metadatos en una base de datos relacional auxiliar. Esto permite hacer operaciones como count() o sum() y también join de archivos pero sin pagar el coste del tiempo de carga en un SGBDR.

Pig es principalmente una herramienta de ETL. A diferencia de Hive, funciona sin esquema y consta de tres partes: 1ª) Pig Latin, un lenguaje de scripting para describir procesos MapReduce; 2ª) Grunt, un shell interactivo y 3ª) Piggybank, un repositorio de funciones definidas por el usuario (UDF).

Hive y Pig están siendo paulatinamente desplazados por Spark.

Spark

Spark ha sido de un tiempo a esta parte la estrella de las aplicaciones de Apache para Big Data. Es un desarrollo originario del AMPLab de UC Berkeley que fue donado a Apache. Su éxito se basa en una mayor orientación a hacer uso intensivo de la memoria por contraposición a Hadoop que está orientado a usar los discos y en su aproximación de programación funcional sobre dos abstracciones de datos conocidas como resilient distributed data set (RDD) y DataFrames. Los RDD básicamente tablas distribuidas e inmutables sobre las que se pueden realizar dos tipos de operaciones: transformación y acción. La transformación convierte el RDD en otro RDD. Por ejemplo, map, filter, flatMap, groupByKey, reduceByKey, aggregateByKey, pipe, y coalesce son transformaciones. Y algunas acciones son reduce, collect, count, first, take, countByKey, y foreach. Spark evalua las transformaciones y acciones de forma perezosa, es decir, los resultados no se calculan realmente hasta que un proceso trata realmente de consumirlos para hacer uso de ellos. A diferencia de Hadoop donde las etapas map y reduce de MapReduce se comunican a través del disco, Spark intenta comunicar los resultados entre etapas en memoria motivo por el cual puede alcanzar rendimientos de uno o más órdenes de magnitud superiores a Hadoop.

Spark requiere para funcionar de un gestor de cluster y de un sistema de almacenamiento persistente. El gestor de cluster puede ser uno nativo de Spark, o también YARN o Apache Mesos. Para el almacenamiento Spark puede usar HDFS, MapR-FS, Cassandra, OpenStack Swift, Amazon S3 o Kudu.

Spark se compone de cinco modulos: core, SQL, streaming, machine learning (MLib) y grafos (GraphX). El core proporciona las funcionalidades de procesamiento y almacenamiento distribuido a través de interfaces Java, Scala, Python y R.

Cassandra

Cassandra es otra base de datos orientada a columna. Originalmente desarrollada por Facebook y luego donada a Apache. No es maestro-esclavo como HBase sino que se compone de un conjunto de nodos iguales que se comunican por un protocolo P2P sin depender de Hadoop como HBase. La estructura de las tablas es similar a la de HBase aunque se permite que los valores de las celdas sean también mapas atributo-valor. Y se pueden crear índices secundarios sobre columnas que no contengan mapas en sus celdas. Es decir, se puede pensar en una fila de Cassandra como un conjunto de mapas anidados.

En general, los benchmarks tienden a mostrar que Cassandra muestra un buen comportamiento respecto de los tiempos de escritura, pero las latencias son mayores que las de HBase en los tiempos de lectura. Ambas base de datos manejan las escrituras grabando previamente cada petición en un log local que luego se graba en el nodo o nodos apropiados del cluster como un sistema de mezcla coordinada de logs.

Cassandra ofrece APIs Java, C#, Python y Thrift. Pero el interfaz Thrift está siendo descatalogado en favor de CQL sobre JDBC.

Machine Learning

Hay tres proyectos en Apache que incluyen algoritmos de machine learning: Spark MLib, Mahout y FlinkML. Mahout proporciona un motor genérico de álgebra pero a la postre se trata la mayoría de las veces de encontrar el proyecto que contiene el algoritmo de machine learning requerido.

Otros proyectos Apache

Para no abrumar al lector, me he dejado en el tintero al menos dos docenas de proyectos de Apache. Hay una lista descriptiva aqui.

Consejos para elegir y desplegar tecnologías big data

1. Hacer un inventario de tipos de datos que se vayan a necesitar.

2. Definir los patrones de acceso a los datos.

3. Crear los modelos de datos de acuerdo a las necesidades de los patrones de lectura y escritura.

4. Utilizar el menor número posible de productos y tecnologías diferentes pues cada pieza añade complejidad adicional y aumenta la probabilidad de fallo del sistema.

5. No obstante lo anterior, no almacenar nunca en una base de datos relacional ni los logs ni los archivos binarios grandes. Las razones para no hacerlo son: 1ª) la escritura constante de logs puede sobrecargar fácilmente el sistema gestor de base de datos y 2ª) los logs y los archivos binarios grandes crecerán rápidamente hasta representar la mayor parte del tamaño de la base de datos, eso dificultará los backups y creará problemas de espacio en disco que no existirían si los logs y los archivos se guardasen separadamente en otro lugar más apropiado.

6. Elegir los proveedores para cada tecnología seleccionada. Aquí entran en juego detalles técnicos que dependen de las necesidades de cada proyecto. No se puede decir que PostgreSQL sea mejor que MySQL o que Cassandra sea mejor que HBase. Tampoco es inmediato que una infraestructura cloud proporcionada por un tercero sea mejor que una infraestructura propia. Depende de para qué.

7. Estimar el coste de despliegue y de mantenimiento. Mantener operativo un cluster, en general, no es fácil ni barato.

8. Establecer las métricas de coste de almacenamiento y retorno de inversión por byte almacenado. En función de dichas métricas, decidir qué datos merece la pena conservar y por cuánto tiempo.

9. Verificar cómo se moverán los datos de una plataforma a otra.

10. No confiar aspectos críticos del negocio a nuevas tecnologías hasta que no se haya comprobado su estabilidad. No todo lo que se puede descargar de Apache es estable. En el caso de las bases de datos los mayores problemas casi siempre se encuentran en los drivers de la parte cliente. El servidor en si mismo es estable. Pero el driver pierde memoria, o un mal uso del mismo deja conexiones abiertas que acaban tumbando el servidor. Si se monta una base de datos relacional para las entidades, y Cassandra para almacenar el catálogo de productos, y un cluster de Hadoop para el almacenamiento de imágenes, y HBase para almacenar mensajes de los clientes, y CouchDB para almacenar los formularios de las encuestas de satisfacción y Flume para capturar eventos y Kafka para gestionar los logs y Spark para hacer análisis de los datos y Kylin para hacer OLAP y… y… y… Muy probablemente el sistema será escalable hasta el infinito al tiempo que por completo inestable e imposible de mantener.

Posts relacionados:

NoSQL para no programadores.
El ecosistema de productos Big Data.
Cómo diseñar una aplicación escalable.

Publicado en Minería de Datos, Tecnologías Emergentes, Tecnologías Libres | Deja un comentario

El emprendedor adolescente

Publicado el 28 de agosto de 2016 por Sergio Montoro

Todos los veranos blogeo alguna historia. La verdad es que en los ya más de 10 años desde que heredé La Pastilla Roja siempre he tratado de evitar la autobiografía pues me aburren, en general, las personas que se dedican a contar su opinión introspectiva ya que a fin de cuentas todo el mundo tiene una opinión frecuentemente tan válida como cualquier otra. No obstante, haré una pequeña excepción esta vez pues creo que algunas experiencias adquiridas en mi periplo emprendedor merece la pena compartirlas. Voy a contar sólo lo imprescindible (que no es poco) sobre los primeros años para que se entienda el contexto, e intentaré detallar un poco más los años recientes tras irme a Inglaterra por estar más próximos a la realidad que otro emprendedor pueda encontrarse ahora mismo.

Soy un emprendedor adolescente, empecé en 2000 y dieciseis años no es nada. A los dieciseis apenas ha terminado de salirles el bigote a los jóvenes imberbes. Tuve, no obstante, una ventaja de salida, que también fue una trampa (por razones demasiado largas de contar): la de provenir de una familia de abuelos y padres emprendedores. También me influyó mucho uno de mis primeros empleos, el de los años que pasé en Meta4, una multinacional española de desarrollo de software como nunca he vuelto a encontrar otra igual. No sólo por la velocidad a la que creció, sino también por su espíritu y sus políticas de recursos humanos que fueron capaces hasta de acomodar a un disidente crónico como yo. Meta4 falló básicamente por efecto de segundo de sistema en una historia que puede encontrarse resumida aquí, pero antes de eso creó un montón de valor y provocó una diáspora de profesionales de la cual yo fui parte.

Salir con buenas referencias de mi primer empleo por cuenta ajena me abrió algunas puertas. Cuando empiezas no tienes nada excepto la confianza en tu coraje que puedas generar en los compradores potenciales, y si ese coraje viene avalado por recomendaciones mejor que mejor. Tu cliente, la ciudad de Gotham, necesita a Batman y a Robin, no al inoperante departamento de policia local. Algunos emprendedores se acomplejan e intentan vender la empresa por lo que no es: más grande, más formal. Esto es un error pues también hay clientes muy interesados en contratar superhéroes.

Mi plan de negocio original no tenía ni pies ni cabeza, tampoco tenía ni idea de finanzas ni de cómo funcionaba realmente el mercado. Aún así conseguí el apoyo de algunos socios y P.P.P. (Primos, Parientes y Putas). Afortunadamente, por casualidad o por sapiencia, estábamos en medio de la primera burbuja punto com y nuestro cash burning rate era bajo, de modo que pronto empezamos a crecer en facturación con pingüe beneficio ya que en aquella época los márgenes brutos en consultoría rozaban el 60%

Después de fabricar un prototipo fallido de Dropbox y otro prototipo fallido de Magento, en el año 2003 (tres años después de fundar la empresa) averigué qué era lo que había que desarrollar, lo cual resultó ser un CRM Open Source bautizado hipergate que durante una década fue bastante exitoso antes de que el SaaS tomara el relevo como modalidad de distribución de software. A hipergate le exprimimos el jugo durante diez años desde 2003 a 2013. El truco erá que la inversión inicial necesaria fué baja (por debajo de 250.000€) y podíamos asumirla sin inversores externos. Además, el mantenimiento evolutivo anual también era barato y financiado en buena medida por clientes. Por consiguiente, cualquier múltiplo que le hiciésemos a esa cantidad iba a beneficio. Esto contrastaba con las inversiones millonarias que empezaron a recibir en los años siguientes otros productos de software empresarial Open Source. La realidad es que en el Software Libre una gran parte del valor creado se transmite al cliente de forma gratuita y, por tanto, la rentabilidad de la empresa es menor. También son menores sus costes comerciales pero hay que ajustarlo todo en función de los ingresos por ventas. Lo cual me conduce al primer gran hallazgo que creo merece la pena compartir:

No es necesaria inversión para ganar dinero.

Esta ha sido mi realidad una y otra vez. Los negocios en los que no he invertido dinero, o muy poco dinero, me resultaron muy provechosos, así fue en KnowGate y en iContainers. Por contra, los negocios en los que he invertido fuertemente he perdido siempre hasta la camisa. No fue hasta 2009 cuando en una visita de turismo tecnológico a Silicon Valley tuve la oportunidad de desayunar con Scott McNealy quien ataviado en vestimenta de golf se limitó a dar dos consejos: a) haz negocios siempre con el dinero de los demás, nunca con tu propio dinero, y b) si sacas tu empresa a bolsa la perderás inevitablemente.

No obstante lo anterior, existe un punto de inflexión en el que sí hay que estar preparado para endeudarse: cuando la empresa empieza a escalar en ventas. En retrospectiva, fué un error estratégico no globalizar KnowGate endeudándonos. Al principio del milenio hacíamos muy buen dinero con la venta de servicios pero el modelo de negocio no era adecuado para internacionalizarlo. Luego tuve otra buena oportunidad en 2004 con hipergate, pero decidí optar por quedarme en mi pueblo y diversificar invertiendo en ladrillos (con el resultado que el lector podrá imaginar). Y para cuando quise volver intentarlo en 2009 ya era tarde pues la competencia de software CRM había progresado mucho y yo andaba demasiado ocupado parcheando el socavón que la explosión de la burbuja inmobiliaria me había creado.

Gracias a la bonanza económica, entre 2006 y 2010 fue muy fácil conseguir financiación pública de diversas fuentes. Sé que los inversores privados critican a la financiación pública porque hace competencia desleal a sus productos financieros. Pero si se puede acceder a ella es dinero muy barato. Hay más detalles sobre cómo funcionaba esto aquí, aquí, y aquí.

En 2009 estábamos en una buena posición. El reventón de la primera burbuja punto com había impactado ciertamente la empresa en 2002, pero no tanto como para desposeerla de capacidad para seguir invirtiendo e innovando. Acumulábamos 9 años de beneficios consecutivos y no teníamos deuda. Y todavía no nos había alcanzado el tsunami de la crisis inmobiliaria porque las grandes empresas para las que siempre hemos trabajado hacen presupuestos anuales y tienen buena calificación de riesgo crediticio (aunque sea mentira).

La diferencia entre la crisis de 2002 y la de 2008 es que la de 2002 fue un suceso súbito y de alcance limitado. El IBEX Nuevo Mercado ¿alguien se acuerda? se fué en bloque a Alpedrete y aniquiló proyectos pioneros como Terra y TPI, pero no dañó demasiado la economía española en conjunto. Además inmediatamente a renglón seguido el ladrillo empezó a tirar del carro y volvieron las vacas gordas. Por contra, la crisis de 2008 fue, y sigue siendo, un proceso agónico que nadie pronosticaba que durase tanto ni tan duramente.

Al principio fué como caerse de un rascacielos: vas por el piso cuarenta y no te enteras demasiado excepto por cierta sensación de vértigo en el estómago. En 2011, casi tres años después del inicio oficial de la crisis y aún en beneficios, empezaron a combinarse varios factores para crear la tormenta perfecta.

• En primer lugar los precios por hora de consultoría prácticamente no habían variado desde el año 2000, pero los costes sí que habían crecido significativamente. Por consiguiente, los márgenes se habían reducido muchísimo, y la rentabilidad se mantenía en gran parte gracias a subvenciones públicas que se repercutían en los clientes. KnowGate vendía con frecuencia a pérdida y compensaba con la subvención. Pero tras la victoria electoral del Partido Popular las subvenciones se redujeron enormemente, tanto que en muchas ocasiones ni valía la pena solicitarlas.

• En segundo lugar los clientes habían apostado porque la crisis no sería muy larga y habían seguido endeudándose tanto como los bancos les habían permitido en la esperanza de que el temporal pasaría pronto. Creo que muchos incluso pensaron que la situación mejoraría con el ascenso al poder de Mariano Rajoy. Pero cuando empezaron a caer los bancos como fichas de dominó se secó definitivamente el crédito a las empresas. Especialmente el crédito procedente de las cajas quebradas que eran menos exigentes en análisis de riesgos que los grandes bancos como Santander y BBVA.

• En tercer lugar yo había estado derivando una cantidad excesiva de caja y de deuda desde el negocio tecnológico hacia el del ladrillo en un intento de salvar la moribunda inversión inmobiliaria. La sangría había reducido la capacidad de KnowGate para reinvertir en I+D justo en el momento en que la competencia venía pisando más fuerte en SaaS.

• El toque de gracia fueron los impagos sistemáticos de 2013. Prácticamente todos los clientes empezaron a tener problemas para pagar, variando desde la demora al impago total. En España la justicia civil es inoperante, especialmente en temas mercantiles (excepto si se trata de la AEAT, y a veces ni eso). En consecuencia, no había forma de cobrar ni tampoco de refinanciarse. Adicionalmente, un agravante era que en 2002 los clientes dejaron súbitamente de comprar (lo cual es malo) pero entre 2011 y 2013 siguieron comprando a sabiendas de que probablemente no podrían pagar, lo cual es mucho peor para el proveedor.

Empezaron a producirse situaciones absurdas. Una aseguradora nos ofreció una póliza de cobertura de impago que contenía una cláusula que decía que el seguro no sería aplicable en el caso de que la información financiera suministrada por el cliente no fuese totalmente veraz. Otro banco nos ofreció una línea de crédito con otra cláusula que estipulaba que la entidad podría cancelar unilateralmente la línea de crédito y exigir el retorno inmediato del principal en el caso de que nuestra calificación de riesgo variase. En otra ocasión un director de sucursal me ofreció una línea de crédito de 60.000€ al 7% y me dio largas durante cuarenta y cinco dias hasta el día 25 de un determinado mes. Entonces se presentó en el notario con una póliza de 30.000€ al 9,5% a sabiendas de que yo no tenía dinero para pagar las nóminas ese mes si no firmaba, alegando que en riesgos le habían prohibido ninguna otra cosa justo esa misma mañana pero sin que se hubiera producido ninguna variación importante en nuestra posición financiera desde que solicitamos y supuestamente se aprobase el crédito.

Fué el hartazgo en perseguir a los morosos lo que me impulso en último término a mover el culo y empezar de verdad a buscar clientes fuera de España. Era muy curioso porque contablemente la empresa estaba bien pero no teníamos ni un céntimo de caja. En cierto sentido los bancos nos hicieron un favor al no refinanciarnos, pues en el caso de haberlo hecho yo habría posiblemente contraido más deuda para financiar los impagos lo cual hubiese sido un error. La sociedad limitada española había que sanearla asumiendo los incobrables y al final en 2014 acabó dividida en dos, la propia KnowGate y QSWKS (nos van los nombres impronunciables) a cargo de mi hermano que había sido mi socio cofundador desde el principio. Un año después habíamos liquidado al resto de los socios fundadores de KnowGate y constituido una nueva sociedad en Inglaterra. La lección en todo esto es lo segundo que quiero compartir:

Voy a volver a trabajar con un banco en la próxima vida.

No he firmado un crédito desde 2008 y no pienso volver a hacerlo a menos que me apunten con un arma a la cabeza.

Desde 2003 teníamos muchos partners de hipergate pero hacíamos poco negocio con ellos pues nunca tratamos en serio de explotar comercialmente el mercado internacional. No trabajar más con los partner y las relaciones públicas internacionales fue un craso error estratégico.

Esto me conduce a lo tercero importante que quiero compartir:

El error estratégico que más lamento y que más me ha costado como emprendedor es no globalizar el proyecto desde el principio. Es haberme quedado en mi pueblo porque vivía bien haciendo ventas en el barrio y sus aledaños a grandes empresas que tenían más capacidad de compra que nosotros de venta.

Tenía varias opciones como destino: podía intentarlo en Silicon Valley, podía intentarlo en Londres o podia intentarlo en Zurich u Oslo. Dependía del modelo de negocio que eligiese. Silicon Valley parecía el destino más idóneo para crear un nuevo producto, pero implicaba quemar todas mis naves, además de que no tenía claro qué hacer con hipergate. Suiza o Escandinavia ofrecían los mejores salarios si lo que quería era trabajar como programador. Londres tenía la ventaja de la proximidad, facilidades de asentamiento y una fuerte demanda de servicios profesionales de desarrollo de software bien pagado. Así que fué Londres.

Desembarcar en el mercado inglés fue relativamente fácil. La burocracia requerida es mucho menor en Inglaterra que en España, y no tardé más de seis meses en encontrar socios en una empresa SaaS ansiosos por contar con mano de obra especializada que, además, podía ser reclutada y ubicada en España. Así que era posible crear un flujo de caja intracomunitario para contribuir a mantener el empleo en España. Esto no funcionó a la postre excepto por algunas subcontrataciones, pues los programadores que podían estaban huyendo en masa de España y acabamos contratando programadores españoles residentes en Inglaterra por un coste muy superior al que nos hubiese supuesto en España. También fue fácil que IBM se implicase en la comercialización conjunta de su stack sobre Websphere, y encontrar apoyo logístico y financiero de la multinacional española Habber Tec para intentar expandirse en el Reino Unido.

El mercado inglés es muy hostil y competitivo y no es para todo el mundo. Algunos españoles nunca consiguen adaptarse. La pretendida educación y buenas maneras de los ingleses enmascara una agresividad insospechada. Algunos compradores potenciales pueden vapulearte sólo por placer. El nivel técnico de la oferta es más elevado y cómo en la City ya no cabe más gente el número de candidatos bien preparados es a veces apabullante. Hay de todo, españoles, italianos, griegos, sudafricanos, hindues, africanos, y un larguísimo etcétera de gente de todos los colores.

El mal clima es un mito. Es verdad que en invierno se hace de noche a las cuatro y media, pero los veranos son muy agradables. El calor nunca es sofocante. La lluvia frecuente ha puesto fin a mi congestión nasal crónica y en la periferia hay menos polución que en Madrid o Barcelona. Lo peor es el viento, solo los extranjeros usan paragüas, pues los nativos saben que no es buena idea a menos que se pretenda volar como Mary Poppins. El transporte ferroviario también es comparativamente muy malo, al nivel de los trenes de media distancia que unían Madrid con Extremadura en los noventa.

La competencia de productos también es dura en Inglaterra. Las empresas proveedoras están muy especializadas y encontrar un «océano azul» o una buena imperfección de mercado es extraordinariamente difícil. Estratégicamente puede que compense expandirse hacia los Midlands donde la oferta es menor debido a lo mal comunicado que está el país isleño. Y sobre todo Irlanda debido a su ventajosa fiscalidad y facilidades para el asentamiento. Yo aún no he explorado estas opciones, pero parecen prometedoras.

Una ventaja del mercado inglés es que los clientes, además de tener más capacidad de compra, se molestan menos si te enriqueces trabajando para ellos. En España era frecuente tener la sensación de que el cliente estuviese molesto porque ganábamos dinero «a costa suya». Siempre andaban indagando sobre nuestros márgenes para dejarnos en coste de empresa más 15%. En Inglaterra hemos recuperado márgenes por encima del 40% que es el mínimo en una empresa de consultoría para resultar rentable.

Por el momento no tengo planeado volver a España, lo siento. La razón es que, básicamente, con respecto a la coyuntura de mercado hay dos entornos posibles: a) el país está bien desarrollado, hay competencia, burocracia, elevados impuestos y mano de obra cara pero también una potente demanda; o b) el país está subdesarrollado, la demanda es débil excepto por algunas grandes cuentas pero existe poca competencia y es barato producir. Mi problema con España es que es complicado como un mercado desarrollado pero con una demanda débil. Los salarios se han abaratado, si, gracias al glorioso plan estratégico estatal de intentar copiar el modelo económico chino, pero los buenos programadores han huido y, paradójicamente, es más difícil ahora mismo encontrar mano de obra bien cualificada en España que en el Reino Unido. En España llegó un momento en el que prácticamente teníamos que suplicarle a los clientes que nos comprasen algo. Luego había suplicarles que nos lo pagasen, en el mejor de los casos a 90 días. En Inglaterra es muchísimo más fácil que un cliente potencial se interese por lo que le cuentas y los pagos son treinta dias máximo, a veces a quince, sin historias de indios y vaqueros en plan «el SAP no me deja pagar en agosto».

El plan a futuro es innovar en la forma en la que se produce el software empresarial y se distribuyen los servicios profesionales en una economía globalizada. Los detalles de este plan aún no los puedo desvelar. Espero que sean la transición de la adolescencia a la madurez conduciendo a un éxito sereno.

Hay más detalles biográficos, mios y de otros emprendedores similares, en este libro de Ana Oliva.

Post relacionados:
Las reglas del perro viejo para los negocios.
La trampa mortal del crecimiento.
Pírricas victorias empresariales.
Saṃsāra corporativo y stress del emprendedor.
Preguntas típicas que hacen los emprendedores noveles.
Combatiendo a tus dragones.

Publicado en Emprendizaje, Mercado y Oportunidades de Negocio, Modelos de Negocio | Deja un comentario

Cómo sobrevivir al software «Enterprise»

Publicado el 4 de agosto de 2016 por Sergio Montoro

Hace poco me sonreía con una viñeta cómica que presentaba el concepto de «Programador Orientado a Google» en referencia a aquellos quienes han adquirido la mayor parte de sus conocimientos por su propia cuenta buscando Internet. Conozco no pocos programadores de esta clase, un puñado de ellos me parecen realmente sobresalientes. No obstante, la industria de software que se ve en Google, como toda la WWW en sí misma, es sólo la punta del iceberg. Este post me ha quedado algo largo y plúmbeo en comparación con las batallitas que suelo narrar. Pero si el lector es informático, o sufrido usuario de informática, le ayudará a reflexionar sobre cosas que posiblemente ya sabe aunque no se haya dado cuenta.

¿Qué caracteriza al software «Enterprise»?

Para los que no estén familiarizados con la historia, el Software Enterprise es algo demoníaco. Es tan pernicioso que se generó un movimiento cultural mundial, el Software Libre, en su contra. Y, sin embargo, el software enterprise también es necesario para el mantenimiento de la industria, incluso la industria del Software Libre. Aunque la innovación la encabeza el software libre, gran parte del dinero que nutre dicha innovación sale de empresas de software privativo ya sea on premise o SaaS. Y los algoritmos más avanzados en inteligencia artificial, machine learning y aplicaciones militares siguen estando sólo al alcance de unos pocos ojos.

Ahora la moda es publicar código en Github (benditos aquellos años 2003-2005 en los que estábamos en el top 10 de SourceForge con nuestro CRM libre hipergate :D). Pero la mayoría de los informáticos no hacen carrera publicando en Github ni sumando medallas en HackerRank. Por consiguiente, necesitan habilidades diferentes de las del Programador Orientado a Google que se caracterizan por lo siguiente:

1. La documentación es comparativamente paupérrima. No tanto por los manuales en sí mismos sino por la imposibilidad de consultar en Stackoverflow cómo se hace esto o aquello. Incluso los ISVs más importantes como IBM, Oracle y SAP tienen lagunas enormes en su documentación. Tampoco existe una comunidad de usuarios como tal, sino que se depende del soporte técnico del fabricante, el cual es caro, lento y a menudo con menos conocimientos prácticos que el cliente que está sufriendo en sus carnes la puesta en producción.

2. Los módulos son cajas negras. No se puede mirar dentro de ellos para ver qué están haciendo. Si no funcionan bien poco se puede hacer para soslayar el problema.

3. El programa de instalación no es algo a lo que le hayan prestado mucha atención. Hay algunas excepciones, creo que la más notoria que conozco eran los instaladores de Panda, por la dificultad excepcional de instalar un antivirus. Pero el instalador no suele considerarse un componente prioritario. Es por eso que empresas como Bitnami han tenido tanto éxito externalizando la función de instalación. A los desarrolladores normalmente se les da una máquina virtual con todo el entorno preinstalado pero no es fácil replicar todo un ecosistema empresarial en local, por consiguiente, pocas veces se puede desarrollar en remoto sino que hay que trabajar de cuerpo presente conectado a las redes internas del cliente.

4. Los expertos escasean. Debido a la dificultad para autoformarse, sólo la gente que ha trabajado en proyectos reales tiene los conocimientos necesarios.

5. El control de versiones es propietario. En el software enterprise muchas veces se programa con un lenguaje de scripting que corre sobre la plataforma privativa. Es frecuente que la plataforma no esté integrada con un sistema de control de versiones estándar como Git o Subversion.

6. Puede ser difícil hacer TDD. Muchas plataformas no incorporan un marco idóneo para el diseño dirigido por tests. Hay que instrumertarlo por fuera con Selenium o alguna otra herramienta.

7. Los componentes están pensados para integrarse en arquitecturas existentes. Esto implica que existirán piezas de las que les gustan a los administradores de sistemas, como single sign-on o sistemas de monitorización. También implica que el número de novísimas librerías «alienígenas» es menor debido a que a los técnicos del cliente no les suele gustar, y con razón, tener que mantener tecnologías de las que son totalmente desconocedores además de ser cuestionables en estabilidad, seguridad y rendimiento debido a su novedad. Ciertamente es posible encontrar piezas de Python 3 escondidas en lo profundo de la aplicación Core Java más recalcitrante, pero no suele ser la tónica que las grandes empresas sean adoptadores tempranos de tecnología excepto en proyecto tácticos con los que pretenden ganar una ventaja competitiva.

¿Qué tener en cuenta a la hora de producir software enterprise?

Como consecuencia de los puntos anteriores, conviene tomar en consideración que:

1. La especificación no puede contener nada que no esté en la documentación. El cliente no puede escribir la clase de Carta a los Reyes Magos tradicional en un proyecto de desarrollo a medida sobre Software Libre. Sólo puede pedir lo que se pueda encontrar en la documentación, pues el nivel de esfuerzo para hacer cualquier otra cosa variará desde titánico a imposible según el caso.

2. Los usuarios tienen que aprender a usar el software. Y no al revés. Quiero decir, cuando se va cambiando su comportamiento del software para adaptarlo a lo que los usuarios esperan que haga.

3. La instalación pueden convenir encargársela al ISV. Así como la actualización de versiones y el desarrollo de plug-ins estrechamente acoplados con el sistema principal.

4. Hay que incluir programas de formación para desarrolladores en la planificación. No se puede conjeturar que habrá en el mercado consultores disponibles. Puede que si, o puede que no. Por consiguiente, lo más prudente es pagar por la formación previa de todos los que vayan a desarrollar sobre la plataforma.

5. Hay que hacer el control de cambios a la antigua usanza. Aunque casi todas las herramientas enterprise proporcionan algún tipo de gestión de versiones, en muchas de ellas no existe una forma sencilla de trazar los commits o revertir un cambio puntual.

6. Conviene sobredimensionar los servidores. Muchas de las aplicaciones enterprise son bastante pesadas, sobre todo en consumo de memoria porque suelen hacer uso de un número muy considerable de librerías. Además, debido a la opacidad sobre el funcionamiento interno de los módulos es difícil hacer optimizaciones en el caso de que el rendimiento no sea el deseado.

¿Cómo influye el entorno organizativo?

Además de la naturaleza particular del software enterprise, hay que tener en cuenta el ecosistema de departamentos que coexisten en una gran empresa donde cada incumbente tiene intereses diferentes de los demás.

1. Patrocinio directivo. Según el capítulo primero de cualquier libro de gestión de proyectos, nada sale adelante sin la sponsorización de la alta dirección. El soporte de alto nivel ejecutivo sirve para garantizar que se mantendrán los recursos humanos, físicos y monetarios asignados al proyectos. Pero cuidado porque el soporte ejecutivo también puede ser una manzana envenenada por tres motivos: a) los miembros del consejo de administración no siempre actúan como una piña sino que pueden usar los proyectos para atacarse unos a otros, b) los altos mandos rara vez pueden defender a los operativos de las malas prácticas de los mandos intermedios esencialmente porque no es fácil reemplazar a los mandos intermedios indeseables, y c) cuanto más apoyo ejecutivo -y por ende dinero- recibe un proyecto más visible se vuelve a los ojos de los Nazgull de otras empresas.

2. Dedicación del staff del cliente. A menudo el staff del cliente se encuentra en una situación de sobrecarga laboral en la cual debe por una parte colaborar con los desarrolladores en la definición y validación de nuevos sistemas, y por otra seguir sacando adelante su trabajo diario habitual.

3. Procesos organizacionales. Cualquier empresa que lleva sufientes años en el mercado probablemente ha invertido una gran cantidad de esfuerzo en definir y mejorar sus procesos hasta el punto de que se han quedado grabados de forma indeleble en la mente de los usuarios. Los procesos de cambio organizacional son, en general, muy difíciles y llevan años cuando no lustros de completar, incluso muchas empresas acaban fuera del mercado antes de ser capaces de cambiar.

4. Dispersión geográfica. Ni el SaaS más puro para empresas puede librarse de al menos un recurso que se necesita de forma casi lineal con respecto al crecimiento de la base de usuarios: el soporte. Muchos pequeños proveedores de software no están preparados para instalar su producto en grandes empresas aunque el producto sea idóneo y funcione bien carecen de la capacidad para movilizar suficientes recursos de postventa. Si las sedes del cliente están geográficamente dispersas el esfuerzo en formación y soporte se incrementa todavía más. No quiero sugerir con lo anterior que el software como servicio no suponga ninguna diferencia, sí la supone, por ejemplo, uno de los factores claves del éxito de Salesforce fué su capacidad diferencial para desplegar apliaciones de CRM para equipos dispersos.

5. Normativas y KPI. En una gran empresa cada departamento tiene sus propias normativas y Key Point Indicators en los que basan sus métricas de eficiencia y cumplimiento de objetivos. Aunque el software tenga una misión global, para alcanzarla todavía necesita cumplir con una larga lista de requisitos burocráticos intermedios.

¿Cómo influye la arquitectura técnica?

No es posible, en general, llegar a una gran empresa y pretender que adopte el último grito en tecnología sólo porque sea teóricamente disruptiva. Algunas veces pasa, y ciertamente en los departamentos web hay bastante libertad para incorporar novedades, pero simplemente no se puede sacar algo de una chistera y que el cliente lo use porque es «mágico». Los arquitectos de software en los clientes piensan de forma holística en términos de plataformas interoperables: ¿Cuánto me costará adoptar esta plataforma? ¿Tengo a gente formada? ¿Cómo haré el mantenimiento diario de sistemas? ¿Qué pasa si algo funciona de forma defectuosa? ¿Cómo voy a comunicar esta plataforma con aquella? ¿Cuantos años puedo usarla antes de que esté obsoleta?

La SEGURIDAD suele ser una característica deficiente en casi todo el software que se instala en las empresas. Además normalmente hay bastantes restricciones de acceso. Es frecuente que los ordenadores desde los que se ejecutan las aplicaciones empresariales tengan severamente restringido el acceso a Internet (o ningún acceso a Internet). Incluso dentro de la red interna de la empresa es probable que una aplicaciones no «vean» a otras. La electrónica de red, por cierto, puede jugar muy malas pasadas en una red empresarial porque la situación típica consiste en centenares de usuarios enviando correos ballena y moviendo archivos diplodocus sobre una infraestructura física que puede tener hasta una década de antigueadad. En una empresa es muy habitual que el rendimiento de una apliación se vea degradado porque otra aplicación está compitiendo por los mismos recursos (casi siempre la red). Por último, para las aplicaciones que trabajan con los datos más sensibles todo tiene que funcionar con certificados y protocolos seguros que garanticen que la información en tránsito no ha sido espiada ni alterada en modo alguno.

Otra regla del dedo gordo es que no quieres que tu software tenga que llamar a ningún otro sistema. Siempre hay que pelear a muerte que sean los otros sistemas los que le llaman a uno. Esto es debido a que siempre es posible monitorizar las llamadas entrantes y el software propio. Pero si se produce un mal funcionamiento los sistemas de terceros son una caja negra con la que se pueden tardar días o semanas en diagnoticar cualquier cosa tras una discusión interminable con el otro sobre quién tiene la culpa de qué.

¿Cómo diseñar software enterprise?

Los requisitos a priori para que un producto de software enterprise sea vendible son una consecuencia de todos los puntos expuestos anteriormente.

1. Tecnología. Debe estar basado en una tecnología que el cliente no perciba como un riesgo a medio-largo plazo. Además, las empresas de software se fagocitan unas a otras. Por consiguiente, desde el día 1 las elecciones de tecnología base deben hacerse teniendo en cuenta quienes podrían ser los compradores potenciales de la empresa. Esto no necesariamente descarta el Open Source, en Google, por ejemplo, se usa mucho Python. Pero si el objetivo último es Oracle o IBM entonces mejor si todo está escrito en Java.

2. Funcionalidades. Los pliegos de compra de software enterprise contienen casi siempre tantos requisitos que parece que el programa vaya a ser capaz de conectarse con la tostadora de tu casa y prepararte el desayuno antes de que te levantes. Hay un dilema irresoluble con respecto a esto: con pocas funcionalidades no se gana el pliego y con muchas el producto es como una navaja suiza útil para todo y buena para nada. Algunos fabricantes han resuelto el problema con una versión «estándar» que contiene lo que funciona, y un conjunto de módulos accesorios con lo que no funciona pero queda bien decir que lo hace el producto.

3. Posicionamiento. El posicionamiento del producto depende del alcance que tenga. Para los productos tácticos que sólo satisfacen una necesidad concreta de un departamento es posible dirigirse directamente a los clientes sin muchas maniobras. Para los productos más ambiciosos se suelen emplear tres tácticas: a) puntuar bien en los informes de las consultoras como Gartner, b) aliarse con socios estilo Accenture o KPMG para que prescriban el producto, c) autoproclamarse sistemáticamente el líder indiscutible en algún determinado nicho. Cualquiera de estas tácticas es costosa. Trabajar con las consultoras que evalúan producto no es barato aunque a veces se puede ahorrar dinero anunciando que se lanzará al mercado justo lo que la consultora pronosticó como tendencia futura a corto plazo. Es peligroso que el roadmap de producto lo condicione un tercero con una tasa de acierto en sus predicciones que no siempre es espectacular. Pero si los clientes también se creen las predicciones entonces se puede salir en el magic quadrant de la consultora y cerrar ventas simultáneamente. Por otro lado, las empresas como Accenture y KPMG lo que buscan es posicionarse como líderes en asesoría de negocio y proyecto en determinados sectores, para lo cual una de las piezas que necesitan es el software. Todos los socios para la implantación son, en general, muy oportunistas y sólo apuestan a corto plazo, pero si se consiguen algunos pocos proyectos exitosos con ellos es posible convencerles de que inviertan más en formar personal de venta, gestión y soporte postventa al software. Por último, aclamarse como el líder indiscutible de un nicho requiere de buenas referencias, una gran pericia en relaciones públicas y no poco gasto publicitario.

4. Precio. Una de las cosas que no se puede buscar en Google es el precio de un software enterprise. Existe un precio de lista que se facilita sólo a los distribuidores pero los fabricantes pueden aplicar descuentos de hasta el 60% según lo que les interese entrar en una cuenta o redondear el cierre de trimestre. La política de precios consiste, basicamente, en cobrar lo que se pueda a quien se pueda.

5. Soporte. El soporte es un área curiosa para mi, porque tiene tanto de gestión de expectativas como de solución real de problemas. Normalmente lo que el cliente quiere es saber qué es lo que sucede y cuándo va a estar arreglado (o no). Pocas veces hay incidencias críticas de verdad. En una ocasión leí una publicidad de una empresa que ofrecía «soporte fanático», no he vuelto a saber de ellos, probablemente porque cuando los de soporte son unos fanáticos todo el mundo va como loco. Y si hay algo que detestan los clientes corporativos es la incertidumbre. En la mayoría de las empresas de software enterprise hay un departamento de I+D (que va a su puta bola) y un departamento de servicios que son los que tragan con la comida de perro de los de I+D. Yo no soy partidario de la separación radical entre desarrollo y soporte por esta razón enunciada de que los programadores acaban viviendo en una torre de marfil, pero tampoco se puede asignar a una persona simultáneamente a desarrollo y a soporte porque acabará haciendo pobremente lo uno y lo otro.

¿Qué ventajas tiene el software enterprise?

Por lo que he escrito hasta ahora, sé que parecería que uno no desearía caer prisionero del software enterprise ni en su peor pesadilla. Pero no todo es malo respecto de este segmento de la industria de software.

1. Acceso a componentes y procesos predefinidos y testeados. Para muchas aplicaciones simplemente no existe ninguna alternativa libre. Los programadores son técnicos a quienes lo que les gusta resolver problemas técnicos y luego publicar las soluciones para ganar fama, pero muchos de los procesos empresariales son aburridos a morir ergo no les interesan. Faricarse el software a medida uno mismo puede ser mucho peor. Yo he estado en proyectos con más de 300 aplicaciones a medida cada una de su padre y de su madre y eso es un sin Dios.

2. Disponibilidad de un marco de desarrollo común. Cuando se trabaja con varios equipos, posiblemente subcontratados de forma cambiante, es necesario tener un marco de desarrollo común que aporte un mínimo de homogeneidad a las aplicaciones. Los desarrolladores de funcionalidades deben estar, además, lo más aislados posibles del núcleo técnico para que no puedan por error provocar ningún desastre en la base de datos.

3. Acceso a innovación precocinada. Una pega de las herramientas Open Source es que muchas de ellas se distribuyen como un kit de hágaselo usted mismo. Entonces, una parte de lo que se ahorra en licencias hay que gastarlo en configuración y atención diaria de sistemas.

4. Mejor arquitectura. No siempre es el caso porque algunos programas bastante populares son un verdadero truño. Pero normalmente un software enterprise que ha sobrevivido suficiente tiempo en el mercado ha pasado por una serie de versiones en las que ha tenido que evolucionar en función de los requisitos de múltiples clientes en producción. Algunas de las aplicaciones Open Source más rabiosamente de moda son software extraído, es decir, software que se fabricó en una empresa concreta para un propósito concreto y luego se liberó sin demasiados cambios.

5. Continuidad. Esto sólo se aplica a los programas que son tan grandes como para no se blanco de compra de nadie. Las empresas de software empresarial tienen tres opciones de futuro: crecer muchísimo, ser absorbidas o desaparecer. Existen incluso empresas especializadas en gestionar el fin del ciclo de vida de software empresarial obsoleto. A decir verdad nunca se está a salvo. Spring y JBoss se fueron a manos de Red Hat y MySQL acabó nada menos que en manos de ~~Microsoft~~ Oracle con todos los directivos abandonando el barco y Monty Widenius creando MariaDB por su cuenta. Y si el software no es comprado por otro más grande es posible que al proveedor deje de interesarle y no invierta en actualizaciones.

Conclusiones

Existen muchos aspectos a tener en cuenta en el software que no son el lenguaje de programación o la productividad del último grito en herramientas. El software empresarial debe gestionar un complejo conjunto de subsistemas interconectados y debe cumplir con una larga lista de requisitos técnicos y funcionales de los clientes. Todo esto tiene un coste que, unido a lo largos que son los procesos de venta, implica que el precio del software empresarial no puede ser bajo. Por último, es legítimo invertir en innovación y pretender cobrar por ello. Creo que una parte de los defensores a ultranza del Software Libre se equivocan al pensar que todas las licencias de software deberían ser GNU o Apache. El movimiento Open Source surgió como reacción a las prácticas abusivas de venta por dominio de algunos fabricantes y como respuesta a regulaciones absurdas como las patentes de software. Pero no se trata de negar el derecho a cobrar por la propiedad intelectual y el esfuerzo en innovar, testear y distribuir.

Post relacionados:

El ciclo de vida del cliente B2B.
Los nuevos productos y el poder en las organizaciones.
Cómo ponerle precio a un producto software.

Publicado en Adoptando Sw Libre en una Organización | Deja un comentario

Muerte por agilismo

Publicado el 18 de junio de 2016 por Sergio Montoro

He perdido la cuenta de la cantidad de empresas que he visitado las cuales, pretendiendo hacer Agile a ultranza, se enfrentan a serios problemas de retrasos en los plazos y falta de calidad en los entregables. La justificación siempre es la misma: que el problema no es Agile sino que no están haciendo Agile bien. Que el problema es que no cierran una release verdaderamente estable en cada sprint o que la descripción de cada tarea en JIRA cabría perfectamente en un tweet, o que los tests son insuficientes, o cualquier otra excusa justificando la disfuncionalidad en base a una falta de ortodoxia. Pero es falsa la creencia extendida de que más Agile arreglará los problemas de una empresa con dificultades para producir versiones estables dentro de los plazos estipulados. A renglón seguido contaré la historia que nos ha traído a la situación actual. Me ha quedado un post algo largo, pero prometo al lector paciente que es todo “lean”, sin circunloquios ni banalidades.

Agile nace gestado por la Primera Burbuja Punto.com

Agile nació poco después de que creciese la Primera Burbuja Punto.com. Agile apareció como una metodología para que las consultoras pudiesen gestionar de alguna forma su relación con clientes que no sabían exactamente lo que querían. Agile no se inventó durante la década de los sesenta para el Programa Apolo porque la misión era poner a un hombre en la Luna antes del 1 de enero de 1970. No necesitaban una sucesión de lanzamientos con mejora contínua de los resultados. Sí necesitaban, en cambio, nuevas herramientas como IBM IMS para gestionar el inventario del Saturno V o las metodologías estilo Waterfall de los 70 que siguieron vigentes durante muchos años tras su invención. Pero en el año 2000, con clientes que no sabían ni a qué planeta querían llegar o, peor aún, cambiaban el planeta de destino según avanzaba el proyecto, era muy difícil hacer un inventario de necesidades y presupuestarlas. Entonces se inventó algo para facturar al cliente no una cantidad fija por proyecto cerrado sino por “time & materials” (horas/hombre y cualquier otro coste imputable) sin límite presupuestario. Obviamente, si el cliente pagaba por horas en lugar de por resultados era necesario demostrarle que los programadores estaban trabajando de la forma más eficiente posible. Y de ahí surgieron todas las prácticas ágiles para optimizar la productividad de los programadores exprimiéndoles como cítricos.

Agile emigra a las grandes corporaciones

Aproximadamente un lustro después de que las consultoras introdujesen Agile, los gestores de proyectos de los clientes empezaron a pensar que si la metodología funcionaba tan estupendamente para las consultoras entonces funcionaria igualmente bien para los proyectos internos de la compañía. Como las grandes empresas cambian despacio, les llevó aproximadamente otros cinco años, hasta 2010, entrar de lleno en la cruzada por el agilismo.

Fué en este momento cuando se empezó a complicar la cosa. No es lo mismo hacer un proyecto táctico para un departamento de una gran corporación que un megaproyecto de transformación empresarial de gran calado. Las consultoras web muy a menudo trabajaban para directores de desarrollo de negocio que estaban frustrados con la lentitud de su servicio de informática interno respecto de la velocidad que había tomado el mercado. Querían soluciones rápidas de negocio, y no les importaba si estaban bien o mal integradas con el resto de los sistemas de la casa. Sólo buscaban correr para no perder el tren de Internet. Agile primaba la entrega sobre la calidad, porque la consultora tenía un tiempo de vida limitado para conseguir algún éxito rápido antes de que les cancelasen el proyecto o fuese absorbido por el departamento de informática del cliente. Pero a un mando intermedio de una gran empresa casi nunca le conviene priorizar la entrega sobre la calidad por dos motivos: a) vive permamentemente en competencia por el ascenso con otros mandos quienes están siempre pendientes para descubrir dónde se ha equivocado; y b) a las empresas les cuesta tanto cambiar organizativamente que la velocidad de desarrollo no es casi nunca un cuello de botella. Es más, el tiempo de codificación sólo supone, como mucho, el 30% o el 40% del tiempo de trabajo de un programador. Al obcecarse con reducir el tiempo de programación se optimiza sólo el 30% del tiempo y no se hace nada respecto del otro 70%. Entonces, el cliente puede acabar pagando “time & materials” de programadores quienes, siendo muy eficientes en su labor, pasan no obstante una fracción significativa de su tiempo esperando.

Se eliminan los gestores de cuenta

Los vendedores y gestores de cuenta en las consultoras provocaban con frecuencia el siguiente problema serio: en un caza de combate el piloto puede normalmente hacer sólo tres o cuatro maniobras de alta velocidad antes de agotar su reserva de combustible y tener que volver a la base. Análogamente, los gestores de cuenta tenían tendencia a pulsar el botón que activaba la postcombustión cada vez que se veían al borde de ganar o perder una cuenta porque les faltaba esta o aquella funcionalidad en el producto. Esto dejaba a los programadores quemados y agotados y encima con frecuencia no servía para lograr los objetivos comerciales deseados. Tras una serie de motines de los programadores, la solución fue quitar el poder a los gestores de cuenta para dárselo a los programadores.

Se decidió que los programadores debían hablar directamente con los clientes, ya que los gestores de cuenta entendían y trasladaban mal los requisitos. Y que los programadores debían auto-organizarse fijando sus propios objetivos y estimaciones. ¡Bien! ¡Poder para el pueblo!

Se decidió también que los programadores podían programar y reunirse con los clientes al mismo tiempo. De todas formas si no se reunían con el cliente se tenían que reunir con el gestor de cuenta lo cual es casi lo mismo ¿no?

De nuevo, esto funcionó bien para las consultoras. Más horas hablando con el cliente estrechaban el vínculo emocional con él y proporcionaban más información a la consultora para hacer venta cruzada.

Pero ¿qué pasó en los grupos de trabajo de los clientes? Bien. Lo que sucedió fué básicamente que Agile tomó el control estratégico de la empresa. En lugar de un equipo directivo fijando la visión y misión y un equipo operativo tratando de ponerla en práctica, la empresa pasó a estar gobernada por un grupo de ejecutivos desvalidos que mendigaban al cognitariado agilista si era posible hacer esto o aquello. Cualquier intento de dirigir la empresa fuera de los límites de Agile era vaticinado como una hecatombe segura por el Oráculo Agile. Y así Agile pasó a convertirse en una cuestión de fé.

Respecto de la comunicación, si las empresas ya estaban saturadas de reuniones, Agile potenció todavía más reuniones. Y además introdujo la idea de que los usuarios pueden (y deben) crear las historias «de usuario». El problema es que los usuarios carecen normalmente de formación en diseño estructurado de sistemas y, por consiguiente, no pueden crear una especificación de calidad porque nadie les ha enseñado cómo hacerlo. Tienen un conocimiento experto de su negocio, pero necesitan coaching de un analista-programador para plasmar dicho conocimiento en un papel.

Se veta a los senior

Una consultora obtiene beneficios de la diferencia entre lo que le cobra al cliente y lo que le paga a sus empleados. Por consiguiente, una consultora rentable es, por definición, una horda de juniors. No todas las consultoras son así, por supuesto, algunas son boutiques de un puñado de verdaderos expertos, pero si la consultora tiene más de 10 empleados entonces el 80% de ellos son junior porque las consultoras existen tanto para hacer lo que el cliente no sabe hacer como para que éste les lance toda la basura que no quiere procesar.

Los senior tienen mala cabida en una metodología Agile. No da tiempo en un único sprint de producir un buen análisis o una arquitectura de software para un proyecto complejo. Además, la presión constante por alcanzar el sprint abona el terreno a peligrosísimos errores de diseño. Agile microgestiona a los senior obligándoles a acudir a reuniones diarias de control. Y es fácil eliminar miembros de alto potencial identificándoles falsamente como de bajo rendimiento simplemente porque no siguen a pies juntillas los sprints por absurdos que estos sean.

Un cliente con sistemas de información complejos quiere personal senior entre sus empleados. Quiere arquitectos capaces de aprehender todas las interacciones sutiles entre una miriada de sistemas de información y de adquirir una visión holística desde el alto nivel de las necesidades de negocio hasta los detalles de la electrónica de red. Esto simplemente no casa con Agile.

Se introducen métricas envenenadas

Junto con Agile, se introdujeron ciertas “prácticas Agile”. Algunas ya existían previamente con otro nombre, estilo las retrospectivas antaño conocidas como post-mortems, excepto que el nombre era muy tétrico y por eso se cambió y se le añadieron al método algunas viñetas graciosamente elocuentes.

Algunas prácticas fueron definitivamente un avance: Domain Driven Design, Integración Contínua, Refactorización, etc. Otras introdujeron caballos de Troya.

El primer troyano fueron las Historias de Usuario. En la época del diseño estructurado se abogaba por estimar el esfuerzo requerido usando métricas como los Puntos Función o la Complejidad Ciclométrica. Los puntos función, básicamente, consistían en medir la complejidad de los datos de entrada y los datos de salida y estimar que el esfuerzo requerido para desarrollar un programa sería proporcional a la complejidad requerida para manipular los datos. Algunas empresas como IBM llegaron a poder producir estimaciones muy fiables para determinado tipo de proyectos con estas métricas. Pero en las Historias de Usuario no se trataba tanto de estimar el esfuerzo requerido como el valor que aportaría al cliente la funcionalidad. Esto era debido a que la consultora estaba interesada en cobrarle al cliente no por su coste de producción más un márgen sino por el valor añadido. Hablando de valor y no de coste se evitaba que el cliente dejase a la consultora cobrando “time & materials” más un 15%. Pero en los proyectos internos en grandes empresas el valor que añade cada funcionalidad es mucho menos relevante puesto que las grandes empresas casi siempre operan en oligopolios que pueden repercutir sus sobrecostes a los clientes. Lo que sí es crucial es saber cuándo estará terminado y qué hará, debido a que puede que se avecine una campaña de Navidad o una salida a bolsa. Pero ese ¿cuándo? y ¿qué? es justamente lo que NO garantiza Agile. En cambio, la sucesión interminable de releases incompletas lo que acaba generando es una profunda desazón en los usuarios y patrocinadores quienes empiezan a tener la sensación de que el proyecto no estará terminado nunca.

El segundo troyano fue Test Driven Design (TDD). No es que TDD sea para nada malo en sí mismo. De hecho, ningún programador profesional hoy en día escribe código sin un juego de tests que lo acompañe y eso es por muy buenos motivos demasiado largos y técnicos para enumerarlos aquí. El problema de TDD fué que generó la idea de que el código estaba «listo» cuando estaba «listo para lanzárselo a control de calidad» como quien pasa una patata caliente. Si pasaba los tests entonces el código funcionaba, fin de la historia. La mil veces repetida excusa de los programadores «en mi PC funciona» pasó a ser «pasa los tests». Gracias a la integración continua, todas las máquinas virtuales podían tener fácilmente la misma configuración, luego ya no sucedía que funcionase en una si y en otra no, pero pasar los tests no implicaba que el programa hiciese en absoluto lo que el cliente esperaba que hiciese, pues, cómo ya hemos explicado anteriormente, quién había redactado la historia de usuario no sabía explicar exactamente lo que necesitaba. De postre, los tests escritos por el programador nunca incluyen pruebas de carga, puesto que son muy tediosas de escribir y además bloquearían el sistema de integración continua. De modo que incluso si el software funciona en producción lo hace a la velocidad de un trasatlántico a pedales.

El tercer troyano fueron los Product Backlogs. Estos priorizaban la aceptación de cambios y el desarrollo sobre la planificación. La forma en la que un backlog fuera de control aniquila un proyecto la describí en otro post titulado lo que sucede cuando un software se convierte en un agujero negro, de modo que no voy a extenderme aquí sobre este punto.

Se arregla Agile con más Agile

Como corolario de todo lo anterior, la situación típica es una de las siguientes:

a) Si la empresa es pequeña, el CEO ha caído prisionero de los programadores. Cada vez que intenta pedir algo, los programadores le responden que debe conseguir más recursos, o más inversión ¡o traer menos clientes! porque no les da tiempo de atenderles.

b) Si la empresa es grande, hay una gran cantidad de proyectos bloqueados a la espera de que un tercero entregue algo. El proyecto avanza, pero lo hace a una velocidad exasperantemente lenta y no exenta de sobresaltos.

El diagnóstico siempre es invariablemente el mismo: no se está haciendo Agile correctamente. Pero ¿quién puede hacer Agile correctamente? y… ¿de qué manera? si ya se ha intentado todo y se han mantenido sempiternas reuniones.

Entonces ¿Cómo salvar el proyecto?

1. Se deja de esperar a que los usuarios produzcan ninguna especificación. En cambio, se asignan analistas para trabajar con ellos en la producción conjunta de especificaciones.

2. Cada sprint durará lo que tenga que durar. ¿Por qué dos o tres semanas? Tampoco seis meses, para evitar los sustos que daba Waterfall. Puede haber puntos de control intermedios, pero si se necesitan ocho semanas para producir algo estable, se necesitan ocho semanas, y no cuatro sprints de dos semanas.

3. Se resucitan los Gantt, si ¡horror! Se restituyen los análisis de caminos críticos que muestren quién está bloqueando a quien y dónde. Se instalan pantallas gigantes que muestren en tiempo real el grado de progreso del sprint, los retrasos acumulados, el estado de los tests de integración y la actividad de usuarios en producción.

4. Se para en seco la aceptación de nuevas funcionalidades hasta que se estabilicen por completo todas las que hay. Es decir, desde mañana y hasta nuevo aviso los cambios NO son bienvenidos en la planificación del proyecto.

5. La decisión sobre la fecha de release pasa al departamento de control de calidad. Será este, de común acuerdo con los usuarios, quien valide que el software producido cumple con los requisitos.

6. La misión de sprint es cumplir expectativas. Al cuerno con la verborrea sobre valor añadido al negocio o restricciones técnicas insalvables. No se acepta ninguna excusa técnica ni organizativa en el último minuto para justificar por qué el cliente no obtendrá lo que esperaba obtener.

7. Cada programador arregla los bugs que él mismo haya introducido. Además, no gozará de más tiempo sobre el que tuviera pre-asignado a sus tareas. El programador no sufrirá penalización salarial ni de carrera profesional por un bug, pero tendrá que arreglarlo haciendo horas extra no retribuidas.

8. Se diseñan informes que muestren claramente cuánto tiempo se está dedicando a : desarrollo, corrección de bugs, soporte a cliente y reuniones. En la contabilidad analítica se diferenciará claramente el coste de producción del coste de soporte.

9. Quedan abolidas las reuniones. En lugar de una metodología que fomente que la gente se reuna y hable con la mayor frecuencia posible, se intenta que los programadores tengan que ir al mínimo número de reuniones. Como máximo una por semana. No se puede ser creativo y explicar lo que se está haciendo al mismo tiempo. El daily se substituye por un chat online donde todos los programadores y gerentes puedan acceder de forma inmediata a cualquier otro miembro del equipo en caso de necesidad urgente.

10. Los programadores son obligados a documentar lo que están haciendo. Si bien no están obligados a estar cada dos por tres de pie en una sala, sí deben mantener actualizado un repositorio documental con el progreso y detalles de todo su trabajo ya que no existe tal cosa como el código autodocumentado. La herramienta puede ser JIRA, Redmine, un wiki o incluso un blog donde los programadores compartan sus progresos en lugar contarle a nadie lo que están haciendo o enviar un mail a una lista y crear un hilo interminable. Evitar las reuniones no implica desinformarse. El desafio es mantener a todo el mundo informado sin necesidad de mantenerlo permanentemente reunido.

11. Se añade una capa de metodología de optimización global sobre Agile.

12. Se decreta la Anarquía de los Programadores. Podrán reirse a carcajadas de una decisión. Podrán ser sorprendidos trabajando en cosas aparentemente no relacionadas en absoluto con el proyecto. Podrán soñar con dragones.

Posts relacionados:
Las zonas grises de Agile.
Cheat Sheet de marrones en un proyecto.

El oportunismo del agilismo (Luis Lobo).

Publicado en Organizando la Comunidad. Modelos de Desarrollo | Deja un comentario

Sobre la dinámica social en los sitios de dating

Publicado el 26 de mayo de 2016 por Sergio Montoro

He estado tentado de titular este post cómo ligar en sitios de dating. Mucha gente busca una relación estable o casual. Pero a mi lo que me interesa es el uso social de la tecnología para conocer gente, concretamente del sexo opuesto en el caso de los sitios de dating.

¿Funcionan realmente los sitios de dating? Bien, no existen pruebas científicas a favor o en contra. Yo creo que sí funcionan. La razón es que si no funcionasen entonces no habrían sobrevivido más de una década ya desde sus inicios. A principios de 2016 un 5% de los norteamericanos casados o en una relación estable reconocían haber conocido a su pareja online. Según PEW Research Centre el número de adultos usuarios de los sitios de dating se ha duplicado entre 2014 y 2016. El gráfico muestra cómo la opinión de los usuarios se ha vuelto más favorable de 2005 a 2013 Pero ¿funcionan los sitios de dating con efectividad? Eso seguro que no. Y a continuación explicaré algunas causas de su ineficiencia.

El mito de Mr. Right

Fué Cortázar quien escribió: “Lo que mucha gente llama amar consiste en elegir una mujer y casarse con ella. La eligen, te lo juro, los he visto. Como si se pudiera elegir en el amor, como si no fuera un rayo que te parte los huesos y te deja estaqueado en la mitad del patio”. Y si hay un lugar donde las personas se eligen unas a otras ese lugar son las redes de dating. No está demostrado que exista ningún cuestionario ni check-list que sirva para seleccionar a la pareja adecuada. Varias redes de dating proclaman que tienen algoritmos de matching basados en similitudes de edad, ingresos, profesión, etc. y en tests de personalidad estilo 16PF o MMPI. Pero no hay datos que demuestren que una persona tiene más probabilidades de mantener a largo plazo una relación con otra si ambas son muy similares. Lo que sí parece comprobado es que es falso que los polos opuestos se atraen. Si uno cocina y limpia y el otro sólo come, probablemente acabarán mal. La relación sin embargo sí puede funcionar cuando hay complementariedad (uno cocina y el otro friega los platos). Según un estudio de la Universidad de Chicago, existe una fuerte afinidad por raza con tan sólo un 4% de matrimonios interraciales en EE.UU. Los caucásicos tienen ligeramente más probabilidades de ser elegidos por la mayoría de las otras razas aunque con importantes excepciones como hindues y coreanos.

Sin perjuicio de lo anterior, existen decenas de sitios especializados por perfiles: casaderos, gays, fetichistas, gorditos, yuppies, hipsters, amish o hasta capitanes de barco.

Amish Dating

Sea Captain

La Paradoja de la Elección

La Paradoja de la Elección es un efecto psicológico que provoca una tendencia a estar menos satisfechos con nuestras adquisiciones mientras más alternativas existan. Es por eso que Tinder tuvo tanto éxito limitando la cantidad de candidatos mostrados. Es mejor hacer una preselección y trabajar con un subconjunto de aspirantes. Probablemente la tasa de abandono de mujeres en Match y Meetic está relacionada con la avalancha de inmails que pueden llegar a recibir.

Factores predominantes en la elección

Según los estudios, los hombres con perfil dominante (machos alfa) puntúan mejor a primera vista aunque no está tan claro que luego sean los preferidos para formar pareja estable. Sin embargo, las fotografías agresivas, mirando de frente a la cámara con cara de pocos amigos, intimidan a las mujeres quienes pueden preferir imágenes de hombres con la mirada desviada en el momento de tomar la imagen. Otro factor comprobado en estudios es que incluir niños en las fotografías incrementa la percepción de atractivo del varón. Es decir, el mismo hombre es percibido como más atractivo en la foto por el mismo grupo de mujeres si aparece un niño a su lado.

En cuanto a las fotografías femeninas, prima la estética. Hombres y mujeres tienen tendencia a mentir en media más o menos por igual en los perfiles, excepto en las fotografías donde las mujeres mienten muchísimo más. Según algunos estudios hasta el 46% de las fotografías femeninas no son fidedignas frente al 11% de poco o nada realistas en los hombres.

Las mujeres aprecian el sentido del humor. Existe una correlacion demostrada entre la cantidad de risa que un hombre es capaz de inducirle a una mujer y la probabilidad de que acaben pasando la noche juntos. El recíproco, sin embargo, no es cierto. Si en un bar se encuentra a un hombre desternillándose de la risa con una mujer probablemente ella acabe volviendo a casa sola.

Aunque prima lo visual sobre lo textual, sobre los textos, tanto hombres y mujeres están de acuerdo en que prefieren información personal y relevante alejada de frases hechas y hobbies comunes. Las personas no conectan tanto por coincidencia en grandes temas vitales como por afinidad en muchos pequeños detalles.

Factores imponderables

Muchos de los críticos con las redes de dating afirman que las cualidades verdaderamente relevantes para estimar la viabilidad de una pareja simplemente no pueden medirse a través de Internet. La más citada es el olor de la otra persona. Parece ser que las personas con sistemas inmunes complementarios se atraen mutuamente. Otros factores como el uso del espacio, la forma de andar o la forma de comer tampoco suelen desvelarse hasta la primera cita. Yo personalmente opino que el factor que mejor sirve para predecir cómo es una persona en la cama consiste en observar qué y cómo come, aunque eso sería otra larga historia muy subjetiva.

Tiempo dedicado a buscar online

Aunque no existen datos proporcionados por los portales, preguntando a los usuarios cuando están activos parece ser que se conectan unas 12 veces por semana durante 22 minutos en cada sesión. Y en Francia en 2015 tanto como un 30% de los encuestados reconocía haber visitado un sitio de dating en los últimos tres meses. Por edades los más jóvenes son el grueso de usuarios seguidos de los más mayores y por último las personas de mediana edad. No está clara cual es la distribución de hombres y mujeres. Cuando se filtró la base de datos de Ashley Madison trascendió que tanto como el 80% de los usuarios eran hombres, aunque otras cifras afirman que la cantidad de mujeres es igual o sólo ligeramente inferior a la de hombres.

Si se examina el modelo de negocio de los sitios de dating es fácil deducir que lo más provechoso para el proveedor es que el uso esté gamificado de tal manera que los usuarios tengan una tasa de éxito lo bastante elevada como para quedarse enganchados pero no tan elevada como para acertar a la primera y abandonar el sitio debido a muerte por éxito.

Timadores

Las redes de dating, como cualquier otro lugar en el mundo, no están exentas de peligro. Se puede encontrar de todo pero los perfiles más comunmente peligrosos son los tres siguientes:

El timador económico. La dinámica de timo más común es contar una historia triste y conmovedora. Al cabo de un tiempo pedir una pequeña cantidad. Por ejemplo, 50€ o 100€ para pagar una presunta factura de la luz. Y por último inventar una gran catástrofe sobrevenida del tipo «tengo a mi hijo en el hospital y no tengo dinero para el tratamiento». La pequeña cantidad se pide porque es sabido que las personas que ya han hecho una aportación previa tienen más probabilidades de aceptar hacer otra mayor.

El narcisista y el sociópata. De todos los enfermos mentales que se pueden encontrar online probablemente el narcisista y el sociópata son probablemente los más peligrosos debido a que no resulta para nada sencillo detectarlos tempranamente.

El irresoluto. Este último no es un tipo realmente peligroso. Sólo hace perder el tiempo. Uno de cada tres usuarios de las redes de dating afirma que nunca ha tenido una cita en la vida real. Algunas personas quedan online porque sólo quieren quedar online.

Desvirtuación de otras redes sociales

No sólo se liga en redes de dating. Cada vez son más los usuarios de LinkedIn que se quejan de lo poco profesional que se ha vuelto la red en una deriva hacia perfiles cool del estilo de A Small World. Conozco al menos un caso de alguien que abrió una cuenta de Twitter sólo para compartir fantasías sexuales. Y también es común entre los gamers que una relación que comienza matando bichos en un mundo virtual evolucione hacia unas tapas en un bar. En Facebook los anuncios de sitios con énfasis sexual estan prohibidos lo cual incluye anuncios de sitios de dating que muestren fotos provocativas.

Conclusiones

Como en tantas otras áreas de innovación, la tecnología ha evolucionado más rápido que la capacidad de los usuarios para adaptarse a ella y todavía existe un largo camino por recorrer tanto en el funcionamiento de los servicios como en el aprendizaje de los usuarios para sacar el mejor provecho de ellos. Aunque todavía representa un porcentaje minoritario como medio de establecimiento de relaciones, el dating online está creciendo como mucha fuerza especialmente entre los más jóvenes. Una evolución que a mi personalmente no me parece ni intrínsecamente buena ni mala sino una consecuencia inevitable de la globalización de un mundo en el que nos relacionamos cada vez menos por proximidad geográfica y más por afinidad en otros parámetros.

Un estudio analiza qué funciona para ligar en Tinder (Daniel Mediavilla)

Publicado en Usos sociales de la tecnología | 2 comentarios

Tax Loans

Publicado el 26 de mayo de 2016 por Sergio Montoro

Leo en eldiario.es un certero artículo de Marta Sofía Ruiz aclarando la diferencia entre el EBITDA y el beneficio real en las empresas. Trata sobre la esencia del mecanismo principal para evadir impuestos legalmente en la actualidad.

Los impuestos se recaudan por la diferencia entre ingresos y gastos (no tendría sentido intentar cobrarle a alguien que tiene muchos ingresos pero ningún beneficio). Los gastos incluyen costes financieros (intereses). Entonces una forma de reducir el beneficio (aka no pagar impuestos) es tener una enorme deuda y, por consiguiente, muchísimos costes financieros. He aquí la clave que comenta el artículo de eldiario.es: las punto com son empresas cuyo EBITDA es positivo (ergo cotizan al alza en bolsa) pero en el cierre contable después de intereses e impuestos arrojan pérdidas (ergo no pagan impuestos).

Se trata de una regulacion legal perversa mediante la cual, aunque tengas mucho dinero, lo más eficiente fiscalmente es estar endeudado. Es por eso que incluso las empresas que tienen cantidades ridículamente altas de caja mantienen deuda.

El patrón no se aplica sólo a las empresas. En el Reino Unido, desde hace ya casi una década, y en España según se ha descubierto tras los papeles de Panamá, existe mucha gente que cede sus ingresos a cambio de una renta. En la jerga legal británica se conoce como los tax loans. El mecanismo es como sigue: tú eres autónomo, y vas a firmar un contrato, supongamos de 200€/día por 6 meses. A 22 días por mes igual a 26.400€ de ingreso bruto (más IVA). Entonces haces lo siguiente: pides un préstamo por 20.000€ a una empresa off-shore con un interés del 10% anual. Como garantía de este préstamo pones tu nómina pero de manera que tú nunca llegues a percibir el ingreso. Es decir, el cliente debe pagarle a la off-shore directamente. Fiscalmente, tienes una deuda de 21.000€ (20.000+intereses) y la off-shore debe de reconocer el ingreso pero como está radicada en un paraíso fiscal no tributa. Para que el trabajador tenga cobertura en la seguridad social, la off-shore subcontrata a una empresa en el país que le paga al sujeto pasivo un salario muy bajo, pongamos por caso 20€/día. El resultado neto es un coste real entre el 15% y el 18% para el (no)contribuyente. Puede que ni siquiera se aplique el IVA ya que la venta de servicios entre países intracomunitarios está exenta. Y es todo “legal”. O más bien “legal” sobre el papel. Pues existe un principio de derecho que establece que las cosas son «lo que son» y no «lo que las partes dicen que son». Es por esto que un juez puede limpiarse el trasero con una carpeta de facturas por muy “legales” que sean si en realidad no se corresponden con ningún producto o servicio real o se emitieron con el único fin de eludir el pago de impuestos.

En el Reino Unido le han dado a los listillos de plazo hasta 2019 para dejar en cero sus tax loans y están tratando de llegar a acuerdos negociados de amnistía fiscal (pagando el 10% y esas cosas…) para evitar difíciles batallas judiciales con los implicados ya que con la ley actual no está claro que Hacienda pueda ganarles en un juicio. Algunos tienen un serio problemilla porque, puestos a endeudarse a costa de la nómina, pidieron un préstamo para el Jaguar, el ático en la costa y los costes del divorcio, y, claro, ahora el HMRC (la AEAT en UK) les reclama una cantidad en decenas de miles que no tienen en la cuenta bancaria. Y como llevan haciéndolo años están dentro del rango de delitos fiscales punibles con cárcel. Sin embargo, no llegará la sangre al rio porque hay tanta gente pringada a todos los niveles que a nadie le interesa que se destape todo el cotarro.

La raíz del problema, no obstante, es un sistema fiscal inapropiado donde las personas jurídicas están obligadas a una presión fiscal excesiva. Debido a que no se pueden poner puertas al campo en una economía globalizada, el impuesto de sociedades debería estar siempre por debajo de los costes financieros. Esto implicaría dejar dicho impuesto en una horquilla entre el 3% y el 5%. Ya sé que esto suena completamente impopular ¡Mosquis! ¿No sería eso acaso reducir la presión fiscal sobre los multimillonarios y sus grandes empresas? Pues no. Resulta que el beneficio de una empresa no es de nadie. Bueno, es de la empresa, pero ese es el dinero que la empresa tiene para crecer y generar empleo. Gravándolo al 35% lo único que se consigue es que a las empresas les resulte más rentable estar perennemente endedudas, con el consiguiente riesgo que eso acarrea. El único momento en el que se debería fiscalizar el beneficio es cuando se reparte entre los accionistas bien sea via nómina, dividendos o retribución en especie. Por último, mantener una empresa (o a uno mismo) permanentemente endeudada hasta las trancas es peligroso pues pone a la empresa a merced de los acreedores (bancos y otros aún más fieros) en el caso de que se desplomen los ingresos por causas impredecibles.

Publicado en Análisis Financiero del Software Libre | 1 comentario

Entradas Populares