Archivo

Archivo para la Categoría "software libre"

¿”Ingeniería” del software? Ahora vienen los mea culpa

Los que leen habitualmente mi blog conocen mi opinión sobre la “ingeniería del software tradicional”, muchas veces hablé de ello y del “mal” que hacen en general a la profesión, y hasta como limitan la innovación.

Nunca me gustó que se llame “ingeniería” a un proceso que tiene poco que ver con los de las ingenierías tradicionales, entre ellas que las tradicionales poseen una serie de herramientas analíticas y cuantitativas para evaluar y estimar riesgos y tolerancias. En el desarrollo de software no tenemos esas herramientas, quizás nunca las tengamos: no es lo mismo trabajar en la construcción de elementos físicos, limitados por leyes fundamentales de la física, con pocas combinaciones posibles, con la construcción de programas informáticos que no tienen esas limitaciones físicas, ni en las combinaciones posibles.

Este tipo de visión propuesta desde el mismo nombre “ingeniería” nos lleva a errores muy importantes, por ejemplo el de suponer que las construcciones físicas y las matemáticas [los programas] son equivalentes. No sólo hace “daño” a los proyectos que nunca pueden cumplir plazos y presupuestos, sino también a la propia “ciencia” y profesión informática. Es un engaño, fundamentalmente a los propios profesionales. Así se cometen errores derivados como reclamar colegios, regulaciones y normas y procedimientos similares a otras ingenierías: las soluciones equivocadas son más perjudiciales que los problemas abiertos. Además es ponernos una venda en los ojos para no observar el verdadero potencial de la informática, ni para darnos cuenta de dónde está la innovación (que no es precisamente seguir haciendo el mismo software de siempre).

Escribí bastante sobre estos temas, fundamentalmente en apuntes críticos con la creación de los colegios oficiales informáticos. El núcleo de la argumentación es la que comentaba antes, incluso de crear una “pseudociencia” (p.e. en Recursividad, punteros, estadísticas y pseudociencia del software, Diseño, ingeniería, ágiles… y frameworks, Redescubriendo al Dijkstra provocador 18 años después), además enseñado en la universidad como si de leyes científicas se tratasen –quizás lo que más daño hace–.

También critiqué al establishment de la “ingenieria del software”, dominado por tecnológos pocos “científicos” –en su mayoría empleados de grandes corporaciones de desarrollo de software para empresa de Fortune 500– que en ninguna de sus publicaciones científicas presentan los datos para que puedan ser contrastados (algo inherente del software privativo) y sometidos al peer review (que no es aceptable en ninguna otra rama científica). Este mismo establishment ha ignorado durante muchos años al software libre con sus métodos de diseño y desarrollo completamente contradictorios con los propuestos por la “ingeniería tradicional” (muy bien expuesto en al “Catedral y el Bazar” de Eric Raymond).

Muchas de las respuestas que tuve –incluso entre supuestos reputados profesionales– es que “hago daño a la profesión” [sic].

Pero ahora está surgiendo el mea culpa de los gurús incondicionales de la “ingeniería del software”. El reconocido gurú Tom DeMarco (gracias Paco) que escribió el artículo de opinión Software Engineering: An Idea Whose Time Has Come and Gone? (algo así como “Ingeniería del software: ¿una idea de tiempos pasados?”) que es en gran parte una autocrítica a sus ideas y libro de referencia Controlling Software Projects: Management, Measurement, and Estimation.

Resumo sus ideas fundamentales con algunas de sus frases traducidas literalmente:

  • Hoy en día todos comprendemos que las métricas de software cuestan dinero y tiempo, y que deben ser usadas con moderación.
  • El desarrollo de software es inherentemente diferente de las ciencias naturales tales como las física, por lo que sus métricas son muchas menos precisas para capturar lo que deben describir.
  • La frase más citada del libre es «No puedes controlar lo que no puedes medir». Esta frase contiene una verdad real, pero cada vez me sentía más incómodo con el uso que hice de ella. Está implícita en la frase (y en título del libro) que el control es un aspecto importante, quizás el más importante, de cualquier proyecto de software. Pero no lo es.
  • Muchos proyectos se han realizado sin demasiado control pero han generado productos maravillosos tales como Google Earth o la Wikipedia.
  • Esto nos lleva a la desagradable conclusión que el control estricto es algo que importa mucho en proyectos relativamente inútiles y mucho menos en proyectos útiles. Sugiere que mientras más te enfoques en el control aumenta la probabilidad de que estás trabajando en un proyecto que se esfuerza por generar algo de valor relativamente menor.
  • ¿Estoy diciendo que está bien ejecutar proyecto sin control o con un control relativamente menor? Casi. Estoy sugiriendo que deberíamos seleccionar primero a los proyectos cuyo control preciso no importe demasiado.
  • Estoy llegando gradualmente a la conclusión que el momento de la ingeniería del software vino y se marchó.
  • En los últimos 40 años nos hemos torturado por nuestra ineptitud en acabar proyectos a tiempo y con el presupuesto previsto. Pero como sugerí antes, no debería haber sido el objetivo supremo.
  • El objetivo más importante es la transformación, crear software que cambie el mundo, o que transforme una empresa, o la forma en que hace negocios.
  • El desarrollo de software es y será siempre algo experimental. Lo construcción real de software no es necesariamente experimental, pero sí lo es su concepción. Allí deberíamos enfocar nuestros esfuerzos. Allí es donde deberíamos haberlo hecho siempre.

