Los retos de la innovación

La innovación pretende ser la respuesta a un entorno que cambia continuamente y que cada día lo hace más deprisa. A estas alturas muchos negocios no tienen más remedio que hacer innovación para mantenerse en el mercado, tarde o temprano el resto también tendrá que hacerlo.
Comentar algunas cosas que parecen evidentes, pero que no lo son tanto:

• La innovación debe ser continua, no basta con tener una buena idea y que tenga unos resultados buenos o aceptables. Incluso si se convierte en un gran éxito, tarde o temprano, las cosas cambiarán. Conformarse con lo conseguido es la mejor forma de quedarse atrás, y tarde o temprano, fuera del mercado. Por lo tanto, hay que tener presente que hacer innovación supone adquirir un compromiso que tiene muchas metas intermedias pero ninguna final. La innovación no es el camino para enriquecerse en poco tiempo y con poco esfuerzo (el llamado pelotazo).
• Innovar no es sólo una idea, no es sólo la tecnología, hay que tener muy presentes a los clientes, a los usuarios. La idea o la tecnología son sólo algunos de los miembros de la ecuación, si se pretende sacar algo adelante sin tener en cuenta a aquellos a los que va dirigido, puede quedarse sólo en eso una idea, algo que no se sabe a quién puede interesar, o que realmente no interesa a nadie.
• La innovación requiere de algunas aptitudes personales que hay que cultivar. Entre las más importantes estarían las siguientes: Creatividad, evidentemente tiene que haber ideas, por lo tanto no hay mucho más que decir. Curiosidad, por las cosas, por aprender, por estar al tanto de las novedades, no sólo en el campo que corresponda a cada uno, también de la actualidad en general, es importante conocer nuestro entorno, a las personas que lo componen, de hecho ningún saber está de más. Proactividad, hay que actuar, no se puede estar a la espera de que llegue algo del exterior que nos indique o facilite el camino. Hay que ser motores del cambio, no espectadores de éste.

Technorati tags: innovacion

Programación y comunicación

Cuando se desarrolla software la comunicación es muy importante. Hay comunicación a muchos niveles, y en ocasiones las personas que participan en el desarrollo pertenecen a profesiones distintas, en las que se emplean conceptos y enfoques muy diferentes a los de los técnicos informáticos. Sin embargo, en este comentario me voy a centrar en la comunicación entre los miembros del equipo de desarrollo, y en concreto la que tienen que mantener los analistas, arquitectos o diseñadores con los programadores.
Quiero comentar esto porque en principio puede parecer que de todos los tipos de comunicación posibles, éste debería ser uno de los menos problemáticos, y suele ser así, no obstante uno se encuentra también con ciertos problemas.

El que uno considere esta comunicación más sencilla, se debe a que los analistas y diseñadores han sido o son aún programadores, y por tanto se supone que conocen la forma de transmitir sus ideas a los programadores. Esto es razonable y suele facilitar las cosas, pero no siempre sale bien. Supongamos el siguiente caso, se tiene una aplicación en producción a la que hay que hacer unos cambios para incorporar una nueva funcionalidad. El desarrollo se deja en manos de un analista y un programador. La idea es que el analista plantee las necesidades y el programador las implemente siguiendo la arquitectura y diseño que ya emplea la aplicación.
Un analista describe un sistema empleando un vocabulario y unos conceptos propios del análisis, mientras que un programador suele pensar en términos del lenguaje de programación que conoce o tiene que usar. Suele ocurrir que los programadores tienen menos experiencia y sólo conocen (si los conocen a fondo) lenguajes de programación (pueden conocer lenguajes como UML, pero si no los emplean normalmente tampoco servirá de mucho, eso de: 'Sí, en la carrrera he dado UML', no suele funcionar). La distancia existente entre ambas mentalidades puede quedar más clara si uno piensa en un analista con varios casos de uso, y un programador intentando identificar clases, operaciones y variables en las elipses, líneas y monigotes del caso de uso.

Una vez que el analista tiene terminado el análisis, y comienza a explicárselo al programador, o simplemente se lo pasa y espera a que éste pregunte, se puede dar cuenta de que su lenguaje no funciona, que el programador no termina de entender el análisis, el programador quiere ver cosas como clases y operaciones. Ante esta situación, el analista opta por bajar a su nivel y empieza a diseñar con el programador. Esto suele acabar con el analista describiendo las cosas al más bajo nivel, aquel que entiende el programador, el de las clases y operaciones que hay que usar y si aquí se usan parámetros por valor o por referencia. En este punto el analista ha olvidado el análisis, y se ha convertido en un programador más. Esto no tendría que salir mal, de hecho parece funcionar si el analista conoce bien el lenguaje y el diseño de la aplicación. El problema está en que el programador puede seguir sin enterarse de qué van los cambios. Entiende que aquí va la clase FooBar, con las operaciones foo y bar, que foo llama a foo2, ... etc., pero el problema está en que no sabe por qué debe haber una clase FooBar, por qué debe tener las operaciones foo y bar y por qué foo debe llamar a foo2. Tarde o temprano tendrá que tomar alguna decisión por sí mismo, ya que en la implementación aparecerán cosas que no habló en su momento con el analista, y hará suposiciones que sólo podrá basar en su limitado conocimiento del problema, basado en detalles de implementación que le no permiten ver el bosque.

