miércoles, 29 de abril de 2015

Diversidad y creatividad

Una de las claves de la creatividad es la capacidad para conectar conocimientos, ideas y experiencias procedentes del pasado y utilizar el resultado para afrontar una situación nueva.

Ya rozamos esta idea al hablar de la inspiración y calificarla como mito ya que esa inspiración no era 'pura' sino que se apoyaba en la experiencia.

También rozamos esta idea al hablar de la educación y razonar cómo una educación, incluso de calidad, pero estandarizada, impedía destacar y ser realmente creativo y diferencial.

Abundando un poco más en esa línea de pensamiento que nos ofrece Fred Cook en su libro 'Improvise', una forma de enriquecer nuestra experiencia y, por tanto, aumentar nuestra capacidad creativa es fomenta la diversidad en nuestras relaciones y actividades. En esa línea nos dice:

Humans create original ideas by connecting existing information in new ways. The more data you store away are better. If you expose yourself to unfamiliar people, places and things, you expand the personal Internet inside your head.


Aunque existen personas expansivas y amantes de la novedad, lo cierto es que la tendencia natural es a rodearse de un círculo de personas similares con las que nos sentimos cómodos. Sin embargo, Cook nos advierte:

If you expend all your time with people who are like you, you won't learn how to deal with people who aren't (or don't) like you.


Así que, una receta para mejorar nuestra creatividad es, simplemente, fomentar la diversidad.

¿Simple?

Bueno, quizás no tanto...

Depende de personalidades. 

Pero puede ser interesante intentarlo.

En un próximo post veremos algunas de las originales recetas que nos propone el autor para ayudarnos a diversificar experiencias y relaciones.

lunes, 27 de abril de 2015

La inspiración como mito

A estas alturas ya no nos extraña, porque ya empieza a ser casi un lugar común el hecho de que la inspiración pura, la idea maravillosa surgida de la nada, es posible y que la creatividad es, por tanto, una especie de don, un regalo de la naturaleza.

Cada vez tenemos más claro que el trabajo constante, la transpiración versus la inspiración, tiene también un papel más que relevante en el proceso creativo y en la innovación.

Más aún, además del trabajo, es importante nuestro 'background', el acervo de estudios y experiencias que nos acompañan. Y es que en esa especie de legado o de almacén de conocimientos y experiencias podemos encontrar soluciones o ideas para problemas nuevos.

En su libro 'Improvise', Fred Cook hace especial hincapié en lo que a experiencia, experiencias mejor dicho, se refiere como fuente de la creatividad.

Y así, en esta línea de pensamiento nos dice:

brilliant ideas aren't created in a vacuum. They're formed by the experiences we have and the people we meet.

Creo que es así, toda experiencia, sea directa, obtenida por vivencias y relaciones, sea indirecta, obtenida por lectura o estudio, aumenta nuestros recursos, nuestras posibilidades creativas, porque nos proporciona algo así como un mapa de caminos posibles, una caja de herramientas para afrontar los desafíos.

La inspiración pura probablemente sea un mito, o al menos es muy escasa, pero eso no es ninguna desgracia sino todo lo contrario. Si la creatividad se apoya en el esfuerzo y en las experiencias, está en nuestra manos el mejorarla...

viernes, 24 de abril de 2015

La educación como commodity

No es lo que creemos, no es lo que nos han dicho y, simplemente, no es lo que debería ser...pero tal vez la educación no impulsa tanto nuestro talento ni nuestra carrera profesional como pudiéramos, justamente, pensar.

En el mundo laboral pueden aplicar las mismas reglas que en otros mercados. Y si en la mayoría de los mercados, tal y como desde hace ya muchos años nos enseñaba el pensamiento estratégico de Michael Porter, es fundamental la diferenciación, ¿qué nos hace pensar que en el mercado laboral las cosas pueden ser diferentes?

En el mundo laboral puede ser crucial aportar diferenciación, originalidad, ideas, innovación, cosas que nos hacen diferentes. Al menos lo son si aspiramos a posiciones de liderazgo o a sobresalir de alguna manera,

Sin embargo, la educación que recibimos, aunque pueda ser de calidad, no ayuda a diferenciarnos. 

¿Por qué?

Simplemente, porque es muy parecida para todos.

Esta es, al menos, la desafiante tesis con la que Fred Cook abre su libro 'Improvise. Unconventional career advice from an unlikely CEO'.

Nos dice:

People entering the business world today are a commodity. They've gone to the same schoools, taken the same courses, read the same books, and watched the same movies.
...
Meanwhile, companies like mine are desperately seeking fresh minds...

En próximos posts hablaremos de la receta que propone Fred Cook pero, si nos mantenemos dentro del círculo de la educación, y una educación más o menos convencional, una primera receta para la diferenciación iría en el doble sentido de la cantidad y la amplitud.

Cantidad en el sentido de más formación. No por la cantidad por sí misma, sino porque el conocer más temas, aparte de valioso per se, aporta perspectiva y capacidad de aportar nuevos puntos de vista.

Y amplitud en el sentido de buscar formación desde un punto de vista más multidisciplinar, más extenso...casi por las mismas razones que en el apartado anterior: porque mientras más variados sean los conocimientos, no sólo se es más flexible y más todoterreno, sino porque, de nuevo, puede servir para aportar nuevos enfoques.

Al final, incluso en entornos de buen nivel educativo, mucho depende del individuo, de su esfuerzo, su búsqueda y su desarrollo individual.

No obstante, veremos que la línea argumental de Cook va por otros derroteros...

miércoles, 22 de abril de 2015

Perspectivas y definiciones sobre calidad de servicio en telecomunicaciones

La calidad es un atributo del que realmente existen muchas perspectivas... y no necesariamente correctas... ni coincidentes. No suele ser lo mismo la calidad percibida por un cliente que la calidad objetiva medida, y tampoco suele ser coincidente el entendimiento de la calidad desde un punto de vista de marketing o desde un punto de vista de operaciones o fabricación.

O quizá coincidan más de lo que parecen...pero adoptando diversos puntos de vista.

En el ámbito de las telecomunicaciones esto se complica un poco más porque, en este sector, y desde una perspectiva muy de red, la calidad de servicio (QoS, Quality Of Service) tiene su propio significado relacionado con la diferenciación de tráficos y su tratamiento diferenciado, como ahora veremos.

Por eso, me ha gustado encontrar, y quería recoger en este blog, las diferentes perspectivas y definiciones que sobre calidad de servicio ofrece Toni Janevski en su libro 'NGN, Architectures, protocols and services'.

Son cuatro:

1.- La definición de la ITU-T


QoS is the totality of the characteristics of a telecommunications service that bear on its  ability to satisfy the stated and implied needs of the users of the service.

Una definición algo vaga...pero correcta y que pone en relación las características del servicio con el cliente.

2.- La perspectiva de la red

La siguiente perspectiva que nos ofrece el autor es la de la red, con un concepto que aplica mucho precisamente en el ámbito de redes IP en general y de NGN en particular:

Qos can be defined as the ability for segmenting traffic or differentiating between traffic types in order for the network to treat certain traffic flows differently from other.

Este sentido es al que me refería más arriba y es muy propio de las telecomunicaciones.

3.- La satisfacción del usuario

Esta perspectiva es, si se quiere, más marketiniana, más inespecífica y más subjetiva.:

QoS can also be defined as a criterion of the degree of user satisfaction of the offered service.

Y parece que vale como concepto de calidad de servicio para casi cualquier sector.

4.- La ingeniería de tráfico tradicional

Finalmente, una nueva perspectiva muy cercana a la red:

QoS refers to measurable parameters and techniques to select, control (e.g. via an admission control), measure, and guarantee the required quality for a given service.


Parecen muy diferentes, pero en realidad son diferentes perspectivas, diferentes puntos de vista y todas las definiciones tienen que ver entre sí más de lo que parece. Veamos:

  • Nuestro objetivo último es el cliente y su percepción sobre el servicio (a esto se refiere la definición 3)

  • Ahora bien, dejando aparte aspectos emocionales, intangibles o de percepción, que también existen, se entiende que la calidad percibida por el cliente tiene que ver con una serie de características del servicio (definición 1) 

  • Objetivar y garantizar esas características nos lleva a establecer y medir una serie de parámetros (definición 4) 

  • Y, en el caso de redes generalistas, redes sobre las que se ofrecen muchos servicios diferentes, cso de la Red IP/NGN, el poder garantizar esos parámetros nos lleva a, como primer paso, poder separar y tratar de forma diferenciada, flujos de información correspondientes a servicios diferentes con unos requisitos de calidad diferentes (definición 2).

Visto así parece que todo encaja, ¿no?

De las cuatros perspectivas/definiciones, tres son muy propias del ámbito de las telecomunicaciones, y todas parecen todas bastante heterogéneas entre sí. Sin embargo, y si bien se piensa, solo son, en el fondo diferentes perspectivas. y diferentes gestiones para un único fin: el cliente.


lunes, 20 de abril de 2015

El sueño IP

Hace ya muchos años trabaja yo en Telefónica Investigación y Desarrollo, una empresa especial donde las haya y donde me encontraba rodeado de profesionales jóvenes y brillantes, muy conocedores de tecnologías y tendencias.

En un momento dado asistí a una conferencia interna donde me contaron un sueño: el sueño IP.

Las telecomunicaciones eran entonces mucho más sencillas...aunque ya empezaban a dar síntomas de lo que iba a ocurrir después.

El caso es que en aquella época, aún el Servicio Telefónico Básico era muy importante. No estoy seguro de si ya se había lanzado el ADSL y en cuanto a comunicaciones móviles creo que aún se mantenía la telefonía móvil analógica mientras el GSM, el estándar digital, se abría paso. 

Internet ya estaba presente...pero nada que ver con la ubicuidad actual. Conocíamos el TCP/IP y servicios como FTP, News, Gopher, Telnet y si, también algo de WWW, 

El caso es que en aquel entorno y en la conferencia que menciono, algunas de las personas ,más conocedoras de las telecomunicaciones en general, y de las comunicaciones móviles en particular, nos hablaban de que el futuro sería de los protocolos de Internet, del IP y todos los que le rodean. 

Y no sólo lo aplicaban a las comunicaciones fijas, cosa que aunque aún algo futurista, ya se vislumbraba. No, también nos hablaban de que el IP se utilizaría en las comunicaciones móviles y nos hablaron de la convergencia tecnológica fijo y móvil.

Entonces me resultó sorprendente y estimulante, algo así como un sueño tecnológico: el sueño del IP ubicuo, convergente, universal...

*****

Estoy acabando la lectura del libro 'NGN Architectures, protocols and services' de Toni Janevski, donde se explica la NGN (Next Generation Network), una red, una arquitectura, en realidad, que ya está aquí y que, tal y como la describen, no es más que una arquitectura que se basa en una red todo IP en la que se imbrican protocolos, servicios, y diferentes tecnologías de acceso, fijo y móvil...un acceso, incluyendo el móvil, que también se apoya en IP.

Y he recordado el sueño de aquella conferencia en Telefónica Investigación y Desarrollo.

Y he caído en la cuenta de que se ha hecho realidad.

Casi no había reparado en ello, pero aquella predicción, aquel sueño, se ha materializado.

Probablemente mis colegas hablaban con conocimiento de causa. Probablemente, ellos mismos estaban involucrados e influyendo en los organismos de estandarización que han ido produciendo, a lo largo de de los años, protocolos, tecnologías y estándares que han conducido a esta solución final. Probablemente hayan contribuido a modelar ese futuro que ya es presente. A lo mejor han sido más constructores que adivinos.

Es posible.

Soñadores, en cualquier caso.

Soñadores de una tecnología que se ha hecho realidad.

Soñadores de un mundo IP que ya está aquí.

viernes, 17 de abril de 2015

Reflexionando sobre ingeniería de software con Frederick P. Brooks Jr.

'The mythical man-month' son una serie de reflexiones y ensayos sobre los grandes proyectos de software, su organización y gestión, y algunos de los mitos y concepciones erróneas que les acechan.

Escrito por Frederick P. Brooks, quien fuera responsable del desarrollo del sistema operativo IBM OS/360, queda patente a lo largo de toda la obra que el que habla tiene un conocimiento profundo y real, basado en la experiencia, sobre la materia.

Estamos ante un libro ya vetusto, con su versión original publicada en 1975 y una revisión, ésta, la edición del veinte aniversario, que vio la luz en 1995. A pesar de los años transcurridos, una eternidad en tecnología, gran parte de las ideas y fundamentos siguen vigentes aunque, por supuesto, se aprecia en pequeños detalles el paso del tiempo y la evolución del sector.

El libro se estructura en 19 capítulos:
  • 'The Tar Pit': analiza la diferencia entre la programación de componentes separados o pequeños programas realizados en garages y startups frente a una producción de gran escala de productos y sistemas. También se detiene en las motivaciones, placeres y molestias de la programación.

  • 'The Mythical Man-Month': resalta el optimismo casi patológico que afecta a la planificación inicial de los proyectos software y por qué añadir recursos a un proyecto de software retrasado, normalmente lo único que consigue es retrasarlo más.

  • 'The Surgical Team': Hace una propuesta arriesgada en cuanto a la forma de organizar un equipo dedesarrollo software a imagen y semejanza de los equipos que realizan intervenciones quirúrgicas. Define el número aproximado, los roles y funcionamiento.

  • 'Aristocracy, Democracy and System Design': Se adentra en el concepto de integridad conceptual, defendiendo la importancia de un concepto unitario en el diseño del sistema.

  • 'The Second-System Effect': Advierte sobre el peligro de querer añadir demasiadas funcionalidades innecesarias a un producto en su segunda versión.

  • 'Passing The Word': analiza la diferencia y uso de la prosa frente al lenguaje formal y diferentes aspectos de comunicación de los conceptos dentro del equipo de desarrollo.

  • 'Why Did The Tower of Babel Fail': analiza aspectos de comunicación, documentación y organización

  • 'Calling the Shot': se detiene en la problemática de la productividad de los equipos mencionando y comentando algunas aportaciones de terceros.

  • 'Ten Pounds in a Five-Pound Sack': estudia aspectos relativos al tamaño del software, un problema que quizá hoy día tiene poca importancia pero que en el momento del desarrollo del OS/360 y de la redacción del libro, sin duda era relevante.

  • 'The Documentary Hypothesis': Vuelve a la temática de la documentación, identificando los documentos que considera imprescindibles según el tipo de proyecto.

  • 'Plan To Throw One Away': desarrolla una teoría que defiende que la primera versión de un software complejo normalmente está destinada a eliminarla (suele ser muy lenta, muy grande, y difícil de usar), que el sistema adquiere su madurez y utilidad a partir de la segunda versión y que, por tanto, se debe planificar teniendo este hecho en cuenta. En relación con esto plantean también temáticas relacionadas con el cambio.

  • 'Sharp Tools': se detiene en aspectos más de detalle como los entornos, las librerias, los lenguajes y las herramientas.

  • 'The Whole and the Parts': se centra fundamentalmente en la temática de las pruebas y la depuración del software.

  • 'Hatching a Catastrophe': aborda aspectos relativos a la monitorización y seguimiento del proyecto y a la prevenvión de desviaciones y retrasos.

  • 'The Other Face': retorna a la problemática de la documentación, incluyendo la documentación de usuario.

  • 'No silver Bullet- Essence and Accident in Software Engineering': un interesantísimo ensayo, originalmente publicado de forma independiente en 1986 en "IFIP Tenth World Computing Conference" pero incluido en el libro y cuya tesis es que no se avista ninguna solución milagrosa para incrementar de forma radical la productividad, fiabilidad o simplicidad del software. El ensayo analiza algunas técnicas y tendencias que pueden conseguir mejoras, pero manteniendo la posición de que ninguna de ellas será realmente disruptiva.

  • '"No Silver Bullet" refined': revisa y analiza los comentarios y críticas recibidas por el artículo original.

  • 'Propositions of The Mythical Moan-Month: True or False?': resume las ideas principales de todo el libro, capítulo por capítulo

  • 'The Mythical Man-Month After 20 Years': hace una análisis en retrospectiva de las ideas del libro, aquellas que considera siguen plenamente vigentes y aquellas en que el autor reconoce haberse equivocado o haber reconsiderado.

'The Mythical man-month' es una obra profunda y en muchos momentos amena, creo que muy acertada en su enfoque e ideas (aunque el propio autor reconoce que a alguna de ellas el tiempo les ha quitado la razón), una obra serena, equilibrada y basada en la experiencia que creo constituye una lectura imprescindible para jefes de proyecto de software o todo aquel con algún tipo de responsabilidad en el mundo del software y los sistemas.

Todo un tesoro de conocimiento, ideas y sentido común.

Frederick P. Brooks Jr.

(Fuente: Traducción y ligera elaboración propia a partir de Wikipedia)

Frederick Phillips Brooks, Jr. (nacido el 19 de abril de 1931) es un ingeniero de software y científico de la computación, más conocido por dirigir el desarrollo del sistema operativo OS/360, y después escribir honestamente sobre el proceso en su famoso libro The Mythical Man-Month (El mítico hombre-mes). "Es una experiencia humillante el cometer un error de coste multimillonario, pero es también muy memorable." Brooks recibió el Premio Turing en 1999 "por sus contribuciones a arquitectura de computadores, sistemas operativos e ingeniería del software."

Nacido en Durham, Carolina del Norte, asistió a la Universidad de Duke, licenciándose en 1953. Se doctoró en matemática aplicada por la Universidad de Harvard en 1956. Howard Aiken fue su director de tesis.

Brooks se incorporó a IBM en 1956, trabajando en Poughkeepsie y Yorktown, Nueva York. Trabajó en la arquitectura del IBM 7030 (un supercomputador científico de $10M para el Laboratorio Científico de Los Alamos) y los computadores Harvest, para después dirigir el desarrollo de la familia de computadores System/360 y el software que ejecutaban.

Fue en The Mythical Man-Month cuando Brooks hizo su famosa observación: "Añadir personal a un proyecto retrasado lo retrasará aún más." Desde entonces, esto se ha venido conociendo como la "Ley de Brooks." Además de The Mythical Man-Month, Brooks es conocido por su ensayo No Silver Bullet, sobre ingeniería del software.

En 1965, Brooks dejó IBM para fundar el Departamento de Ciencias de la Computación en la Universidad de Carolina del Norte en Chapel Hill del que fue decano durante 20 años. En 2004 estaba aún implicado en actividades investigadoras, principalmente en realidad virtual y visualización científica. En enero de 2005 impartió la clase magistral anual Alan Turing ante la IEE/BCS en Londres, sobre "Colaboración y Telecolaboración en Diseño".

Puedes saber más sobre el autor consultando visitando su página en la Universidad de Carolina del Norte en Chapel Hill.

Ficha técnica:
Artículos de este blog relacionados

jueves, 16 de abril de 2015

#macrotweet: la necesidad de un plan de proyecto

The first step in controlling a big project on a tight schedule is to have a schedule, made up of milestones and dates for them.

Frederick P. Brooks Jr.
'The mythical man-month'

miércoles, 15 de abril de 2015

Gestionar mentes


El factor humano es diferencial en gran cantidad de actividades. 

Lo es para bien... y en ocasiones para mal. Nos permite alcanzar los mayores logros, pero también experimentar las mayores dificultades.

En su libro 'The mythical man-month', Frederick P. Brooks, Jr. hace esta afirmación

managing large programming projects is qualitatively different from managing small ones, just because de number of minds involved.


En la cita original, esta frase no tiene una gran importancia. Le sirve al autor para introducir los problemas de la complejidad de gestión de grandes proyectos software y revisar su propuesta de conformación de equipos.

Pero a mi me ha dejado pensando la expresión 'number of minds'. 

Y me llama la atención porque el autor no ha elegido la palabra 'people' (personas), o 'programmers' (programadores), o 'resources' (recursos) o 'team members' (miembros del equipo)...

Haber elegido cualquiera de las palabras anteriores referiría fundamentalmente a un problema únicamente de número, de escala y, quizá, de interrelación. Sería un asunto básicamente cuantitativo.

Pero no.


No sé si intencionadamente, el autor ha elegido la palabra 'minds' (mentes).

Y una mente nos habla de una persona, una inteligencia y una personalidad. Nos habla de sentimientos, nos habla de motivaciones, nos habla de creatividad, nos habla de voluntad...

Y eso es, realmente, mucho más difícil de gestionar que simplemente un número, por grande que éste sea.

Gestionar mentes supone una mucho mayor exigencia de conocimientos, de habilidades, de liderazgo,..

Para gestionar mentes, no bastan solamente técnicas u organización. 

Para gestionar mentes se necesitan otras mentes, otras personas.

Factor humano para sacar lo mejor del factor humano...

lunes, 13 de abril de 2015

El software y la segunda ley de la termodinámica

A estas alturas tengo bastante olvidados los fundamentos de la termodinámica, pero vagamente recuerdo  dos cosas acerca de la entropía.

Una, que la entropía, de alguna forma, representa el desorden de un sistema... o del universo.

La segunda es que, según la segunda ley de la termodinámica, la entropía tiende siempre a aumentar, no disminuir.

Busco, en efecto la formulación del Segunda Ley de la Termodinámica en wikipedia y me encuentro:

La cantidad de entropía del universo tiende a incrementarse en el tiempo.

Y ahora vuelvo mis ojos al mundo del software y a lo que de él nos dice Frederick P. Brooks Jr. en su libro 'The mythical man-month'. Y, ya hacia el final del libro, cuando el autor está recapitulando las enseñanzas que ha intentado transmitir, y hablando del mantenimiento del software, afirma lo siguiente:

All repairs tend to destroy structure, to increase the entropy and disorder of a system.

¿Podía ser de otra manera?

El software es un sistema y, como hemos visto, un sistema caracterizado por su complejidad. Es casi científicamente poético pensar que el software aplique principios de la termodinámica. Pero lo cierto es que a medida que evoluciona la funcionalidad, a medida que se corrigen errores y aplican parches, el software tiende a deteriorarse. 

Quizá es que se pierde esa integridad conceptual de que ya hablamos en su momento, quizá es que se pierde conocimiento e incluso cuidado a medida que el código original pasa por varias manos... o quizá es que, simplemente, no se puede ir en contra de las leyes de la física.

Lo cierto es que el software se deteriora con el mantenimiento... y acaba convirtiéndose en obsoleto, inservible y, paradójicamente, inmantenible.

Triste para el arquitecto o desarrollador iniciales...pero buenas noticias para los desarrolladores en general, para el sector en general. Si el software se deteriora, hay que hacer nuevo software que lo sustituya... y la rueda, y el negocio, siguen girando.

Así, y ahora sí que poéticamente vamos a contradecir a la física y a su conservación de la energía, el software sólo se crea y se destruye...pero no se transforma (bueno, no mucho).


viernes, 10 de abril de 2015

#macrotweet: sobre el papel del gestor de equipos

The manager's function is not to make people work, it is to make it possible for people to work.

Frederick P. Brooks Jr.
'The mythical man-month'


miércoles, 8 de abril de 2015

Software y complejidad

El software es algo casi mágico: moldeable, flexible, potente... 

...y sin embargo es también una fuente casi inagotable de quebraderos de cabeza: proyectos que se retrasan casi sistemáticamente, 'bugs' que resisten cualquier depuración, comportamientos inesperados, 'cuelgues'... y degradación con el uso.

¿Qué pasa con el software?

Quizá simplemente le hemos perdido injustamente el respeto, quizá lo hemos menospreciado y lo hemos considerado algo familiar y del día a día, al alcance de todos cuando, en realidad, el software es enormemente sofisticado.

En su libro 'The mythical man-month', Frederick P. Brooks Jr. nos lo dice de forma muy clara: se trata de que el software es, por naturaleza, complejo.

The complexity of software is an essential property, not an accidental one.

Y no es extraño. Una gran parte de la magia del software es su capacidad de adaptarse a situaciones y datos diferentes. Ese comportamiento flexible y aparentemente inteligente indica una lógica compleja y una gran cantidad de combinaciones y caminos posibles. Por eso mismo, no sólo se trata de que sea inherentemente complejo sino que, además, dicha complejidad crece mucho con el tamaño, cuando los caminos se multiplican:

Many of the classical problems of developing software products derive from this essential complexity and its nonlinear increases with size.

Y si esto ya lo hace difícil de producir y mantener, Brooks nos apunta una última dificultad de cara al diseño:

software is difficult to visualize

Es decir, trabajamos con una materia intangible, muy compleja, con muchas variantes y caminos y queremos aprehenderlo en nuestras mentes...pero no se deja visualizar ni reducir fácilmente a esquemas.

¿A alguien le puede extrañar que sea de tan difícil gestión? ¿Nos sorprende que no se deje domesticar?

Desde un punto de vista de gestión y dirección de proyectos no podemos dejar de lamentarlo pero, seamos sinceros y reconozcamos, aunque sólo sea por un momento que, para nuestra alma de desarrolladores, para nuestra vena de innovación, esa complejidad, ese reto, esa dificultad...forman parte también de la magia...

lunes, 6 de abril de 2015

Hardware versus software: ¿Quién corre más?

Es indudable el ritmo acelerado de innovación al que están sometidas las tecnologías de la información tanto en lo relativo a hardware y materiales, como a software y aplicaciones.

Ambas facetas avanzan a gran velocidad pero ¿hay alguna que corra más que otra?

No tengo datos que lo avalen pero sí tengo la sensación de que la tecnología software, no las aplicaciones, sino la tecnología e ingeniería de software propiamente dichas, están algo estancadas. Tengo la sensación de que dado el rapidísimo avance del hardware, dado que las capacidades de todo tipo de dispositivos crecen rápidamente, el software simplemente 'se aprovecha' y gana en prestaciones y posibilidades no tanto por méritos propios como por lo que el hardware ofrece.

Algo se avanza probablemente en lo que a productividad se refiere, pero no tanto en tecnología pura.

Por el contrario es sorprendente la velocidad a que avanza el hardware. Cómo se gana en capacidad de procesamiento y en velocidad, cómo se avanza en miniaturización, en optimización del uso de la energía o en nuevos materiales y tecnologías como la táctil.

Insisto en que son meras impresiones, y discutibles,..pero que no puedo evitar.

Hace ya muchos años, en su libro 'The mythical man-month', Frederick P. Brooks Jr. parecía contemplar un parecido fenómeno. Sin embargo, me gusta su enfoque que más bien concedía el mérito al hardware, más que hablar de un demérito del software.

Esto es lo decía:

the anomaly is not that software progress is so slow but that computer hardware progress is so fast.

Ésto lo afirmó hace muchos años, pero creo que sigue siendo válido, que aún tiene razón. El hardware parece avanzar más rápido que el software... pero probablemente lo admirable sea realmente la velocidad del progreso del hardware y no tanto el ritmo, probablemente menor, de avance del software.

viernes, 3 de abril de 2015

Lo que tu jefe necesita saber de tu proyecto

Por supuesto, existen muchas naturalezas de proyectos, muchos jefes y muchos estilos de gestión, pero como regla general, si quieres saber qué debes contar a tu jefe o a la alta dirección sobre tu proyecto, puedes seguir la sencilla receta que nos proporciona Frederick P. Brooks Jr. en su libro 'The mythical man-month':

every boss need two kinds of information, exceptions to plan that require action and a status picture for education.

Así de sencillo. Sólo dos cosas:

  • estado del proyecto

  • excepciones que requieren actuación

Desde luego, es una receta simplificada, pero eficaz. Añadiría que si, además, las excepciones no son demasiado frecuentes y si el plan se cumple, tu jefe vivirá muy tranquilo... y tú también...


miércoles, 1 de abril de 2015

Usar y tirar: un duro pero quizá inevitable peaje de la innovación

Cuando innovamos, cuando creamos algo nuevo, es fácil y hasta deseable, enamorarnos de nuestra idea, de nuestro producto, de nuestro intento.

Pero a pesar de nuestra pasión, ese primer intento suele estar condenado al fracaso.

Aparte de la imprevisibilidad de clientes y mercados, la propia naturaleza humana parece poco preparada para la proyección y la planificación minuciosa. Parece que funcionamos mejor de forma empírica, ensayando, fallando y aprendiendo.

Y eso se refleja, por ejemplo, cuando construimos un nuevo sistema software, cuando creamos un nuevo concepto o utilizamos una nueva tecnología. A pesar de nuestro empeño e ilusión, el resultado no suele ser satisfactorio... y debemos tirarlo.

Por ello, al innovar conviene estar preparado, e incluso planificar, para hacer un primer prototipo, e incluso una primera versión de producto para usar y tirar.

En esta línea se manifiesta Frederick P. Brooks Jr, en su libro 'The mythical man-month' cuando nos dice:

Where a new system concept or new technology is uded, one has to build a system to throw away, for even the best planning is not so omniscient as to get it right the first time.

Hacer esa primera versión nos ayuda a depurar el proceso y la propia idea. Y su lanzamiento nos brinda la oportunidad de recibir feedback de mercados y clientes.

Decíamos que ese primer intento suele estar condenado al fracaso... pero eso no significa en absoluto el fracaso del proyecto, ni de la idea, ni de la innovación. Aunque no sea lo más eficiente, sí parece ser lo más efectivo comenzar por un primer producto o versión de usar y tirar y, con el aprendizaje obtenido, desarrollar una nueva versión que, si la suerte y el acierto nos acompañan, ya tiene posibilidades de ser un éxito.

'Dura lex sed lex' (ley dura pero ley) que nos decía el derecho romano...