bitácora de uno

Con esta entrada vamos a comenzar a meternos en harina en lo que a desarrollo de software se refiere y a las últimas tendencias en ingeniería de software.

Desarrollar software de verdad debe cumplir con unos requisitos ideales. Supongamos que no queremos desarrollar mierdas.
1.- Queremos que funcione bien y de acuerdo lo que nos han pedido - o hemos pensado - que haga. Cumple.
2.- Lo que haga que lo haga rápido. Eficaz.
3.- Me gustaría poder ponerle y quitarle funcionalidad sin que sea el infierno. Va a ser modular.
4.- Paso de casarme con una plataforma, forma de comunicarme o con un sistema operativo (aunque sea GNU), quiero que la gente se lo instale en lo que tenga SIN problemas. Multiplataforma.
5.- Si cumpliendo lo demás puedo hacerlo genérico y que me sirva a mi o a otras personas en otros proyectos: Fetén. Reusable.

Desarrollar software que cumpla con esta lista es difícil. Cuando te has pegado con varios sistemas, has visto cómo desarrollaban otros, has pensado mejoras o las has visto luego de haber implementado algo, y en definitiva cuando has estado varios años en un caldo de cultivo provechoso en este sentido, te conviertes en alguien que atisba más fácil y rápido arquitecturas adecuadas según ves un problema. Te suena el problema y te suena la solución que mejor encaja.

Encontrar este tipo de persona es difícil. Es importante contar con gente así si tu proyecto es medianamente complicado y quieres hacerlo bien.
Además si es difícil hacer las cosas bien desde el punto de vista técnico todo el panorama se suele ver aun más oscurecido por problemas de trabajo en equipo, organizativos, administrativos, económicos, políticos, sociológicos y psicológicos.

La cosa está jodida pero tenemos algún arma. La primera es la ilusión: mola desarrollar cosas complicadas y que salgan bien ¿o no?. El resto de armas tienen mucho que ver con la ingeniería del software y toda la literatura al respecto generada por un montón de gente dándole a las neuronas.

La idea básica que subyace en todo avance en el desarrollo de software (y en otros campos) es que “a ver si currando menos hacemos más y mejor“. Muy loable; puede ser mejor ser inteligente que muy trabajador. Si el trabajo es tedioso mejor automatizarlo y dedicarnos a otros menesteres.

Esto de trabajar menos programando tiene nombre en ingeniería del software: Reusabilidad. Siempre he dicho que si pillan a un alumno copiando en un exámen de programación sólo debería ser suspendido si ha copiado de una fuente mala. “Oiga usted, que estoy aplicando el concepto de reusabilidad“. Bien.

Copiar código, estructuras o ideas de otros en el desarrollo de un software tiene ventajas, algunas fenomenales:
- Me equivoco menos. Cojo algo que ya funciona, ya lo han probado otros y me quito trabajo de teclear, detectar errores de compilación, errores en producción.
- Voy más rápido. Mejora la productividad.
- Me aburro menos. Desarrollo lo que es específico o nuevo para mi aplicación, no tengo que estar haciendo por enésima vez la librería para generar trazas en fichero.

Hay dos formas de Reusabilidad:

Reusabilidad Oportunista:
En general se da porque un programador copia código y lo pega en el suyo. Está bien pero tiene problemas a la larga: genero líneas diferentes para lo mismo y si algo está mal en el origen hay que buscar todos los sitios en donde se ha pegado para corregirlo.

Reusabilidad Sistemática:
Esta es la buena. Aquí copiamos a posta y con un plan calculado. Quiero tirar poco código, equivocarme menos, poner y quitar funcionalidad de forma fácil. Quiero aprovecharme de los conocimientos y trucos de otros que han estado antes “por aquí”.

Nos interesa la Reusabilidad Sistemática y al vasto campo de la ingeniería del software también.

Conceptos como la Programación Orientada a Objeto, los Patrones de Diseño, Frameworks, y Middlewares, las Arquitecturas Orientadas a Componentes, a Modelos o a Aspectos, son todos maquiavélicos planes para perder menos tiempo, para copiar, para trabajar menos.
Los iremos viendo.

;)

¿Que eso no es tuyo? Mira, mira…

El otro día leía en Curioso Pero Inútil una explicación de lo que es un acto reflejo asaz afortunada.
"Te pegan con un martillito en la rodilla y estiras la pierna. Suena un ruido fuerte y cierras los ojos. Aparece Íker Jiménez en la tele y vomitas."

Yo añadiría que cuando oigo a alguien en un equipo decir :”Eso no es asunto mío”, o “a mi no me toca”, o “eso es de otro”, se me llevan los demonios unix.

Si algo tiene de humano el desarrollo de software es la capacidad de trabajar en equipo, y para eso debemos entender que hay beneficios a medio plazo mejores que los que hay a corto. Es verdad que hay empresas de corte norteamericano que te cuentan milongas sobre el trabajo en equipo para que te quedes más horas. Eso es “que trabaje el equipo que yo paso”.