Esto no es un caso extremo, es un problema real y recurrente. El no tenerlo en cuenta es una garantía de su continua aparición.

Technorati tags: programacion

Web semantica: Ampliando los horizontes de la web

La web semántica se plantea como una extensión de la web actual, con el objetivo de ampliar considerablemente las posibilidades actuales para tratar la gran cantidad de información que hay en la web.
La web actual está claramente dirigida a las personas. Los consumidores de la información existente en la web son las personas, lo que exige que sean éstas las que accedan a la web para obtener e interpretar la información disponible en ésta.
Con la web semántica se posibilitaría que fuesen los programas los que accediesen a la web, recuperasen la información existente en ésta, y la tratasen. Estos programas se les conocen como agentes, y se dedicarían a realizar tareas de carácter automático a partir de la información existente en la web.

Los principales elementos que hacen posible las web semántica son:

• RDF (Resource Description Framework): Es un lenguaje que permite expresar cosas. Cada expresión está compuesta por tres elementos. Se puede establecer una correspondencia de estos elementos con los componentes que se pueden encontrar en una frase simple del lenguaje humano. En muchas de las frases que utilizamos las personas para comunicarnos podemos identificar un sujeto, un verbo y un complemento que extiende el propósito del verbo. En las expresiones RDF, sus tres elementos vienen a representar estos papeles: el de sujeto, verbo y predicado. Así podríamos decir algo como: logos escribe en su blog.Tendríamos a 'logos' como sujeto, 'escribe' como verbo, y 'en su blog' como complemento. RDF por sí solo permite agrupar estos elementos, lo que se necesita ahora es algo que permita determinar qué son esos tres elementos, que los identifique de manera clara, para que no exista confusión sobre lo que son y podamos empezar a entender lo que se está tratando de expresar. En primer lugar están los URI.
• URI (Uniform Resource Identifier): Un URI es una notación que permite identificar de forma única algo, sin importar de lo que se trate. En el ejemplo anterior, habría que usar un URI para cada uno de los tres elementos de la expresión en RDF. El uso de un URI para cada elemento, establece con claridad cuáles son estos elementos. Lo que se pretende es que el significado de la expresión sea claro, por tanto, hay que identificar con claridad cuáles son los elementos que la componen, para así poder determinar el significado de cada uno. Un ejemplo de URI podría ser una URL (Uniform Resource Locator), es decir, la dirección que pone en el navegador para acceder a una página de la web. De hecho una URL es un tipo de URI, ya que permite identificar la página de forma única (lo que hace que una URL sea algo más que una URI, es que además permite localizar aquello que está identificando). Una vez que se tienen identificados los componentes de la expresión en RDF, hay que encontrar el significado que tienen, para ello están las ontologías.
• Ontologías: Las ontologías permiten expresar el significado de un conjunto de términos y las relaciones existentes entre ellos. Una vez que se tiene identificado un término mediante una URI, se emplean las ontologías para expresar su significado, y la relación que tiene con otros términos que puede haber en el dominio que queremos representar.
• Lógica: Un último elemento que dota de muchas posibilidades a la web es el uso de una lógica que permita obtener nueva información a partir de la información existente, combinándola y extrayendo el resultado. Mediante le empleo de una lógica de primer orden, los agentes pueden recorrer la web, recopilando información, para después tratarla y obtener la información de interés que puede concluirse a partir de la información original.
  

Lo anterior es un repaso rápido a lo que se llama web semántica. La web cambiará mucho en los próximos años. Desde los buscadores, que gracias a la web semántica permitirán hacer búsquedas más inteligentes (no como las actuales, que se basan principalmente en la aparición de palabras en las páginas), a los servicios web, los cuales van convirtiendo la web en un lugar no sólo para las personas, sino también para los agentes, que permitirán explotar la información disponible en la web para construir multitud de servicios y aplicaciones.

Tecnorati tags: web semantica, web

Combatiendo el spam con spam