Está muy bien que por fin los gurús de la “ingeniería [tradicional] de software” comiencen a reconocer errores y dejar de ignorar a los métodos y filosofías tan habituales del software libre y de proyectos que han sido realmente innovadores desde el punto de vista de gestión de proyectos de software. Todavía se queda corto y esta opinión me deja la misma sensación de dejè vu que me produjo hace unos diez años la moda de lo métodos ágiles y la programación extrema: era algo que ya se veía hace tiempo en el software libre y de hecho era mucho más radical que las “radicales” nuevas metodologías y métricas. Por ejemplo.

Tom DeMarco cita a dos proyectos que le parecen notables para mostrar la contradicción con las ideas tradicionales: Wikipedia y Google Earth. Pero resulta que ambos tienen muy poco que ver y no han sido “seminales” en sus aŕeas.

El software de la Wikipedia [un wiki colaborativo] es muy sencillo y no fue el primero en hacer un programa de este estilo. el éxito e importancia social de al Wikipedia es el proyecto global, y cómo ha conseguido formar una enorme comunidad de gente que comparte valores de fomentar la divulgación libre del conocimiento. Poco tiene nada que ver con “desarrollo de software”, sino con valores y conceptos mucho más amplios.

Google Earth es un programa mucho más complejo pero que ya eran comunes desde principios de la década de los ’90, con el auge de las estaciones 3D (el líder indiscutible era Silicon Graphics, SGI) y la realidad virtual. De hecho Google Earth surge de la compra de una empresa (Keyhole) que a su vez se basó en otras ideas e implementaciones previas de 1994. El logro fundamental de Google Earth poder acceder a esa cantidad de datos y dejarlos a disposición de todo el mundo, algo que antes sólo podían hacer muy pocas empresas. (En todo caso yo hubiese mencionada a Google Maps, porque mostrar esa información usando sólo HTML y Javascript sí fue una innovación importante, junto con Gmail mostraron el camino del desarrollo de aplicaciones Web/Ajax complejas).

Si yo tuviese que elegir proyectos de software realmente indicativo de las contradicciones con las “métricas tradiconales”, por ejemplo:

  • Núcleo Linux: Es muy complejo desarrollaro un núcleo de sistema operativo, la variedad de hardware es enorme, los bugs tienen consecuencias graves, se necesitan mucho conocimientos, tiene una enorme cantidad de elementos independientes, las combinaciones de caminos de ejecución de casi infinitas. Aún así se desarrolló uno que funciona desde los superordenadores más grandes del mundo a los teléfonos móviles, con el aporte de miles de programadores sin ningún tipo de reuniones, coordinación, diseño previo o siquiera documentación básica (ahora ya hay bastantes libros y documentos).
  • KDE/Gnome: Dos proyectos complejos, independientes pero competidores e incluso “con esfuerzos inaceptablemente duplicados”, pero que cada uno aportó innovaciones en distintas áreas y se integran o usan en entornos diversos como escritorios completos a dispositivos móviles o multimedias (por ejemplo el Sfari/Webkit que se ejcuta en Mac, iPhones, Androids y Nokias es derivado directo del KHTML de KDE).
  • Sistema GNU/Linux o BSD (+ X.org, +GNOME/KDE, +multitud de software): Ejemplo radical de cómo se pueden construir sistemas complejos muy completos basados sólo en una coordinación o consenso mínimó para las interfaces entre ellos. Estas interfaces además son muy simples y no han dejado de evolucionar sin necesidad de “cambios drásticos”.

Cualquiera de los tres proyectos es –en código fuente– órdenes de magnitud más grande que la Wikipedia o Google Earth, además ninguno de ellos dependió de una empresa o fundación, y tienen una complejidad y diversad de uso mucho mayor.

Por eso, está muy bien que empiecen a descubrir todo un mundo allí fuera, que creció y se desarrolló sin seguir las métricas y métodos “tradicionales”. Es aún una mejor noticia que los gurús de la ingeniería del software empiecen la autocrítica de las ideas erróneas que han fomentado durante 40 años.

Estaría ahora muy bien que los fanboys de esa “ingeniería” empiecen a aceptarlo. Pero sería mucho mejor que los responsables de planes de estudio y asignaturas de “ingeniería del software” en las carreras informáticas sean conscientes del problema, al menos ya tienen a uno de sus gurús poniendo en dudas los cimientos de su [pseudo] ciencia. Quizás así dejaremos de leer y escuchar falacias tales como “para ser buen director de proyecto no hace falta saber programar”, “un proyecto es malo si no tiene un diseño previo bien especificado y documentado”, o el mantra:

[...] podemos y/o debemos gestionar un proyecto de software de la misma forma que un proyecto de arquitectura.

Futurología: en unos pocos años veremos que el hot topic en las publicaciones de ingeniería del software serán estudios de caso de grandes proyectos de software libre. Nos hablarán de la radicalidad de los métodos ágiles usados, la coordinación debil, el software evolutivo, la complejidad de las relaciones sociales entre programadores y usuarios, la influencia del uso real de los usuarios para el diseño del software, la importancia del release often, del peer review, los casos reales de uso no previstos por los programadores… y volveré a sentir una sensación de dejà vu.

De software libre…

junio 11, 2009 19 comentarios

Escribo poco en el blog, como comenté antes le doy prioridad a cosas que son más fructíferas y divertidas que estar en constante discusiones en el blog: la familia, mi trabajo de investigación [*], programar cosas del Menéame… y en estas épocas corregir prácticas y examenes como loco. Pero además de ello hace tiempo no escribo sobre software libre.

La verdad es que se me secaron las ideas sobre el tema. Todo lo importante está dicho, el que tenía deseos de aprender ya lo sabe, los demás no habrá forma de explicarlos. No saldrán del eslogan “talibán”.