Yo me refiero a un conjunto de personas a las que se enfrentan a un proyecto y deciden poner cierto entusiasmo en llevarlo a cabo con un reparto de papeles y unos objetivos. Ah, además a fin de mes, todos ponemos el cazo. En este tipo de entorno creo que debemos ser mejores egoístas antes que más egoístas. Calidad contra Cantidad. Si todos prestamos atención a un problema y tratamos de hacer algo para resolverlo nos irá mejor a medio plazo que con respuestas tipo el título de esta entrada (cuidado con los enlaces recursivos ).

Cuando uno oye esos comentarios, no hace falta ser Rapel, para ver que o se corta de ráiz o el reino del mal se está infiltrando en el equipo, y el coordinador o jefe debe sentirse responsable y ponerse al servicio de los demás, señalando cuando menos el problema.

Parece que Sergio Montoro no empezó evitando tareas al montar su empresa. Leed la primera frase de esto y lo entenderéis.

El viernes estuvimos en la jornadas de Software Libre que organizaba la UNED. Respirar ese ambiente de ilusión por hacer las cosas, de idealismo y pequeños fallos es como un chute de buen rollo para seguir en esto del software y los servicios, tanto personalmente como en la empresa.

Cada vez veo más claro que el software libre está calando en el mercado. Es verdad que ha habido y hay mucha gente luchando porque así sea, pero es como un hijo que tomará el control de su destino en el mundo que representa un mercado lleno de tiburones.

Las jornadas empezaron con una presentación de los modelos de licencias y sus diferencias desde un punto de vista muy de “software libre bien resto kaka”. Yo personalmente estoy de acuerdo en que resulta hasta indignante que haya software propietario según como se mire, pero exigir un enorme grado de coherencia o compromiso a todo programador o persona, con sus propias circustancias, me parece tan poco adecuado como defender el software cerrado a base de insultos al resto y la exigencia debe tener dos extremos: el de los demás y el nuestro. Además en este caso hay argumentos demoledores y elegantes: no hace falta hacer el molinillo y romperle la cara a todo el mundo.

Esta sesión del viernes fue, ya digo, un gusto, hubo opiniones de todo tipo y la participación fue alta que creo que es de lo que se trata.

A ver para cuando se publican unas reglas para las universidades públicas (las otras también deberían) y en concreto sobre el uso de estándares y software abierto. Antes quizás les había pillado el toro, pero ya no hay excusas posibles o al menos defendibles. NO se pueden pedir los trabajos en formatos propietarios discriminando al que se lo puede permitir del que no, y favoreciendo a una empresa o un producto “porque sí”.

Como alumno de doctorado de la UNED mi compromiso es que me negaré en rotundo a aceptar formatos propietarios para presentar mis trabajos y artículos.
¿Tú compromiso? (El que tú quieras)

Es un poco drástico pero si lo analizamos, en algunos casos debería prohibirse y perseguirse.

A la hora de presentar un proyecto, es interesante contar con una planificación con las fases generales y los hitos principales. Puede servir como guía pero cuando no contamos con los requisitos - que deben salir de una fase de análisis - la utilidad de nuestro bonito diagrama de Gantt es cuestionable desde el minuto uno.

Si hablamos de cuando ya estamos metidos en faena lo de contar con la planificación “actualizada” es una quimera. Mira que he visto Gantts cojonudos en diferentes tipos de proyectos: Pues ni uno ha sido capaz de sobrevivir al proyecto. Como mucho se rehacía uno mirando un puñado de hitos del anterior, para poder presentar a algunos gestores.

Quizás en sectores menos artesanales que el de la producción de software pueda funcionar y seguirse y presentar desviaciones y riesgos. El proyecto “Huevo Frito” se gestiona y se sigue estupendamente, pero quizás para ese viaje me sobren alforjas. En un mundo con tanta indefinición de requisitos, tanto del producto como de los recursos, y si queremos bajar a detalle, un diagrama de Gantt es el infierno.

Scrum (melé, como el el rugby), es un método ágil para desarrollo de productos, y como dice su consigna “Es cuestión de sentido común”. Esta gente ha prohibido los diagramas de Gantt por estas razones.

Más pensamientos provocadores en el Blog de Jeff Sutherland

Escribir un artículo científico o académico es - por un lado - una tarea de recopilación de la literatura existente para saber cómo está el asunto y si nuestra contribución es más o menos novedosa. Por otro lado está el trabajo en sí, y además, las referencias a aquellos trabajos que nos han ayudado de manera positiva o como contraejemplo.

La idea en realidad es que aportes algo a la comunidad, de lo más específico como el grupo de gente que trabaja en lo mismo, a lo más genérico: la comunidad científica y a la postre toda la humanidad.

Para hacer esto es necesario muy útil tener acceso al último grito en publicaciones sobre tu más-o-menos-restringida-área.
Google ha sacado hace no mucho un área de su buscador, especializada en información de investigadores, Google Académico pero te ocurre a menudo que llegas a una revista electrónica de pago. Si no pagas no te bajas el artículo. Vaya, ¿esto no era de la humanidad? Ummm.