Este artículo habla de una de las características del FairUCE de IBM. Según se comenta en el artículo, con esta herramienta se pretende combatir a los spammers en su propio terreno, mediante el envío masivo de spam al propio spammer, con el objeto de saturar las máquinas desde las que envía el spam.
No he podido encontrar la referencia en el The Wall Street Journal, y en la página de la herramienta tampoco habla de esta característica. Además es extraño porque en el propio artículo se menciona el hecho de que en USA, algo así podría tener problemas legales al tratarse de una forma de denegación de servicio (DOS).

En cualquier caso, la idea me parece un disparate. Son varios los motivos:

• Muchas de las máquinas que envían spam no son de los spammers, son máquinas en las que los spammers han conseguido infiltrar un programa para el envío automático de spam. Con lo cual, los spammers lo único que tienen que hacer es buscar nuevas máquinas, y lo que se habrá conseguido es dejar fuera de servicio a algún usuario inocente, que posiblemente no entienda qué le pasa y se dedique a reiniciar la máquina. Si además trabaja con dhcp, puede acabar con otra ip desde la que podrá empezar de nuevo a enviar spam.
• Incrementaría considerablemente el tráfico en Internet. Para tener éxito en un ataque de denegación de servicio hay que superar la capacidad de la máquina objetivo. Si por ejemplo ésta tuviese capacidad para tratar 100 correos por minuto, puede que para saturarla haya que enviarle 150, con lo cual hemos inutilizado una máquina que enviaba 100 correos poniendo otra que envía 150. En este punto además, me surge la duda del tipo de ataque DOS a emplear, ya que muchas máquinas que envían spam, no aceptan correos entrantes, por lo que habría que emplear otro tipo de ataque, esto requiere determinar a qué tipo de ataque DOS puede ser vulnerable la máquina.
• Para llevar a cabo este tipo de medidas se requieren bastantes recursos, en términos de máquina y ancho de banda, ya que pueden ser decenas o centenares los spammers de los que recibimos correos. Por lo tanto, hay que hacer cuentas para ver si el coste que tiene esta forma de combatir el spam compensa. ¿Mejora con creces las herramientas actuales? ¿Qué efectividad tiene? ¿La han probado ya? ¿En un escenario real?
  
• Otro problema puede darse si el spam no es identificado correctamente, y se toma por spam lo que no es. Se estaría inutilizando un servicio que no tiene nada que ver con el spam.
  
• Un sistema capaz de realizar ataques de este tipo, podría ser empleado para atacar otros sistemas, por lo que sería un objetivo muy deseable para los crackers. Bien sea tomando el control de estos sistemas, o simplemente engañándolos para que identifiquen como fuente de spam un determinado objetivo, los crackers tendrían en sus manos una herramienta poderosa para atacar a los objetivos de interés.

No creo que hagan falta más motivos, la idea es que hay que buscar otras vías para combatir el spam, vías de caracter constructivo. Como dijo Gandhi, si aplicamos el ojo por ojo, todos acabaremos ciegos.

UPDATE: En este enlace también comentan algo, pero no es exactamente lo mismo. Al final va a resultar la típica noticia que es malinterpretada por los medios cuando no comprenden suficientemente los aspectos técnicos del asunto.

Technorati tags: spam, dos, internet

Blogs y los medios de comunicación tradicionales

Del estudio aparecido recientemente sobre medios de comunicación. Uno de los aspectos más comentados es el de la fuerza de los blogs y cómo éstos desplazan en ocasiones a los medios escritos tradicionales.

Los medios tradicionales tienen que plantar cara allí donde les conviene, deben reconocer las ventajas (recursos, personal cualificado, ...) que poseen frente a los blogs y explotarlas. Pretender competir con los blogs en su terreno es una pérdida de tiempo. Sin embargo, si aprovechan las ventajas que tienen consiguiendo atraer a los internautas hacia aquellos contenidos que un blog no puede ofrecer, tendrán mucho ganado en esos otros contenidos que en principio son más fáciles de explotar por parte de los blogs. Es algo que hacen los buscadores, y muchos otro sitios de Internet. Ofrecen un conjunto de servicios con idea de atraer usuarios. Éstos pueden estar en principio interesados en alguno de ellos, pero con el tiempo pueden empezar a usar todos los demás, bien por comodidad o por la confianza que le inspira el proveedor.