Pero en la conferencia de Carlos Almeida alguien del público comentó que era una pena que no hubiésemos hablado de software libre. Mi respuesta fue que ojalá el tema de la cultura, libre o encerrada, estuviese en la misma situación que el software libre:

  • Se produce mucho software que se libera y se utiliza por individuos y empresas.
  • Los programadores de software libre no reclaman que el gobierno les subsidie o les asegure ingresos a pesar que el númer de usuarios de software libre es infinitamente mayor de los que ven pelis españolas (sólo contando a usuarios de Firefox o los GNU/Linux en móviles y empotrados ya se gana por goleada).
  • Se produce y divulga mucho conocimiento útil y de efectos prácticos inmediatos.
  • etc. etc.
  • Ganan dinero.

Pero lo mi respuesta fue que hace 15 años hubiese sido imposible imaginar que grandes corporaciones, competidoras entre sí, trabajasen de forma conjunta para desarrollar software que es fundamental para sus negocios, y que además lo liberasen.

A un no iniciado eso le sonará a utópico o exageración, pero a los hechos me remitiré. Cogiendo una pequeña parta de las cosas nuevas cool que se implementaron en la última versión del núcleo Linux (obvío las contribuciones personales):

  • Contributor: NTT Labs (Nippon Telegraph and Telephone Corporation)
  • Contributor: www.openfabrics.org (Particularly, Oracle)
  • Contributor: Intel
  • Contributor: Atheros
  • Contributor: Red Hat
  • Contributor: Panasas
  • Contributors: Panasas, Netapp and IBM
  • Contributor: Red Hat
  • Contributor: NTT DATA CORPORATION
  • Contributor: Michal Simek, with donations from PetaLogix and Xilinx
  • Contributor: IBM

Luego se se ven los detalles de los commit de cada cambio se podrán ver las firmas de empleados de casi todas las empreas inportantes de hardware y software. Es casi un Who is who en informática.

Ojalá la “industria” cultural estuviese en la misma situación. El equivalente sería ver a los majors colaborando entre ellos, con productoras pequeñas y músicos de todo tipo, liberando todo con licencias libres, promoviendo el remix, con páginas webs para que cualquiera se baje la última versión de cualquier obra, organizando conferencias y conciertos para explicar el porqué es bueno compartir, sin SGAEs ni reclamando subvenciones y cánones, y además ganando dinero en el proceso.

Sí, quizás nunca lleguemos a esa situación. Pero si IBM, Oracle o Intel ya lo han tomado como parte natural de sus negocios no hay que perder las esperanzas.

Claro que la gente que suele dirigir empresas como IBM Oracle o Intel suelen ser muy listas, con doctorados o másters de universidades prestigiosas, y una larga experiencia en la empresa y el área. Aquí en cambio cualquier guionista de pelis subvencionadas puede llegar a ser ministro sólo por haber repetido una y otra vez lo de “la piratería de Internet nos está matando”. Vaya si hay diferencias.

Tant de bo! que a la cultura le pase lo que al software libre. A nadie se le hubiese ocurrido leyes hadopis y estupideces similares.

PS: Sí,  hay contradicciones, doble juego y cosas no tan bonitas, pero cada año mejora la colaboración e igualmente –en el peor de los casos– no hay color en la comparación con la “industria cultural”, que son peores que el temido y odiado Big Brother de IBM en los 60-70.

[*] Estoy metido en dos cosas. Una que desarrollaré poco a poco y cuya idea surgió de la chapucilla rápida que hice para sindemocracia.net, técnicas de clustering para organizar noticias a partir de seguimineto en sitios sociales y de noticias a partir de palabras claves. La otra es muyteórica, coloreado de grafos con algoritmos polinomiales. El coloreado de grafos es un problema NP-Completo, es decir, puede ser resuelto por una máquina de Turing no determinística y se puede verificar la solución en tiempos polinomiales,  pero no se conoce un algoritmo óptimo polinomial para hallar la solución. Para encontrar soluciones se usan heurísticas, por ejemplo ordenar los nodos y asignar colores con el [simple] algoritmo greedy. Ya desarrollé un algoritmo de ordenamiento que es no sufre los problemas de los conocidos –fundamentalmente con “prismas”– y que encuentra soluciones con menos colores, pero la diferencia es pequeña para que sea importante. Por ejemplo para grafos –de bases de datos de “grafos reales”– de 1.000 nodos y con 60 colores en su solución óptima asigna 121 colores, tres menos que el conocido smallest-last. Ahora estoy trabajando con heurísticas un poco más complejas, pero todavía sencillas y de tiempos de ejecución polinomiales, basadas en la freucencia de colores usados y las restricciones de nodos previos como “grados de libertad” para la asignación de los siguientes.

Fonera USB, sin DRM

octubre 14, 2008 60 comentarios

Disclaimer muy importante: Martín Varsavsky, fundador e inversor en FON, es inversor y socio de Menéame Comunicacions S.L. vía  JAZZYA Investments desde enero de 2007. Por lo tanto este apunte sólo tiene la credibilidad que se merece por lo que expresa, no por su “objetividad” o “neutralidad”. Incluso puede ser tomado como “publiapunte”, a lo que el autor no pondrá reparo alguno.

En mi antiguo blog he sido muy crítico con Fon apenas fue fundada. Primero y fundamentalmente porque no cumplía la licencia GPL, luego por un problema de seguridad. Después de unos duros debates públicos mantuve conversaciones con gente de FON donde me contaron los problemas con el desarrollo incial, sus planes de inversión y desarrollo, y que se iban a solucionar todos los problemas de licencias y desarrollar un nuevo sistema de autentificación y control –como así fue–. Por ello dejé de hablar de FON, la siguiente vez fue cuando lanzaron la Fonera y me enviaron una para que la pruebe y verifique que el código cumplía las licencias.

