El cierre de Cuil

Leo en Denken Über que el buscador Cuil ha cerrado.

Este buscador, cuya existencia no ha sido conocida por muchos, generó cierta atención tras su puesta en marcha a finales de julio de 2008, ya que en su creación habían participado ex trabajadores de Google por lo que su conocimiento del mundo de los buscadores hacía pensar que podían lanzar un producto con la suficiente calidad e innovación para ganarse cuota de mercado y convertirse en un competidor de cierta relevancia para Google.

Además de un cambio en el diseño respecto a los buscadores tradicionales y de la forma en que presentaba los resultados tenía como principal valor el hecho de que anunciasen que eran capaz de indexar muchas más páginas web que Microsoft o Google (diez veces más que el primero y tres veces más que el segundo) y que además no almacenaba ningún tipo de actividad de los usuarios en el buscador.

Tuvo un buen arranque debido principalmente al revuelo mediático de su lanzamiento y de hecho a finales de 2008 fue incluso reconocida como una de las startups más existosas de ese año.

Sin embargo con el paso del tiempo fue perdiendo más y más relevancia, lo que probablemente le haya llevado a su situación actual.

Yo he tenido la oportunidad de utilizar Cuil y en las distintas ocasiones que realicé búsquedas a través de él no quedé satisfecho con los resultados (y no es algo que hiciera exclusivamente en los inicios, sino que con el paso del tiempo fui dándole nuevas oportunidades). Esa es mi experiencia, tal vez otras personas hayan obtenido otras conclusiones.

¿El problema de la no continuidad de Cuil es que no hay espacio para más buscadores? Es cierto que Google domina y que tras él y a gran distancia están Bing y Yahoo (por ese orden) y que el resto de buscadores prácticamente están en el fondo del abismo. Si por el simple hecho de existir ese panorama en el mercado de los buscadores debiéramos pensar que no hay espacio para nadie más, lo mismo podríamos haber pensado en el mercado de los sistemas operativos de móviles antes de la aparición de iOS y Android o en el mercado de los sistemas operativos de PCs donde el dominio de Windows es mucho mayor que el que tiene Google en los buscadores.

Desde mi punto de vista si un producto es lo suficientemente bueno e innovador puede ganarse su hueco, no es fácil, pero tendría posibilidades, además al tratarse de productos tecnológicos el simple boca a boca que se produciría en la red le haría conseguir rápidamente una primera base de adeptos.

Sobre el asunto de Cuil tengo una pregunta (desconozco su respuesta), ¿cuál fue el objetivo de Cuil, crear un buscador para competir con los grandes o desarrollar una tecnología para ser comprada por los grandes?.

Desarrollo de software: La cohesión

Cuando se habla de programación orientada a objetos se dice que un buen diseño es aquel que consigue una alta cohesión y un bajo acoplamiento. Como es lógico, estoy de acuerdo, no obstante de los dos conceptos la cohesión, tal vez por entenderse menos su utilidad, es el hermano pobre, es decir, si se tiene en cuenta alguno de los dos (algo que desgraciadamente no ocurre demasiado, ya que no se suele prestar suficiente atención a la calidad del diseño y de la codificación) se suele echar más en cuenta al acoplamiento, además de ser más inteligible por ser más evidentes los problemas existentes cuando el acoplamiento es alto.

La cohesión mide la relación entre los distintos elementos que componen una clase: atributos y métodos. Una baja cohesión da lugar a las denominadas clases tutti frutti, clases que pretenden hacer muchas cosas y diferentes.

Cuando se tienen clases con baja cohesión implica principalmente:

– Falta de comprensibilidad: La clase no sirve a un aspecto concreto, sino a muchos. Cuando pensamos en un objeto lo hacemos entendiendo que sus partes son necesarias para que exista su todo (es decir, las partes por sí solas tienen poca utilidad y es mediante su relación cuando dan entidad al objeto y hacen que en su conjunto (el todo) valga más que la suma de las partes por separado). Cuando tenemos clases cuyos elementos forman un todo, pero ese todo no es identificable con nada, nos encontraremos probablemente con clases que tienen una baja cohesión, con métodos que no guardarán relación con otros muchos de la misma y que servirán a propósitos distintos. Habrá que tener bien documentada la clase para mantenerla posteriormente, porque si la coge un equipo de desarrollo distinto o ha pasado mucho tiempo desde que se implementó resultará complicado entender para qué sirve y qué utilidad tienen muchos métodos y atributos de la misma.

– Dificulta la mantenibilidad: Además de por la disminución de la comprensibilidad de la clase, al tener más código del que debería tener, se incrementará en consecuencia la complejidad ciclomática de la misma y por tanto será más costoso realizar cambios.

– Dificulta la reutilización: Cuando tenemos una baja cohesión quiere decir que hemos modelado una realidad rara, un híbrido de muchas cosas. Se ha implementado una clase para algo muy específico y lo concreto pocas veces es reutilizable.

– Suelen tener un acoplamiento alto (en comparación a una cohesión baja): Tiene su lógica ya que la clase tendrá más métodos que si los diferentes objetos reales que están dentro de la misma se hubieran encapsulado en sus correspondientes clases. Más métodos implican por regla general llamadas a más métodos de clases y paquetes externos y en consecuencia un mayor acoplamiento.

– Tendentes a sufrir modificaciones: Como estas clases son híbridos de varias la probabilidad de tener que sufrir operaciones de mantenimiento crece (tanto como clases distintas pudieran contener en su interior), lo cual tiene su importancia sobre todo si tenemos en cuenta que este tipo de clases son más complicadas de mantener.

Una forma de medir la cohesión la tenemos con la métrica LCOM4, propuesta a partir de la métrica inicial LCOM1 de Chidamber y Kemerer. Esta métrica forma parte del conjunto de las mismas que calcula Sonar haciendo análisis estático de código.