Hay millones de blogs, pero el número de los que son seguidos por un número considerable de internautas es bajo. En mi opinión, el éxito de la blogosfera está soportado por el interés que suscitan esos blogs, y el hecho de que cualquiera pueda tener el suyo, aunque no tenga demasiado seguimiento. En cualquier caso, estos blogs de éxito creo que tienen asegurado su seguimiento. Detrás de ellos hay una o más opiniones que han sabido ganarse el interés de los internautas y tendrán su lugar junto al resto de medios de información. En este sentido, son similares a las columnas de opinión de los medios escritos, pero además hacen uso de un lenguaje informal (que no suelen emplear los columnistas de los medios escritos) con el que consiguen establecer una relación más estrecha y personal con el lector. Esto es un ejemplo de cómo los blogs han tenido éxito modificando un formato que venían explotando desde hace mucho los medios escritos. Lo cual no quiere decir que le haya restado valor, o su sitio, a las columnas de opinión de los medios escrito, tan sólo que con un retoque de este conocido formato están teniendo bastante éxito.

En definitiva, en Internet hay sitio para una gran variedad de formatos y contenidos. Cada uno debe encontrar su espacio, o creárselo, y estar con los ojos bien abiertos, porque esto cambia muy deprisa y aún hay mucho que ver.

Technorati tags: blog

El ambiente de trabajo

El ambiente de trabajo es uno de los elementos que más influyen en la productividad de un equipo de desarrollo software. Y creo que en ocasiones no se le presta la suficiente atención. El desarrollo de software comparte con otras profesiones la necesidad de un espacio que facilite la concentración, la reflexión, la creatividad, ..., habilidades intelectuales, que además requieren de la motivación de la persona para su buen desempeño.

Aunque estas habilidades dependen de la persona, se ven influenciadas para bien y para mal, por el ambiente del lugar de trabajo. Hay muchas cosas que se pueden hacer para mejorar esto, pero las que normalmente he echado en falta son las siguientes:

• Un entorno que al menos no fomente las distracciones. En esta caso una de las fuentes de distracción más importante son las personas, las cuales pueden ser ajenas al grupo de trabajo o pueden pertenecer a él.
  
• Falta de medios, que obligan a los desarrolladores a realizar más trabajo del necesario para lograr resultados, o simplemente les impiden alcanzar los resultados que se les exigen.

A todas estas cosas debe poner remedio el responsable del grupo de trabajo, que es además el primer interesado en que su grupo obtenga los resultados esperados.

Se suele mencionar el concepto de flujo (flow) cuando se habla del estado mental que se requiere para alcanzar resultados óptimos en el desarrollo de software. Me gustaría apuntar unas cuestiones sobre esto:

• No todos los desarrolladores alcanzan este estado, o lo hacen de forma permanente. Pero los resultados de los que lo hacen suelen destacar.
• Las deficiencias existentes en el lugar de trabajo, son un obstáculo para que las personas entren en este estado, o logren mantenerlo el tiempo suficiente. En este estado no se entra automáticamente, pero sí se sale con facilidad debido a las interrupciones y distracciones.
  

Para todo lo anterior recomiendo el libro Peopleware de Tom DeMarco y Timothy Lister.

Technorati tags: programacion

Libros de desarrollo software

Hay una cosa que considero importante en cualquier campo de conocimiento, y que veo deficitaria en el campo de la ingeniería del software. La escasez de libros de cierto nivel, escritos y traducidos al español.

La mayoría de los libros que adquiero, y sobre todo, de los que he aprendido más cosas, son libros en inglés, y que además he podido comprar gracias a Internet.

Si se pasea por una librería técnica en España, la mayoría de los libros están dedicados a un lenguaje de programación, la administración de la última versión de un determinado sistema operativo, o el manejo de la última versión de los programas de oficina y multimedia más habituales.

El tipo de libros que encuentro de interés no son éstos, sino los que tratan de temas más generales: gestión de proyectos, requisitos, análisis, arquitectura, diseño, programación, pruebas, etc. , y que traten el tema sin estar ligados a un lenguaje o plataforma. Tengo libros de todo tipo, y tengo muy claro cuáles son los que siguen teniendo vigencia, los que me siguen aportando cosas con el paso de los años.

Lo que me sugiere esto, es que si estos libros no están en el mercado, es porque no tienen demanda, y si no la tienen es porque no hay interés en su contenido por parte de los profesionales. Lo que puede dar una idea de los recursos de estos profesionales, de los conocimientos y habilidades que poseen. Con esto no quiero generalizar, conozco gente (poca) que sí se interesa por estos temas. Pero esto supone leer libros y documentación en inglés, y son pocos los que lo hacen por iniciativa propia.