En estos casos y si el artículo está en formato PDF, suele estar disponible la opción de ver en formato html, que no siendo tan bonita te da acceso al texto que por humano te correspondería poder leer.

Navega que te navega, y buscando información para la tesis, he encontrado grandes nichos - nodos - de información no indexada normalmente por los buscadores convencionales. Son los archivos de las universidades y centros de investigación a disposición del público de forma gratuita.

Me ha gustado mucho el de la Universidad Complutense de Madrid, en el que he encontrado cositas como una tesis completita sobre la capacidad innovadora de las empresas españolas (aunque no tanto sobre ingeniería del software), y que además utiliza software libre: E-Prints e Instituciones Usuarias. Una joyita para unas horas de infobulimia compulsiva.

Esta aplicación genera archivos de publicaciones electrónicas conformes con el Protocolo de Archivos Abiertos para Recolección de Metadatos OAI 1.1 y 2.0., Open Archives Initiative.

Dejaré más enlaces hacia este tipo de información.

1.- http://www.uned.es/biblioteca/recursos/nv/informatica.htm
2.- http://www.scirus.com/srsapp/

Código Abierto + Estándares Abiertos + Archivos Abiertos + …

Hoy, me he vendado los ojos y V. ha ido alternando el comienzo de la misma canción, entre reproducción calidad CD, y reproducción a 192 kbps, en un prueba, y entre reproducción CD y mp3 a 128 kbps en otra. Todo esto equilibrando el volúmen para que no se notaran los cambios.
Total, que mi sorpresa ha sido mayúscula: Entre CD y 192 kbps no he dado ni una. Entre CD y 128 kbps parece que hay algo más de acierto que el debido al azar, pero poca cosa más. De lo que podemos concluir que con mi oído actual y, suponiendo que no evolucione demasido rápido, debería considerar la opción “mejores vacaciones y ahorro en equipo de música“.

¿Qué pueden tener que ver un equipo de alta fidelidad, una botella de vino y un producto software?

Todos ellos son productos de consumo. Alguien o algo los intenta vender explicando más o menos sus características de forma también más o menos honesta o veraz. Por otro lado existe otra parte destinataria de las ventas que pueder ser más o menos compulsiva, arriesgada o conservadora en su estrategia de compra.

Independientemente del perfil que tengamos como consumidores, que nos guste o no somos, no debe faltarnos nunca una buena dosis de escepticismo sano. Se trata de aplicar el método científico a la vida cotidiana, algo que en realidad sabemos hacer con según qué cosas. Si nos fuéramos a comprar un coche de segunda mano, nunca lo haríamos a ciegas dejando que el vendedor nos convenza con un: “Tenga usted fé“. Y si lo hiciéramos una primera vez, a la segunda ya andaríamos pidiendo el libro de revisiones.

Sin embargo nos creemos determinadas publicidades sin prueba alguna: “Churuflú lava más blanco” o “Churuflú le deja los dientes más blancos” o “Vote Churuflú: Nos irá mejor”. Oiga: ¿Por qué me va a ir mejor? ¿Me puede explicar de dónde saca usted esas conclusiones? ¿Dónde están las pruebas, si no le importa, que corroboran que el tal Churuflú lava más blanco?

Si todos hiciéramos lo propio habría menos fraudes, mejores productos, menos charlatanes, mejores programas electorales, etc. Pero nos queda un enemigo que batir que es el que representamos nosotros mismos. Tenemos una estupenda capacidad para engañarnos o para interpretar los datos como nos venga bien. Si, pero también podemos hacer pruebas a ciegas.
Eso es lo que hemos hecho hoy V. y yo con un reproductor mp3 y un equipo de Alta Fidelidad que contaba con un reproductor de CD’s con un precio unas diez veces superior al del mp3.

En realidad, tú también eres parte de la cadena de música. Eres el importante eslabón receptor del final.

Estoy deseando someterme a una prueba - si no es a ciegas no vale - en el que reproducir de forma aleatoria la misma canción a diferentes resoluciones. Lo pondré por aquí por si quieres también probarte, o también lo puedes intentar tú (idealmente antes de haberte gastado la pasta en tu equipo de música).

Lo mismo ocurre con los vinos. Somos muy influenciables si un amigo o el sumiller nos habla previamente del vino. Prueba a hacerlo a ciegas o tapando las botellas e incluso desafía al experto en música o en vinos a que participe en la prueba.
Este tipo de escepticismo beneficia a la empresa o al consumidor particular de software. Además también beneficia a los buenos productos software y si éstos son “software libre” pienso que más todavía.

El software libre encaja y se beneficia estupendamente en la corriente de escepticismo, ya que - si está bien hecho - soporta las comparaciones de forma clara y transparente, y tiende a despuntar ante el obscurantismo de determinados software propietarios, proporcionando buenas y fundamentadas elecciones y resultados a los responsables de la elección del software en la empresas. Es una manera de eliminar malos productos. La luz es un desinfectante cojonudo, como dijo alguien.