En ese apunte comento que no estaba de acuerdo con el DRM. En conversaciones privadas con Martín Varsavsky le di mucho el coñazo con el tema. Me explicó los problemas que tenían: que el DRM era una “protección” básica ya que habían invertido millones de euros en el desarrollo y aún así las vendían subsidiadas, que tenían problemas con los fabricantes de chips (especialmente el de WiFi), que querían evitar problemas de seguridad en el sistema de autentificación de Fon, que había inversores importantes que no lo entenderían, etc. etc.

Aún así le insistía en que el diseño de la Fonera estaba muy bien –sobre todo el hecho de poder definir más de una red WiFi– y que podrían vender una versión no subsidiada sin DRM.

Le intentaba convencer que eso aumentaría el interés y facilitaría el hacking, que podrían hacer cosas interesantes y que además serviría para fomentar el desarrollo de redes libres que a su vez aumentaría el interés de redes como Fon. Aunque me comentó varias veces que seguramente sacarían un versión sin DRM en cuanto pudiesen (me hablaba de la Fonera 2 y de la versión con USB) y estaba al tanto de los nuevos desarrollo de Fon, no volví a hablar del tema, me da vergüenza hablar –bien o mal– de la empresa de alguien que es tu amigo o socio.

Sin embargo esta vez creo que es muy importante.

El día 3 de octubre recibo un email de Jordi Vallejo, CTO de FON, avisándome que tenían la nueva fonera USB disponible en beta para desarrolladores y que me enviarían una para que la pruebe. No tenía más información, por lo que comenté antes tampoco escribí sobre el tema, pero me llamó la atención ese “interés”, me olía a que vendría sin DRM (todavía no me ha llegado así que no lo sé de “primera mano”).

Pero esta mañana recibo un email de Martín Varsavsky que me dice literalmente:

Subject: seguimos tu consejo!
sacamos la fonera totalmente hackeable con USB
te vamos a enviar una, ¡gracias!

Si es verdad y eso significa “sin DRM”, es un notición. Si Fon fuese de Silicion Valley la noticia ya estaría en portada de Techcrunch o Digg.

Que después de los millones de euros que han gastado en desarrollo y fabricación del harware ahora lo “abran” yendo en contra de la tendencia habitual de aumentar las restricciones –y meter DRM hasta en las lavadoras– es para alegrarse  y estar orgulloso que eso ocurra en este país.

Aunque las críticas y flames anteriores podrían haber sido más “civilizadas” –mea culpa y disculpas por lo que me toca– el resultado final ha sido muy bueno: redes WiFi de una empresa española que ya es multinacional, con desarrollo de software y hardware local con millones de euros de inversión, y que además sea software libre y sin las restricciones del DRM es espectacular. No podía evitar contarlo, me alegró el día y me deja finalmente un buen sabor de boca de una experiencia personal bastante agria.

Insisto: Releer el disclaimer y poned mucho en duda mi objetividad, seguramente peco de exceso de entusiasmo y completa falta objetividad. Además creo que esta información todavía no es pública, por lo que podrían agradecerme por facilitar un “viral”, o por abrir la boca con información “reservada”. Ya lo sabré en pocos minutos.

Categorías:desarrollo, empresas, software libre Etiquetas: , ,

Tantos años hablando de software libre…

septiembre 21, 2008 16 comentarios

… y siguen escribiendo artículos erróneos.

En Un día para festejar el sofware libre y tirar de emule (vía) comienzan mal desde el mismo titular, ¿qué tiene que ver festejar el día del software libre con el “emule” o el P2P?

Pero en el primer párrafo la lían aún más:

¿Hace cuánto tiempo que no paga por un programa informático? Probablemente ni se acuerde. Y es que para utilizar buena parte del software que hay en nuestro ordenador no siempre tenemos que rascarnos el bolsillo antes, ya sea porque se trata de una copia pirata, o porque los programas son gratuitos.

¿A qué esa colación de emule o copia pirata? ¿y siguen con lo de gratuito después de tanto años de expresar claramente la diferencia entre “libre” y “barra libre”? ¿está igualando “nuestro ordenador” con “nuestro Windows”? ¿no dice nada de sistemas completamente libre?

Al final pone a Vuze en la lista de software libre, que no lo es. Además enlaza erróneamente al VLC.

Como para aclarar las cosas al no iniciado. Seguro lo dejó  más confuso que antes. Una tontería lo que comento, pero demuestra el estado general del conocimiento del software libre. Ni los que escriben sobre él con buena voluntad se enteran.

PS: Hace tiempo que no doy más conferencias de software libre y me preguntan por qué. No tiene sentido, suele ser un brindis al sol. Es difícil hacerlo mejor que Stallman, el que se quiere enterar ya se enteró hace tiempo. Los que no –una mayoría– seguirá igual de ciego, sordo y charlatán.

Categorías:blogs, cultura, software libre Etiquetas:

Software, innovación y crisis del ladrillo

septiembre 12, 2008 30 comentarios

De una presentación que hice en febrero de 2004 en Sant Bartomeu de Grau (y luego en varias más, también en algún apunte del 2005):

Eso sí, de paquetes de software de contabilidad y nóminas se han producido, especialmente en Catalunya, más que en ningún sitio. [...] Los catalanes no hemos innovado, hemos hecho aquello que– usando una determinada tecnología– era más cómodo. Con el turismo y la construcción hemos actuado de forma similar. No tenemos unas cuantas grandes constructoras que hagan puentes en Malasia, sino muchas construyendo apartamentos en la Cerdanya. — Xavier Roig