Hay gente que considera que todo lo que necesita está en Internet, y ciertamente en Internet hay mucho material, pero no está todo, y hay muchos temas de los que en Internet sólo se ofrecen apuntes o introducciones, en los que no se alcanza la profundidad ni la extensión que tienen en los libros. Internet es en muchos casos un lugar en el que se ofrece información que pueda ser asimilada o digerida en poco tiempo y con poco esfuerzo. Esto hay que tenerlo presente si no se quiere caer en el error de pensar que con haber leído un par de artículos ya se conoce un tema. Esto puede ser válido para algunas cosas pero hay otras, que suelen ser las que más perduran, que no se adquieren con un par de apuntes sacados de Internet. Y además, no todo está en Internet, muchas de las cosas que he aprendido en los libros, algunos de los cuales llevan ya muchos años publicados, no están en Internet. No olvidemos que en muchos casos son contribuciones de alguien que conoce un tema, y que quiere obtener una ganacia económica a cambio de sus conocimientos, por lo que los derechos del autor sobre la obra impiden su libre distribución.

Technorati tags: programacion, libros

El neolítico del desarrollo software

Mientras más programo más convencido estoy de que se podría conseguir el mismo resultado sin tener que escribirlo tanto código. No me estoy refiriendo a programar mejor, me estoy refiriendo al hecho de que una gran parte de la información que es expresa mediante código, podría expresarse mediante otro tipo de lenguajes y herramientas que ofreciesen un nivel de abstracción mayor.

Hablo de neolítico porque cada día tenemos mejores IDEs para escribir, compilar, depurar y controlar las versiones de los fuentes y productos. Pero todo se sigue moviendo alrededor del código, hemos pulido las herramientas, pero hay que dar un salto cualitativo, hay que pasar de la piedra a los metales para poder afrontar los retos que tiene el desarrollo de software en una sociedad cada vez más dependiente de su software. Tengo muy presente la frase y comentarios de Frederick P. Brooks en "No Silver Bullet". Esto no resolverá todos los problemas del desarrollo software, muchos no tienen su origen en la tecnología, y su solución no es tecnológica, pero el paso del que hablo no sólo es posible, sino necesario, aunque no sea la panacea.

Para que todo esto no sea demasiado abstracto voy a hablar de la propuesta del OMG llamada MDA. La propuesta consiste en convertir a los lenguajes de modelado (como UML) en el centro de gravedad del proceso de desarrollo. El objetivo es que los modelos sean la herramienta básica del desarrollador, que le valgan para realizar la mayor parte de su trabajo. Los lenguajes de modelado son lo suficientemente potentes y abiertos como para poder descargar en ellos esta 'responsabilidad'. Por ejemplo, UML es un lenguaje que proporciona varios mecanismos de extensión (estereotipos, valores etiquetados, restricciones, perfiles UML) que permiten aprovechar de muchas maneras la información contenida en sus modelos, entre ellas, la de automatizar muchas de las tareas actuales de programación, no sólo la generación de código.
Por otra parte, en MDA se hace hincapié en el uso de varios tipos de modelos, destacan aquellos que no están vinculados a una tecnología concreta (PIM-Platform Independent Model), y aquellos que representan los sistemas empleando una tecnología concreta (PSM-Platform Specific Model).
Otro aspecto destacable de MDA es que formaliza los mapeos entre los modelos, es decir, el conocimiento necesario sobre una determinada tecnología, que permite pasar de un PIM a un PSM está en las herramientas de desarrollo, de forma que el paso de uno a otro puede ser en gran parte automático, lo que implica no sólo un importante ahorro de esfuerzo, sino lo que es más importante, permite que los desarrolladores dediquen su esfuerzo a tareas que no se pueden automatizar, y que requieren de su creatividad e ingenio.

Un lenguaje con un nivel de abstracción superior al del código tiene ventajas considerables:

• Un lenguaje más abstracto es un lenguaje más cercano al problema y a su solución que el código. Esto facilita la descripción y comprensión.
• Permiten centrarse más en el contenido. Se podría decir que es más 'denso'. Hay que escribir menos para decir lo mismo. Las aportaciones que se hacen contienen más semántica, y requieren ocuparse menos de los aspectos sintácticos.
• Cuanto más tempranas sean las fases del desarrollo en las que se comiencen a usar lenguajes formales, antes se puede aprovechar la información. Para hacer comprobaciones, obtener métricas, controlar el avance, control más riguroso de versiones, ...
  

Las ventajas que reportaría al desarrollo un salto como el descrito abarcan muchos aspectos de éste: productividad, reutilización, mantenimiento, portabilidad, interoperabilidad. Pero eso es tema para otra ocasión.

Techorati tags: programacion, mda

Microsoft y los problemas con las patentes de software en USA

En este artículo se habla de las modificaciones que propone Microsoft al sistema de patentes en USA. Y es que ni a Microsoft le gusta el sistema de patentes que tienen.

El artículo habla de entre 35 y 40, las demandas que Microsoft tiene abiertas normalmente en su contra, y que le suponen unos gastos anuales de unos 100 millones de dólares.

También dice que en el último año han solicitado 3000 patentes, y que el número total de patentes solicitadas a la oficina en el año supera las 350.000 (se han triplicado desde 1980).

Además los gastos de la oficina de patentes no dejan de subir año tras año (hasta a Microsoft le parecen excesivos).

Microsoft propone reformas al sistema de patentes en USA, pero creo que es querer enmendar algo que no tiene remedio, ya que las patentes no son beneficiosas para la industria del software. Lo que ocurre es que allí ya no pueden dar marcha atrás, las compañías han invertido mucho dinero en patentar y mantener litigios, su única baza es extender el sistema al resto de la industria, y el objetivo actual es la UE.

En fin, me gustaría que nuestros políticos de la UE, reflexionasen sobre lo que se le puede venir encima a la industria del software europea si la directiva sobre patentes se aprueba finalmente en su forma actual.

Technorati tags: patentes

La demanda de SCO terminará favoreciendo a Linux

A raíz de este artículo, uno puede sacar varias conclusiones.

Una de ellas, es que si había dudas sobre el origen de partes del código de Linux, gracias a SCO y a sus demandas, este asunto se va aclarando en favor de Linux, lo que redundará en la confianza sobre la autoría del código de Linux, ya que hasta el momento se daba por supuesto, pero gracias a la demanda de SCO se verá reforzado en los tribunales.

Algo que también es deseable, cuando llegue, para las licencias de software libre.

Technorati tags: linux

Patentes de software e innovación

Uno de los argumentos más utilizados por los defensores de del patentes de software, es el consistente en decir que con las patentes de software se favorecerá la innovación en la UE. En mi opinión es todo lo contrario, y voy a explicar por qué.

• El software es un producto que se hace en base a combinar y mejorar ideas previas, con alguna idea que puede ser nueva. Las aplicaciones pueden contener cientos o miles de ideas susceptibles de ser patentadas. Es casi imposible, por no decir imposible, hacer algo que no use algo ya patentado. Esto perjudica claramente la innovación, y lo hace para todos, grandes y pequeños. Lo que ocurre es que las grandes compañías, que tienen cada una cientos o miles de patentes, pueden negociar entre ellas y establecer pactos de no agresión. ¿Pero qué ocurriría en este juego con las pequeñas y medianas empresas? Pues que el pez grande se come al pequeño. Punto para las compañías que ya tienen un buen saco lleno de patentes.
• Un sistema de patentes cuesta dinero. Cuesta dinero porque hay que estudiar si algo que se quiere hacer está pantentado. Cuesta dinero porque uno que tiene proteger lo que hace mediante patentes. Y cuestan mucho más dinero si hay que litigar, o pagar por usar las patentes de otros. Por lo tanto, para participar en este sistema, hay que tener recursos no sólo para desarrollar, también para conocer las patentes que hay, patentar las propias y poder mantener litigios con los competidores. Los recursos que uno dedica a esto no los puede dedicar a innovar y desarrollar. Por lo tanto, punto para los que tienen más recursos, las grandes compañías (que no tienen por qué ser de software, cualquiera puede patentar).
• Las oficinas de patentes ganan dinero con las patentes, es decir, cuando se registran patentes, no cuando se rechazan. Por tanto, hay un interés por parte de estas oficinas a otorgar patentes. Se puede hacer una lista enorme de las patentes absurdas (1 y 2) y obvias que hay en todo el sistema de patentes, no sólo en el del software. Otro punto, esta vez para las oficinas de patentes, abogados y demás entes que viven de que existan este tipo de monopolios.

Sobre la naturaleza del software y la innovación también habría que decir varias cosas:

• El software libre es un motor de innovación. Y es todo lo contrario a usar un sistema de patentes. Muchas de las innovaciones que se han producido en el campo del software vienen del software libre, o de cuando no se jugaba todavía a esto de las patentes. Hoy en día, hay muchísimos casos de cómo el software libre innova y obliga al resto del software a innovar y mejorar para mantenerse (Linux, firefox, por citar ejemplos claros y recientes).
• El del software es un mercado, en el que por su propia naturaleza, hay que innovar para sobrevivir. No necesita de patentes para esto. Al contrario, si tienes patentes con las que ya ganas dinero, y además, con estás o con otras, le has cerrado el paso a tus oponentes, adiós a la innovación en la parcela que has acotado con tu patente (monopolio).
• En el mercado de las tecnologías de la información (específicamente en el de Internet) se da el fenómeno denominado como la larga cola (long tail). Se caracteriza porque los costes de almacenamiento y distribución son mínimos en comparación con la difusión que se puede alcanzar. Cualquiera mañana podría mejorar lo que hace google y empezar a ganar dinero. Eso siempre que no esté patentado.