Era la época de la euforia después de ocho años de gobierno de Aznar nos creíamos los amos ricos del mundo,  cuando mencionaba esta falta de innovación en el software comparada con la de los ladrillos –además el ladrillo se comía las inversiones que podrían haber ido a “innovación”– me ponían caras de “mira lo que dice este talibán catastrofista, si está criticando a la gallina de los huevos de oro, no tiene idea de economía”. :-)

Aunque es verdad que el texto no refleja la realidad completa, donde dice “catalanes” debería generalizar en “españoles”, “ibéricos”, “PIGS”, etc.

Es curioso que cuatro años después hayamos tenido la caída prevista por cualquiera con dos dedos de frente, pero que muchos pongan cara de asombrados. Especialmente el PP, que contribuyó enormemente al desatino.

Ya cayó una crisis sectorial muy gorda, ¿cuánto pasará para que yo repita este mismo rollo cuando la prensa y políticos hablen escandalizadas de la “[mini] crisis del software y TI en España”? Estáis avisados :-)

“Innovación”, como fuck

julio 19, 2008 26 comentarios

Pienso que “innovación es un la palabra de cuatro letras [Nota: por fuck] en la industria. Nunca debe ser usada en una compañía respetuosa. Se convirtió en una objeto de RRPP para vender nuevas versiones. [...] Edison dijo “1% de inspiración, 99% de transpiración”. Pudo haber sido cierto un siglo atrás. Actualmente es “0.01% inspiración, 99.99% transpiración”, y la inspiración es la parte fácil. Como gestor de proyectos nuca tuve problemas para encontrar gente con ideas locas. Tengo problemas para encontrar gente que puedan ejecutarlas [...] Así que no creo que se necesite más innovación. — Linus Torvalds

No podría(mos) estar más de acuerdo. Pero aquí es difícil que dejen de usar el palabro, si aparece hasta en los grandes planes estratégicos (I+D+i) y seguimos creyendo que aumentar el número de patentes es la forma de mejorar, aunque al final dejen patentar cualquier cosa con tal de maquillar y justificar.

Relacionado con el tema de “ideas” y “ejecución”, hoy leí en un blog –de un viejo “conocido”– que se queja amargamente de los datos de las balanzas fiscales. Cuando no estaban publicadas vivían más tranquilos en un mundo de riquezas de fantasía. Ahora que son públicas y se confirma que Catalunya es una de las que más “aporta” –menos que Balears, dicho sea de paso– su queja de  que es una empresa catalana la que vende el tomate extremeño envasado, por lo que no “cuenta” como extremeño sino como catalán. Pobret! Si dejase de quejarse –y lamer el culo a políticos del PSOE buscando posicionarse para algún cargo– y montase una empresa “extremeña” la situación sería un poco distinta. Pero demasiadas “ideas locas” y poca ejecución.

También relacionado… afortunadamente en tecnologías de la información –especialmente en software– hace falta mucho menos dinero y logística para “hacer cosas” que una empresa de fabricación de tomates envasados. Pero aún así encontraremos la forma de quejarnos: mileurismo, las otras empresas chupasangres y malvadas, el intrusismo,  o lo que toque en el momento.

Tener “ideas locas” y escribirlas es fácil. Lo difícil es ejecutarlas, joder si es difícil, y el “sudor” que necesita.

Categorías:desarrollo, software libre Etiquetas:

“No está lista para la empresa”

junio 17, 2008 30 comentarios

Esto es un boboapunte, pero es que ya no puedo reprimirme. Cuando llegó a 50.000 minutos lo hice, pero ahora con 60.000 ya no aguanto las ganas :-)

790 ?        Sl   60235:33 /usr/sbin/mysqld

La línea anterior muestra que el servidor del MySQL (del servidor del Menéame) consumió más de 60.000 minutos de CPU desde la última vez que se reinició –en una actualización de seguridad–, son casi 42 días completos de CPU.

El status da la siguiente salida:

Server version:        5.0.51a-3-log (Debian)
...
Uptime:            79 days 18 hours 10 min 21 sec
...
Threads: 287  Questions: 6812282200  Slow queries: 51042  Opens: 64030  Flush tables: 1  Open tables: 497  Queries per second avg: 988.574

Está en marcha sin parar hace casi 80 días –a punto de dar la vuelta al mundo– y sin nada de “mantenimiento”. En ese período recibió casi 7.000 millones de consultas a casi 1.000 consultas por segundo de media con picos que superan los 10.000 consultas por segundo, sobre una base de datos que no es minúscula –más de 2 millones de comentarios, casi 400.000 artículos y más de 25 millones de votos registrados–.

No está nada mal para una base de datos que tiene sus limitaciones [*] y que hay que tratarla con cariño en las consultas, pero que difícilmente pueda ser batida en estabilidad y eficiencia.

No está nada mal, aunque el FUD no enterprise ready continúa a pesar de la evidencia de los años.

[*] La versión que tenemos es la de etch-backports, ya que la que está en Etch tiene problemas con algunas consultas full-text en UTF-8. También necesitó su trabajo de tuning en las consultas e índices, pero de eso no se escapa ninguna base de datos que tenga que deba dar tiempos de respuestas tan bajos como los que se necesita en las aplicaciones web en general y el Menéame en particular –que necesita hacer muchas consultas diferentes para generar cada página–.

La diferencia entre “opinionated” e ignorantes de su ignorancia

En inglés se suele decir que una persona -especialmente un blogger- es opinionated cuando opina frecuente y públicamente, además es obstinado en esas opiniones. Quizás en castellano la palabra sea terco, obstinado, aunque me parecen que son demasiada peyorativas. De todas formas seguro que yo entro en ese conjunto de personas opinionated :-)