Tecnorati tags: patentes, innovacion, programacion

Patentes de software en la UE

El consejo europeo ya ha dado su visto bueno a la propuesta que deja la puerta abierta a la patentabilidad del software.

Al final las grandes compañías se están saliendo con la suya. Muchas de ellas ajenas a la propia UE.

Se trata de una propuesta que es perjudicial para la industria del software en la UE, ya que pone en manos de las grandes compañías, muchas de ellas ajenas a la UE, un arma que frenaría el desarrollo de software en la UE por parte de las pequeñas y medianas compañías. También supondría un freno para el desarrollo del software libre. Se están cambiando las reglas del juego. Un juego en el que sólo podrían participar aquellos que dispongan de los recursos que exigen las reglas de las patentes. Me gustaría recordar que el software algunas de las particularidades que no existen en la industria (que cuenta con sistemas de patentes desde hace tiempo):

• El software son algoritmos, o sea, ideas. Se estarían patentando ideas. Impidiendo su uso por otros, ya sea para mejorarlas, o combinarlas con otras.
• Un programa está compuesto por cientos, miles o decenas de miles de ideas que podrían patentarse. ¿ Cómo se puede desarrollar algo en un sistema así ? Las grandes compañías juegan a esto, negociando entre ellas con los miles de patentes que tienen. Pero, ¿Qué pasaría con las pequeñas y medianas empresas? ¿Y con el software libre?.
  

Por último, estamos en la sociedad de la información. La cual gestionamos gracias a los sistemas de información. Los cuales van a estar en manos de aquellos que puedan desarrollarlos y controlarlos, ...

Creo que habría que seguir movilizándose para que nuestros políticos en la UE conozcan de una vez por todas las deficiencias de la propuesta. Esto lo tenemos que hacer sobre todo los que estamos en el sector, y conocemos los detalles técnicos del asunto. Sigamos trabajando para que desde la UE modifiquen la propuesta y cierren las vías que permitirían la patentabilidad del software en la UE.

UPDATE: De todas las reacciones me ha llamada la atención la de Lawrence Lessing. Y es que al igual que él, muchos no entendemos por qué los que se suponen que deben defender los intereses de la UE, estén facilitando las cosas a las compañías de USA y poniendo en dificultades a la industria del software en la UE.

UPDATE 8/3/2004: Una reacción más vehemente por parte de Jorge Cortell. Incluye en su post la posición de hispalinux,

Technorati tags: patentes, ue

"El portal místico me espera"

La frase es de la película Toy Story. La pronuncia el marcianito de color verde, 'capturado' junto a Woody y Buzz Ligth Year por Sid, cuando se aproximan a la casa de Sid. Lo hace en la creencia de estar alcanzando el destino glorioso que aguarda a todos los marcianitos de color verde del Pizza Planet. Esta idea se podría llevar más lejos, pero no me quiero poner muy trascendental, lo dejaré en un nivel más mundano, la del cambio profesional.

Para alguien dedicado al desarrollo software, hay una que se diferencia de todas las demás porque impone unas exigencias de carácter personal más que técnico. Me refiero al cambio que supone el pasar a ser jefe de proyecto.

En primer lugar, quiero decir que cuando este puesto se alcanza en la misma organización en la que uno lleva cierto tiempo desempeñando otras actividades, el cambio no lo tiene que asumir sólo el nuevo jefe de proyecto, tienen que hacerlo también todas las personas que le rodean. Ya que se suelen dar situaciones en las que se continúa requiriendo a la persona para desempeñar las funciones que hacía hasta ahora, y que no son las propias de su nuevo puesto. Pongo algunos ejemplos:

• Se había estado ocupando del desarrollo la programación de una aplicación que nadie conoce mejor que él, y surge la necesidad de hacer una mejora, o arreglar cuanto antes un problema. Así que como poner a otra persona puede suponer 4 o 5 días, en vez una mañana, el trabajo termina sobre su mesa (y en algunos casos con prioridad absoluta sobre todo lo demás).
• Hasta la fecha, se ocupaba de tratar personalmente con los clientes de cierto producto o servicio, y como les entiende mejor que nadie, y los clientes están acostumbrados a él, las demandas de éstos le siguen llegando.
  

También hay que entender que el cambio, en muchas ocasiones debe ser gradual, la persona debe ir delegando poco a poco, sus anteriores responsabilidades. Es algo que debe llevar a cabo toda la organización, no sólo el individuo. El problema se da cuando pasa el tiempo y no se consigue acabar con esta situación.

A pesar de lo anterior, el reto más importante, en cuanto a la asimilación del cambio de rol lo tiene el propio sujeto. Si éste siente una inclinación por las tareas que venía realizando (porque le gustan y además las domina), se sentirá mucho más cómodo ocupándose de estas tareas que de las que conlleva su nuevo puesto. La inclinación a seguir realizándolas es muy fuerte.