Salvando las distancias en calidad y éxito, suelo hacer lo mismo que Jeff Atwood de The Coding Horror –que por cierto hace poco habló bien del WP-Cache, a pesar que está “abandonado” hace más de un año por falta de tiempo y motivación :-( –. Hoy  explica su estilo en Strong Opinions, Weakly Held.

Lo saco a colación a raíz de su artículo –con el típico titular de un opinionatedPHP Sucks, But It Doesn’t Matter. Yo llevo programando PHP desde hace años, pero su titular y estilo no me molestó, al contrario, me gustó bastante. Primero porque entiendo muy bien –y lo comparto– ese estilo de escribir. También porque sé que el PHP como “diseño de lenguaje” es muy malo. Luego porque el apunte es divertido, pero fundamentalmente porque invita a una reflexión sobre la paradoja y contradicciones del tema.

Lo realmente importante está en la segunda parte del título y en la última del apunte:

But I’m also here to tell you that doesn’t matter.

The TIOBE community index I linked above? It’s written in PHP. Wikipedia, which is likely to be on the first page of anything you search for these days? Written in PHP. Digg, the social bookmarking service so wildly popular that a front page link can crush the beefiest of webservers? Written in PHP. WordPress, arguably the most popular blogging solution available at the moment? Written in PHP. YouTube, the most widely known video sharing site on the internet? Written in PHP. Facebook, the current billion-dollar zombie-poking social networking darling of venture capitalists everywhere? Written in PHP. (Update: While YouTube was originally written in PHP, it migrated to Python fairly early on, per Matt Cutts and Guido van Rossum.)

Notice a pattern here?

Some of the largest sites on the internet — sites you probably interact with on a daily basis — are written in PHP. If PHP sucks so profoundly, why is it powering so much of the internet?

Coincido con él en muchas cosas, aunque describiría de otra forma a los problemas fundamentales del PHP:

  1. No fue diseñado desde el principio como un lenguaje basado en objetos y polimorfismo, que es uno de los problemas que genera la superpoblación de funciones. Así en vez de tener un $array.shift() o $array.pop() existen funciones como array_shift() o array_pop().
  2. Tampoco tiene las facilidades de tratamiento de listas que tiene cualquier lenguaje dinámico desde hace dos décadas como mínimo, como por ejemplo slices nativos, por lo que se necesita otra función como array_slice() a substr() en vez de poder usar $array[i:j] o $string[i:j].
  3. No hay soporte nativo uniforme de módulos que permita tratar de forma transparente –como el use de Perl,  import de Python o include en Ruby–, a módulos desarrollados en PHP y a los llamados “módulos PHP” que se cargan dinámicamente por el interprete.
  4. No soporta los namespaces independientes para evitar evitan la polución del espacio de nombres global.
  5. No tiene soporte nativo para frameworks o abstracciones tan básicas como las de acceso a bases de datos como DBI en Perl, PyDB en Python, DBI o ActiveRecord en Ruby. Así cada sistema gestor de base de datos tiene sus propias funciones, con sus propios nombres y métodos de acceso.
  6. Otros et cetera.

Pero unas críticas de este tipo son incompletas, hay que analizar también el porqué tuvo tanto éxito, su contexto histórico y qué tipo de problemas fue capaz de resolver.

El contexto histórico es que el PHP surgió como un hack rápido para poder generar páginas HTML dinámicas en un momento –1995, antes que existiese ASP o VB Script de Microsoft– en que no había demasiadas opciones y que la Internet comercial y ommipresente estaba todavía en sus inicios.

El lenguaje, por su sencillez, podía ser compilado e interpretado muy eficientemente. Hoy en día, en un programa “pequeño” el PHP sin precompilar (o sin cachear, lo que hace el eaccelerator) sigue siendo más rápido que un Python precompilado (que a su vez es mucho más eficiente que Ruby). En unas pruebas que hicimos en clase de AdmSO, un “hola mundo” en PHP generaba casi 6000 páginas por segundo en mi portátil. En el mismo ordenador, Python no llegaba a 4000. Esta velocidad y eficiencia tiene su coste, por ejemplo la falta de polimorfismo, la diversidad de funciones, la falta de namespaces, etc.

PHP también supo resolver los problemas de su época, aunque hoy todos estemos convencidos que un modelo MVC (o MTV) como el Django, Rails, PHP Cake o Struts sean la “bala de plata”, no es ni ha sido siempre así. En el desarrollo web se usó y sigue siendo útil el modelo de desarrollo “basado en la vista” sin “efectos colaterales” en las otras vistas que permiten un prototipado poco ordenado y quizás caótico, pero extremadamente rápido. Es decir, se pueden definir las páginas que serán visibles al usuario –lo que suelen hacer con el “árbol de navegación”– y programarlas de forma independiente sin que la modificación de una implique u obligue a cambios en las otras vistas.

Esto último no es lo habitual en el desarrollo de aplicaciones web MVC, a menos que tengas perfectamente diseñado y resuelto  de antemano cuál será el uso final y la arquitectura del sistema (algo bastante raro en proyectos novedosos o en startups, véase por ejemplo el caso paradigmático de Twitter). A diferencia del PHP “plano”, en un modelo MVC como Rails o Django (supongo que en Struts debe ser similar, no lo conozco) hay que mantener sincronizados el controlador, las vistas y las plantillas. Se puede “forzar” a tener un fichero independiente para cada vista y plantilla, pero eso exige duplicación de trabajo y se pierden algunas de las ventajas del MVC (aunque la  DRY –Dont Repeat Yourself– sigue prevaleciendo como fundamental).

Además de los puntos mencionados anteriormente –eficiencia y velocidad del intérprete, prototipado rápido– tiene otras ventajas que han tenido mucho que ver con el éxito del PHP: es libre, multitud de código y ejemplos en Internet, las librerías de PEARL, facilidad para implementar frameworks adaptados a las necesidades de una aplicación –como el EZ DB simplificado y optimizado del Menéame–, una curva de aprendizaje muy suave y quizás la fundamental, la calidad de la documentación en línea de PHP.net.

En resumen. No existen las soluciones mágicas, diseñar buenos lenguajes es muy difícil, incluso los lenguajes a priori muy malos tienen sus ventajas y no hay que descartarlos sobre todo si han tenido el éxito que tuvo el PHP, uno de los primeros lenguajes dinámicos usado de forma masiva en Internet (después de Perl –cuyo equivalente “empotrado” en el servidor web, el mod_perl– es bastante duro para programar).

Además PHP no ha dejado de evolucionar, así en la versión 4 (liberada en mayo del 2000) se incluyó  programación orientada a objetos, muy mejorada en la versión 5 (2004) que incluyó también construcciones importantes como las excepciones.

Todo esta reflexión fue generada por un artículo en principio “troll” pero en el fondo provocador, de esos que me gustan mucho. Un ejemplo de todo lo contrario se puede leer en este otro artículo que usa de excusa a PHP Sucks, But It Doesn’t Matter para demostrar públicamente la ignorancia sobre el tema. Así dice:

Siempre me ha parecido la “versión amateur” del ASP. Sin orientación a objetos hasta hace poco, Testeo unitario, manejo de excepciones y con una serie de aspectos que me han tirado siempre de espaldas cada vez que he intentado hacer algo con él.

En este apunte ya desgrané parte de la respuesta, además ya respondí brevemente y punto por punto.

Si este apunte hubiese sido de un jovencillo que empieza su andadura en el desarrollo o estudios de informática no me hubiese extrañado nada esa divulgación de mentiras, la ignorancia del tema del que habla, la falta de un mínimo de contraste –tan fácil que es recurrir a Google, la Wikipedia o PHP.net– y la defensa cerrada y numantina de una tecnología –ASP y VB Script– propietaria de una empresa y que prácticamente no tiene “mercado web” más allá de las empresas cautivas de Microsoft (módulo MySpace).

Tampoco me hubiese molestado si un “profesional” afirmase desconocer completamente el PHP, nadie está obligado, ni siquiera es posible, conocer todas las tecnologías que existen en informática. De hecho es un acto de honestidad enorme y poco frecuente que un blogger reconozca que no sabe de un tema.

Pero en este caso se hacen afirmaciones contundentes de un profesional que afirma tiene un máster, fue consultor y ahora responsable de tecnologías de la información de una empresa.

Ya ha llovido mucho, pero no deja de soprenderme el nivel de disfunción metacognitiva de los supuestos profesionales –mis colegas–, ¿cómo se puede ser consultar con tanta ignorancia de lo que “hay allí fuera”? ¿cómo este tipo de profesionales pueden llegar a ser responsables informáticos de una empresa?

¿Cómo pueden tener las empresas semejantes responsables? ¿No es una contradicción que sean las mismas que se quejan de la capacidad de los técnicos o de la formación universitaria? ¿No saben aplicar filtros para sus directivos? ¿O valoran más otras capacidades y luego se quejan de la carencia de las que ignoran?

Aunque hace años que se lleva la moda new age de pensar erróneamente que todas las opiniones son respetables.  Lo único respetable son las personas, en cambio hay opiniones que no se merecen nada de respeto. Si además se trata de obviar o mentir sobre temas técnicos objetivos de un profesional, deberían ser consideradas basura absoluta.

Deberíamos aprender de una vez a opinar como verdaderos profesionales, conocedores de lo que hablamos y/o contrastar mínimamente antes de hacer afirmaciones tan gruesas. No se trata de usar las “provocaciones inteligentes” de otros para manipularlas y usarlas de excusa para “salvar el culo”.

Porque al final me parece que este tipo de FUDs son [mala] excusa para justificar años  de decisiones incompetentes que han dejado a su empresa totalmente cautiva de lo que pueda hacer o dejar de hacer Microsoft.

I’m really pissed at Microsoft. Why?… Amazon doesn’t offer EC2 for Windows, just Linux… And I’m stuck with two Windows boxes at my hosting company, hosting a dead fucking end. My bet on Microsoft in the late 90s just ran out of gas. — Dave Winer en  Early notes on GoogleApps.

Vale. Salvad vuestros culos como podáis, pero no echéis mierda alrededor, que nos pringamos y cabreamos todos.

AvantHotel, el retorno

Hace más de tres años escribí un apunte criticando las decisiones que se habían tomado con AvantHotel. Básicamente que aunque había cierto interés en que el iBit lo libere, al final se cedió a la presión de unos pocos y no llegó a liberarse. Mi crítica iba en dos sentidos:

  • Era un oportunidad desperdiciada para que Balears se convierta en referente de software relacionado con el negocio turístico. Históricamente las regiones o países se convertieron en líderes de software en aquellos sectores donde ya existía una industria potente. Así los alemanes son o fueron líderes en software de control industrial, los italianos en los relacionados con industrias alimentarias y automovolísticas, los franceses en aviónica, etc. Balears es un líder mundial en turismo –por cadenas hoteleras, de aviación, turismo receptor, etc.– pero casi no contábamos en el software.
  • El software había estado desarrollado con fondos públicos, fundamentalmente europeos, por lo que debía haber un compromiso ético para dejar disponible ese software a todas las empresas. El hecho que cada una pudiese hacer lo que desease con el software sin tener que pedir permiso a nadie sin duda mejoraría la calidad e innovación de ese software. Además ayudaría a establecer estándares, fundamentalmente para el B2B.

La buena noticia es que después de más de tres años, finalmente el iBit liberó el AvantHotel, además con la Affero GPL, lo que hace un doble acierto.

Además que quizás sea un poco tarde, el “pero”, por lo poco que sé, es que se libera la versión de 2005, mientras que se cede los derechos de autor a las empresas. No sé en qué condiciones ni a quienes, ni la diferencia entre las “versiones” actuales y las del 2005. Pero sin duda alguna es una decisión valiente, ojalá tengan éxito.

Felicitaciones :-)

Categorías:software libre Etiquetas: , ,

Diseño, ingeniería, ágiles… y frameworks

abril 16, 2008 42 comentarios

Entre 1992 y 2001 participé en unos proyectos europeos gordos de R&D relacionados con gráficos, realidad virtual, arquitectura y trabajo colaborativo (RACE Monalisa, CODI, Esprit M3D, eEurope MNM). En todos esos proyectos desarrollamos más de un par de millones de líneas de código (C++ fundamentalmente), y salvo excepciones todas están muertas de risa en algunos discos duros por “problemas de IPR” (Intellectual Property Rigths, creo que eso me influyó mucho para darme cuenta de los problemas de la “propiedad intelectual” en el software). Había socios de todos los tamaños, desde pequeñas empresas, universidades, BBC, Daimler Benz, Siemens, Thompson Multimedia –antes Thomson CSF–, etc. que hicieron más problemático lograr acuerdos, ni siquiera con la spinoff creada (aunque se sacaron productos como ELSET –Electronic Set, para estudios de televisión– que fue llevado a solas por una empresa de Hannover).

En casi todos esos proyectos colaboré estrechamente con Miguel Salles Dias, en su momento presidente de Adetti, hoy directivo de Microsoft (demás está decir que casi no lo ví desde que entró en Microsoft :-( ).

Miguel era un fanático de lo que estaba “revolucionando” la ingeniería en aquellos años, el UML. Tanto que pasábamos horas –muy a mi pesar– estudiando los libros relacionados con UML que compraba para luego intentar aplicarlo en el desarrollo de nuestros proyecto –donde trabajaban más de 30 desarrolladores de 9 ó 10 países distintos–. Nunca nos ha ido demasiado bien, la verdad.

Suponíamos que se debía a que éramos unos inútiles, o lo que hacíamos era muy nuevo o bastante experimental, por lo que intentar convertir en predecible lo impredecible se hacía una tarea imposible. Al final imperaba el “diseño mínimo” –la arquitectura– y luego un proceso bastante evolutivo que se corregía cada mes o mes y medio en nuestras reuniones periódicas entre desarrolladores y “usuarios” que quedaban documentados de forma bastante caótica en los deliverables.

Esos fueron mis últimos años donde seguía más o menos el día a día de lo que se cocía de ingeniería del software de grandes proyectos. Luego seguí la pista al Extreme Programming (que decían que era “revolucionario”, pero la verdad es que era bastante parecido y menos radical de lo que se hace en los proyectos gordos de software libre) y algo de patrones, pero poco más, me metí de lleno en temas de software libre, donde la impredecibilidad y el diseño estrictamente evolutivo suelen ser parte de la realidad imperante, quizás también la ventaja fundamental.

Después de varios años casi desconectado decidí intentar volver a ponerme al día. Hoy encontré un viejo artículo de Martin Fowler del 2000 pero actualizado en el 2005, New Methodology e Is Design Dead?

Son interesantes y algunas de las frases e ideas me parece geniales. Pero poco más. Seguí los enlaces –recomiendo el ejercicio pero de forma no guiada– y me encontré con mucha charlatenería, sin dar un ejemplo práctico, ni un sólo documento, ningún análisis comparativo de caso reales. Casi discusiones metafísicas sobre bondades y problemas de las diferentes metodologías (Yagni, XP, UML, patterns, planificado, evolutivo/incremental/interativo, etc.).

Ya, son sólo artículos y ensayos, pero me sorprende que haya tan poca “chicha”. De todas maneras parecen referencias en sus campos, debe ser por algo. Pero me soprende que en uno de esos artículos –de hace pocos años– justifiquen a los “diseñadores” y el “diseño complejo” (como contrapuesto a los “ágiles”) como la única forma de obtener frameworks y módulos reusables genéricos.

Me chirría, será por el momento obsesionado con Django y similares.

Si se analizan los frameworks de programación que más impacto están teniendo en el diseño web, estos son Rails y Django (o el propio Webapp de Google). Hasta donde llega mi conocimiento son el resultado del “diseño evolutivo” de unos hackers, a pesar que los hacks son uno de los pecados capitales de las metodologías complejas.

Debo reconocer mi gran desconocimiento de las profundidades del área, o de los múltiples frameworks para tipos de proyectos que desconozco, pero me resulta muy curioso. Aunque no sé todavía si los Rails o Django respaldan a metodologías ágiles, o a los hacks… o no dicen absolutamente nada. Si es lo último, ¿qué frameworks son los que significan algo?

Pero no debo ser especímen raro, hay otros que afirman –y parecen– saber muchísimo pero se atreven a hablar de pseudociencias para describir los “avances” de los últimos años.

Seguiré leyendo. ¿Alguna recomendación? ¿algunos buenos blogs que escriban sobre el tema que comento?

Categorías:internet, software libre Etiquetas:
Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

Únete a otros 428 seguidores