Un jefe de proyecto software debe tener conocimientos técnicos, pero además debe tener unas habilidades personales, que no son necesarias en los puestos que ha podido desempeñar antes (arquitecto software, analista, programador, ...), por lo que normalmente se llega al puesto de jefe de proyecto sin tenerlas, o sin haberlas desarrollado lo suficiente. Esto hay que tenerlo muy claro, porque a veces uno se da cuenta, demasiado tarde, que dirigir un grupo de desarrollo tiene que ver más con las personas que con la tecnología. Así que el que no quiera ocuparse adecuadamente (espero tratarlo en otro post), de los problemas que conlleva el trato con sus desarrolladores, deberían abstenerse de asumir la dirección de un grupo de trabajo si no quieren acabar tirando sus proyectos, o a la gente que trabaja para ellos, por la borda. Lo que ocurre aquí, es que la renuncia a este puesto, supone la renuncia a mejoras económicas y/o de estatus.

No obstante, si uno quiere dedicarse a esto, muchas de estas habilidades se pueden adquirir y mejorar. Quizás no esté al alcance de todos poder convertirse en el mejor jefe de proyecto de la organización, o del sector, pero sí se puede aprender lo suficiente para hacer un trabajo digno, que permita sacar adelante los proyectos, manteniendo un buen clima de trabajo y convivencia en el grupo. Al fin y al cabo, ése es el objetivo.

Technorati tags: gestion proyectos, programacion

Cambio a Firefox

No pretendo a estas alturas descubrir la existencia de este estupendo navegador, sólo me gustaría comentar algunas de las cosas que tras unos días de uso, me han llevado a cambiar a Firefox.

+ El uso de pestañas. Permite navegar con una única ventana. Resulta especialmente cómodo porque suelo abrir los links que me interesan en otra ventana. La idea es seguir leyendo la página actual, y que mientras tanto, se vayan cargando las páginas que me pueden interesar, las pongo a cargar en cuanto veo el enlace, no quiero que luego se me olviden, ni tener que repasar la página. Cuando esto se hace abriendo ventanas, las nuevas ventanas se ponen encima de la actual, por lo que hay que buscar la ventana de partida y hacer otro click para volver a ella. Con las pestañas, el navegador se comporta como quiero. Deja seguir viendo la página actual, y mientras, va cargando las páginas que quiero ojear más adelante. Además, después sólo hay que mirar en el propio navegador (no en la barra de tareas del sistema, o por el mosaico de ventanas que hay en el escritorio) para saber qué páginas tenía interés en ojear.

+ Las búsquedas en la web (búsqueda inteligente, usando el vocabulario de firefox). Utilizaba mucho la barra de herramientas de google, pero básicamente para las búsquedas. En firefox, tengo búsquedas en google, yahoo, drae, etc.

+ La búsqueda de texto en la página. El que aparezca una barra en la parte inferior para estas búsquedas es muy cómodo. Cuando se tienen abiertas varias pestañas con los resultados de una búsqueda de google, se puede repetir la misma búsqueda en cada pestaña con un sólo click.

+ La barra de acceso rápido. Otra cosa que acostumbro a hacer es tener accesos directos en el escritorio para páginas que miro a menudo. Ahora los tengo en el propio navegador (cada oveja con su pareja), así tengo el escritorio más limpio.

+ La gestión de marcadores es muy cómoda. Es una interfaz bastante más trabajada que la del IE.

+ Las extensiones. Tengo que probar alguna más, tienen muy buena pinta.

+ Los popups se los carga el propio navegador, ni barras adicionales ni parches del sistema operativo (para aquellos que los tengan).

Habrá que estar atentos al IE 7 anunciado hace unos días por microsoft, y es que ante esta competencia, los mayores beneficiados somos los usuarios.

Technorati tags: firefox, tools

marzembre

El nombre tiene su origen en cierta ocasión en la que me encontraba programando una función que recibía un número del 1 al 12, y devolvía el nombre del mes correspondiente. Tenía a mi lado, a un compañero que seguía atentamente mis movimientos, y se me ocurrió hacer una broma con el código que estaba escribiendo. Lo que hice fué escribir código para que la función devolviese un nombre de mes ficticio cuando el número recibido no se encontrase entre 1 y 12.
Tras terminar de escribir miré a mi compañero, y los dos estallamos en una sonora carcajada. Había nacido el mes de 'marzembre'.

Nota para programadores: El código final trataba el error como corresponde, es decir, lanzando una excepción 'Error: Mes de marzembre desconocido para el sistema'.