Angel Retamar Arias

Buenos profesionales o trepas?

Como todo el mundo, a lo largo de mi vida profesional, me he encontrado (ocasionalmente o no tan ocasionalmente) con los típicos "trepas" que "en este mundo abundan". Siempre me ha llamado mucho la atención este "perfil profesional" (por llamarlo de alguna forma). Es realmente interesante cómo personas, con habilidades tanto técnicas como personales muy limitadas pueden ascender con tanta facilidad en sus trabajos.
Yo creo que la clave está en la personalidad. Son gente con ambición y que "viven profesionalmente por encima de sus posibilidades". Por ejemplo, si su trabajo es programar, van a dedicar más tiempo del que deberían a diseñar o a escribir documentos funcionales, o cualquier otra tarea en principio de más nivel del que les correspondería. Si tienes a un programador (trepa) con algo más de experiencia y le encargas "controlar" un grupo de juniors, enseguida se montará un diagrama Gantt para seguir el progreso de "su" equipo (cuando en realidad, coño, solo tenía que echarles una mano de cuando en cuando!!).

Lo mas curioso es cómo estos tipos (y tipas, para que nadie se ofenda) consiguen engañar a sus superiores. Muchas veces trepas iguales que ellos. Otras veces, profesionales a los que en principio, respetas. Todos a la larga caen engañados por los trepas. ¿Como lo hacen?

Yo tengo una teoría. Últimamente me ha tocado tener algo de responsabilidad sobre un grupo de desarrollo, en el que trabajamos en varios proyectos. Al final, como responsable ¿que es lo que valoras de la gente con la que trabajas?: El compromiso. Lo que mas valoras es que puedas encargar un trabajo a una persona y tengas las mejores garantias de que esa persona lo va a hacer tan bien (al menos) como tu lo harías: se va a preocupar porque todo salga bien tanto como te preocuparías tú, si no da tiempo se dará cuenta y actuará en consonancia (al menos, como lo harías tú), sabrá decidir cuando hay que echar mas horas y cuando no, y si toca pringar, pringará como pringarías tú. Si tiene que lidiar con una tecnología desconocida, sabrá ponerse al día por su cuenta, etc. En resumen, un buen profesional desde el punto de vista de un responsable, es alguien en quien puede confiar tanto como en él mismo.

Normalmente los trepas encajan en este perfil. Son gente con ganas y con ambición. Gente que se busca la vida, que se preocupa (o eso parece), etc.

La diferencia entre un trepa y un buen profesional es que éste último asume las responsabilidades y las lleva a cabo con SU trabajo. Un trepa asume las responsabilidades ante su superior y luego consigue que los demás hagan el trabajo sucio, poniéndose luego las medallas.

Como siempre termino con la pregunta...Seguro que todos conoceis a algun trepa (o varios) ¿se ajusta a este perfil?

Programación, Java y Videojuegos Hoy leyendo las noticias de JavaHispano me encontré con esta: http://www.javahispano.org/contenidos/es/liberada_la_version_1_0_jmonkeyengine__una_libreria_para_construir_juegos/ . Hace tiempo me dio por echarle una ojeada al jmonkey este, simplemente por frikismo, no por nada en particular y me pareció que tenía buena pinta. Me he acordado de cuando era joven y queria dedicarme al tema de los videojuegos. El caso es que, si en la tele no mienten como bellacos (cosa que no descarto), cada poco están diciendo que si el mercado de los videojuegos factura tropecientos millones, que si tiene un crecimiento del nosecuantos porciento. Entonces, ¿por qué en España (ya no digo en Asturias porque sería un cachondeo) hay tan pocas empresas en ese negocio?... ¿será porque, al fin y al cabo, los videojuegos no dejan de ser un producto software y a las empresas de aquí el tema de los productos les da tirria? Y eso nos vuelve a llevar siempre al eterno debate de lo bien que nos iría si en lugar de hacer siempre "ñaplicaciones" ad-hoc en "modo consultoría" las empresas tuviesen lo que hay que tener y apostasen de una vez por desarrollar productos, construidos una vez y vendidos miles. A ver si nosotros (o nuestros hijos, difícil, mas probable nuestros nietos) llegan a ver una SAP, Oracle, Sun, etc, española.

Diez consejos para desarrollar sofware de calidad

Ultimamente (por temas de trabajo, ¿por qué si no?) he estado reflexionando mucho sobre las cosas que nos funcionan y las que no a la hora de desarrollar un producto software. El objetivo es minimizar los bugs, detectar el máximo posible de ellos ANTES de la entrega al cliente y facilitar el mantenimiento.

Y como ahora está de moda contar cualquier pijada en "formato ranking" pues ahí van mis:

Diez mejores prácticas para desarrollar software de calidad:

1.- Asumir (como equipo de desarrollo) la responsabilidad de la calidad del proyecto. Seamos sinceros con nosotros mismos, a los "de arriba" les da igual la calidad técnica del proyecto. Con cubrir los requisitos del pliego, aunque sea de refilón y que funcione bien el día de la presentación les sirve y sobra. Si queremos hacer software de calidad tenemos que asumir que eso va a ser cosa nuestra y de nadie mas.

2.- Cualquier esfuerzo para evitar pringar horas una vez que te ha caido el marron es inútil. Los "de arriba" siempre tienen mucha imaginación a la hora de idear requisitos imprescindibles. Si un proyecto va mal de tiempo, la reacción habitual suele ser acelerar el desarrollo (vamos, picar codigo sin pensar, sin probar, sin calidad) para evitar pringar "horas extra". Al final, parece que te da tiempo a cubrir la funcionalidad que te habian exigido y entonces: ¿que es lo que sucede?. Que aparecen nuevos requisitos "imprescindibles". Y otro atracón y según vas acabando aparecen más y mas requisitos "imprescindibles". En resumen, una vez que "los de arriba" deciden que toca pringar es que toca. El equipo ya está sentenciado. Si acaba las funcionalidades se meten más y, por supuesto, el 90% de estos nuevos requisitos nunca son imprescindibles. No es muy lógico que nadie se acuerde de alguna funcionalidad, con tanta importancia como para ser imprescindible, un mes antes de la puesta en producción ¿verdad?.

3.- Definir cuanto antes el alcance del proyecto. Si la definición funcional del proyecto está en nuestras manos, es importante dedicar un tiempo, no mucho, a definir funcionalmente el proyecto: identificar las funcionalidades verdaderamente imprescindibles, seleccionar las tecnologías, etc. Lo habitual en estos casos.
Si la definición funcional no es cosa nuestra, entonces es cuando se debe aplicar lo comentado en el "punto 1" y, aunque no sea nuestra responsabilidad (ojo que esto es muy importante), perseguir al analista funcional (o al gerente, comercial, cliente o quien sea) y darle la chapa hasta que cumpla.
Lo que no se debería hacer es esperar pacientemente por ese documento que nos hace falta para poder empezar. En mi opinión, tampoco es muy buena idea ir adelantando el desarrollo sin tener cerrada la funcionalidad (aunque es algo que se suele hacer bastante).

4.- Escribir una lista de funcionalidades a cubrir. La lista debería dar, con un vistazo, una impresión general de las características del producto a desarrollar. Por lo tanto, las funcionalidades no deberían ser de grano muy fino.
La lista debería estar ordenada por la prioridad de cada funcionalidad. Esta idea es mucho mejor que asignar a cada funcionalidad un campo: "prioridad" (porque al final, todas las funcionaliades acaban con "prioridad ALTA").

5.- Analizar al detalle cada una de las funcionalidades de la lista (punto 4) y desmenuzarla hasta obtener una nueva lista de requisitos (o historias de usuario, o como se quieran llamar). Las historias de usuario deberían ser funcionalidades atómicas. Se cumplen o no se cumplen, pero no tiene sentido que se queden a medias. Si se consigue esto, podemos garantizar que una aplicación con historias sin finalizar está inestable y, por lo tanto, no se puede poner en producción (al menos no se debería, luego allá cada uno con su conciencia...)

6.- Desarrollar las historias de usuario de forma ordenada. Implementar una por una, siguiendo el orden de la lista. Evitar abrir una historia antes de cerrar la anterior. Cuantas mas historias abiertas haya mayor inestabilidad tiene el producto. Cuando se termine una historia integrarla rápidamente con las demás. De esta forma, siempre es mas fácil empaquetar versiones intermedias (milestones) y sobre todo, no se deja la integración de todos los componentes para el final.

7.- Ser consecuente con el concepto de CIERRE de cada funcionalidad. Ser consciente de que cerrar una funcionalidad implica darla por finalizada y no volver a preocuparse mas por ella. Normalmente solemos engañarnos y decir cosas como: "Esto esta así, pero ya lo remataré mas adelante" o "Esto esta terminado, solo queda probarlo". Mentimos. Lo que dejamos para "mas adelante" al final nunca se hace, se queda siempre así. Así que lo mejor es asumirlo y tenerlo en cuenta al cerrar una funcionalidad. Por eso, procurar NUNCA dar por cerrada una historia si el código no tiene la calidad que nos gustaría y, sobre todo si no está todo probado a conciencia.

8.- Llevar un registro escrito de los cambios en las especificaciones y requisitos. Solamente hay una cosa tan desagradable para un desarrollador que los cambios constantes en los requisitos de un proyecto: los cambios constantes en los interfaces de los sistemas con los que se hay que integrar. Por eso, para evitar "malentendidos" posteriores (y porqué no, para cubrirse las espaldas en caso de que haya "reparto de mierda") nunca está de mas llevar un registro con los cambios: las fechas en que se realizaron, la persona responsable, el motivo del cambio, etc.

9.- Replanificación ante cualquier cambio. A vuelta de correo, de telefono, o de lo que sea, antes de decir "SI" a un cambio (en los requerimientos, en los interfaces, etc.) hay que ser capaces de calcular lo que puede llevar y replanificar el proyecto. Y entonces contestar "SI...pero...", indicando el coste que tiene dicho cambio. Que quede claro desde el primer momento. Nunca hay que aceptar un cambio sin conseguir algo a cambio.

10.- Esta última queda para vosotros. ¿Hay alguna receta mágica que incluiríais en este ranking?. Como siempre, agradezco cualquier comentario.

Life at Google

Estaba leyendo este post: http://no2google.wordpress.com/2007/06/24/life-at-google-the-microsoftie-perspective/ y no he podido evitar postear algo al respecto.
Trata, mas o menos, de 10 razones para no trabajar en Google. Yo solamente he leído la primera y no he podido seguir. Mas o menos, reza así:
1.- ... ¿Cuantas horas al día trabaja la gente (en Google?...

Respuesta (traducción libre):
bla, bla, bla... estos frikis (N del T: para referirme a Geeks) no tienen vida privada y curran como cabrones y ademas, la empresa les engaña porque les da: 2 camisetas a la semana, 3 comidas al día completamente gratis (y al parecer abundantes), seguro sanitario y dental "IN SITU" (como las garatias), les lavan la ropa, tienen gimnasio, etc. pero les hace trabajar en un horario infernal: DE 10:00 a 18:00 !!!!

No hay mas preguntas señoría...

Siguen faltando profesionales de la informática

Acabo de leer en el periodico "La Nueva España" de Asturias una nueva entrega del culebrón de este verano: "Hacen falta tropecientosmil profesionales de la informática" (http://www.lne.es/secciones/noticia.jsp?pRef=1769_52_560241__OPINION-serio-problema-falta-informaticos-Asturias). En este articulo, las empresas autóctonas del sector, mas o menos vienen a decir que se quedan sin profesionales porque otras empresas de fuera (del extranjero) pagan mas y además reciben subvenciones del gobierno y, al parecer, ellos no.
Entonces, ¿cuál es la genial solución que han adoptado?: Hacer unos cursos de formación (de unos meses) para reciclar a personas de otros sectores (filosofos, licenciados en derecho, en empresariales, etc.) y convertirlos en programadores.

Personalmente, dudo que esta medida permita mejorar la productividad y la calidad de los servicios y también dudo que las empresas medianas y pequeñas puedan competir con las grandes consultoras con otra cosa que no sea mejor calidad y mayor productividad, como muy acertadamente opinaba en su blog (http://pablopriesca.es/2007/06/02/el-problema-de-los-rrhh-en-el-sector-tic-en-asturias) Pablo Priesca, que es el Gerente de la Fundación CTIC y una de las personas más influyentes en esto de la informática (http://www.seniornet.es/Pablo-Priesca-es-uno-de-los-mayores-influyentes-en-Internet_a555.html).

Yo animaría a estas empresas a arriesgarse un poco más, dejar un poco de lado el negocio relativamente seguro de la industria cárnica y apostar por desarrollar productos tecnológicos propios e innovadores, de calidad, que les permitan competir de tú a tú con cualquier gran empresa del sector.

Por último, ahí dejo para la reflexión unas cifras (obtenidas de Infojobs, para Asturias):

Profesionales de la Informática y las Telecomunicaciones:

No especificado (68)
Menos de 6599 € (3)
Entre 6600 y 13499 € (5)
Entre 13500 y 16499 € (5)
Mas de 16500 € (7)

Ingenieros e Ingenieros Técnicos (otros sectores):

No especificado (47)
Menos de 6599 € (5)
Entre 6600 y 16499 € (4)
Entre 16500 y 28499 € (4)
Mas de 28500 € (5)

Los salarios en el sector TIC

A ver si, siendo éste un foro de programadores Java, el único en el que no se va a tratar el tema de los sueldos del sector. Pues nada, habrá que ponerle solución al asunto:

Para quien ande perdido y no le de mucho por leer foros o blogs (a parte de este portal, claro está); aquí van unos cuantos enlaces que tratan el tema, para ir poniéndose en situación:
- http://hronia.blogalia.com/historias/50882
- http://meneame.net/story/faltan-programadores-alla-va-respuesta
- http://pablopriesca.es/2007/06/02/el-problema-de-los-rrhh-en-el-sector-tic-en-asturias/
- http://www.ingenierosdeprimera.com/node/645

En resumen, para el que no quiera leer tantos enlaces el asunto es: El sector TIC, el sector de la innovación, el que tantos titulares (y subvenciones) se lleva, la "gran esperanza blanca" de la economía española (supongo que en hispanoamérica el tema será parecido, ¿algún compañero hispanoamericano quiere dejar por favor algun comentario para contarnos como van las cosas por su pais?), el sector para el que no hay (ni habrá) profesionales cualificados en nosecuantos años... es uno de los sectores con salarios medios mas bajos; y esta estadística es a todos los niveles, desde profesionales sin experiencia hasta los más cualificados. Además, es uno de los sectores que menos directivos aporta a las empresas ¡Incluyendo las propias empresas del sector!!

Y ahora mis "dos centimos", como se suele decir...

Vamos a la raíz del problema. ¿A qué se debe esta situación?. No me acuerdo exactamente de las cifras pero me suena que el volumen de facturación en consultoría y desarrollo de proyectos es, mas o menos, el 90% del total del sector (en concreto, en Asturias me parece que un 80% de la facturación total del sector se va en proyectos para la Administración Pública. Si me equivoco, por favor que alguien me corrija).

Si no me equivoco mucho con las cifras, esto quiere decir que la situación laboral de desarrolladores que trabajen otros sectores: productos software, construcción de hardware, etc. es irrelevante de cara a las estadísticas. Lo que ocurra en el sector de la consultoría va a determinar la política de todo el sector.

Entonces, la culpa de todo la tiene el modelo de negocio de las consultoras. ¿Por qué? Porque en un proyecto de este tipo, cuando el desarrollador entra en acción, el proyecto YA ESTÁ VENDIDO!!!!.
Entonces, ¿para qué quiere la empresa pagar más a mejores programadores?. Mejor pagar menos y así poder competir por precio en la oferta. Total, la mejor calidad la van a prometer todos: los que se gastan un pastón en los mejores programadores y los que pagan cuatro duros a chavales recién salidos de la carrera.

¿Aquí que es lo que interesa?. Comerciales. Los comerciales son los que facturan, los que en realidad producen, los que venden humo.

Muchos desarrolladores ingenuos pensamos: "A ver, al cliente le están facturando 100€ la hora por mis servicios. Luego yo valgo un pastón..." Y no, mentira. Al cliente le cuelan esos 100€ por tí o por cualquier otro recién salido de la carrera. El mérito donde está: en el comercial que le vendió la moto al cliente. Y si tu, con toda tu experiencia te largas, el mérito donde está: en el comercial que convence al cliente de que te sustituyen por otro ingeniero igual de cualificado, cuando en realidad te sustituyen por el primero que encuentran.

Parece mentira que nadie lo reconozca públicamente. Este es un negocio de trileros, de timadores profesionales con traje y maletín. Vivimos bajo el "reino del terror" de los comerciales. ¿Qué comercial conoceis que sepa remotamente de lo que habla cuando vende un proyecto a un cliente? Ninguno. Lo que hacen es decir que sí a todo lo que diga el cliente, ofertar plazos y precios mas ajustados que la competencia y a cobrar la comisión.

Ahora, cuando un tio que no tiene ni idea de lo que implica, desde el punto de vista técnico, hacer realidad el humo que vende, ¿que pasa?:
a) Que ajusta los precios a la baja una barbaridad. Lo que implica que hay que hacer el proyecto con menos recursos (personas normalmente) y/o, lo mas habitual, pagar sueldos muy bajos.
b) Que ajusta los plazos a la baja otra barbaridad. Entonces, como ya ajustó también el precio y esto habíamos quedado que implicaba involucrar a menos personas, no queda mas remedio que, los cuatro gatos que quedan, echen horas como forzados, encadenados al PC.

Total que la final, los proyectos siempre se acaban trabajando horas extra. Y la muchas veces las horas extra hay que echarlas porque "si no nos comprometemos al plazo X, se pierde el proyecto". Y con esto todos contentos. Pero coño, al comercial si que le pagan la comisión: ¿y que mérito tiene vender un proyecto que dura X jornadas en la mitad? ¿o hacer un descuento del 30% en el precio del proyecto?. Al final, todos estos "regalitos" para conseguir el proyecto se acaban pagando con las horas extra de los desarrolladores. Así que ya sabeis, cuando esteís echando horas extra, estais pagando la comisión de un comercial que no fue capaz de vender el proyecto con el plazo y precio con que los debería haber vendido.

(No me imagino a un comercial de la BMW orgulloso por haber vendido un M3 en 10.000€ y encima pidiendo comisión.)

Pero eso sí, el negocio funciona y todos contentos: la empresa se lleva el proyecto, el comercial se lleva la comisión y el desarrollador "tiene la oportinidad de enfrentarse a un reto muy interesante tecnológicamente hablando e involucrarse en el desarrollo de un proyecto puntero en el sector" (vamos, hacer cuatro informes con JSPs).

Fabricas de Software (II)

El otro día me aptecía postear, preguntar a la gente sobre las Fábricas de Software. Tenía y sigo teniendo, mucho interés en el tema. Lo que el otro día no tenía era mucho tiempo para postear y creo que, por los comentarios que he recibido, no he conseguido explicarme muy bien. A ver si hoy consigo explicarme un poco mejor...

Desde mi punto de vista, esto de las "Fábricas de Software" solamente se aplicaría al desarrollo de productos (es decir, aplicaciones no desarrolladas para un cliente concreto, mas bien para ser vendidas varias veces a cuantos mas clientes mejor).

Logicamente, cualquier equipo (o empresa, o lo que sea) que se dedique a hacer proyectos "ad-hoc" (o llave en mano) nunca va a tener el más minimo interés en montar semejante infraestructura. Así, de mano, se me ocurren varias razones:
- Los proyectos viven del corto plazo. Un proyecto con un horizonte temporal de mas de un año es un proyecto, como mínimo, grande. Para un producto un horizonte temporal de un año es una autentica ruina.
- Los proyectos se venden "a priori", antes de ser desarrollados. Una vez vendidos, lo mas importante es conseguir el mayor margen posible. Esto implica contratar personal barato (baja cualificación, poca experiencia, etc.). Además, como normalmente hay un "pliego de condiciones" (o similar), lo importante es tirarse a cubrir la funcionalidad especificada, sin centrarse en florituras, ni preocuparse por la estabilidad del desarrollo. Vamos, lo que llaman "sin perder el tiempo".
- El mantenimiento también es muy diferente. Al final, en un proyecto, los usuarios finales son casi siempre los mismos y usan el software siempre para las mismas tareas y siempre de igual forma. Las funcionalidades están muy acotadas y los fallos también. Y en el peor de los casos, siempre se pueden ir parcheando los fallos que vayan apareciendo sobre la marcha.

Bueno, entonces pongamos que nos centramos en el desarrollo de productos software. Vale, acepto que un desarrollo de software no es igual que el de otros productos como ruedas, botellas o televisores, pero ¿tanto?.
Las empresas que yo conozco aplican téncias de gestion de proyectos al desarrollo de productos. En el post del otro día, simplemente me preguntaba si habrá alguna empresa que aplique técnicas de gestion de productos (productos en general) al desarrollo de productos software.

Alguien me dejo un comentario hablandome sobre RUP. Me parece muy interesante, pero no me estaba refiriendo a una metodología de desarrollo. Por ejemplo Scrum es una metodología que últimamente pega mucho y proviene del desarrollo de otro tipo de productos tencológicos (no especificamente software) y ahí si que conozco sitios donde se usa.

Me refería mas bien a la gestión en general del centro, de la supuesta "factory". Por ejemplo, en la definición de requisitos. ¿Es realmente necesario el baile de requisitos tipico de un proyecto de desarrollo de software al construir un producto?. O también la organización y la burocracia, la gestión de tiempos, la definición de protocolos.

Por ejemplo, hace poco estuve en un curso sobre gestión del conocimiento en las empresas y el profesor del curso en un momento habló sobre "protocolos de contingencia" (o algo así). Son una especie de pasos a seguir para los momentos de crisis. El ejemplo que nos puso era la caída de la energía eléctrica en una central nuclear.
¿Por qué las Software Factories no tienen "procedimientos de contingencia"? ¿Por que no hacemos simulacros para saber como reaccionar si en un momento critico se cae un sistema importante?. Es solo un ejemplo.

Otro ejemplo es la definición de requisitos. En cualquier industria, cuando se plantea la posibilidad de introducir una mejora (una nueva tecnología de inyección, un nuevo sabor, un nuevo material, etc.) a un producto, siempre se hacen un monton de estudios, prototipos, pruebas, etc. ¿Se hace esto cuando se plantea una nueva funcionalidad en un producto software?. Pero es que este tipo de pruebas no son solamente tecnicas, tambien se estudia desde el punto de vista del mercado, de la usabilidad, de la aceptación por parte de los clientes, etc.

Un ejemplo mas, la "automatización del proceso productivo". Nosotros tenemos ANT, Maven, Makefiles, etc. Algunos incluso son capaces de empaquetar todo el producto en un solo paso pero, ¿también distribuirlo, almacenarlo, clasificarlo?. Si un producto software tiene personalizaciones para clientes ¿tenemos automatizada la gestión de nuestro "almacen"?.

¿Cuantas empresas de desarrollo de productos software tienen un CRM para atender a sus clientes? ¿De las que lo tienen, cuantas explotan la información capturada para mejorar sus productos?
¿Existen en alguna empresa de desarrollo de productos personas que trabajan como ingenieros de pruebas (como en la industria automovilistica, aeronautica, etc.), ingenieros de procesos (como en la siderurgia) que trabajan estudiando y afinando los procesos internos de la "factory"?

No pretendo comparar una cadena de montaje con el hecho de "picar codigo", está claro que no es ni parecido. Estoy muy de acuerdo con el comentario que decia que el desarrollo era mas parecido a la fase de diseño de un producto. Pero no estoy para nada de acuerdo en que el diseño industrial (desde mi ignorancia siempre) es caotico. Existen un monton de ISOs, y otras normas internacionales que debe respetar, ademas de estandares de empresa.
¿Las empresas de desarrollo de productos software tienen estrictas normas de estilo de cara al desarrollo y a los componentes, arquitecturas, etc. que se pueden usar?. Las partes funcionalmente similares deberían de ser similares en cuanto a su implementación. Por ejemplo, en una fabrica de botellas, si los tapones tienen dos vueltas de rosca, cuando se diseñan nuevos tapones, o llevan dos vueltas de rosca igual que los anteriores, o hay alguna buena razón para lo contrario. Nunca suele ser por comodidad, gusto, dejadez o manía del diseñador.

Bueno, la verdad es que no se muy bien como funciona una industria de cualquier otra cosa que no sea software, y me gustaría saber si el desarrollo "industrial" de software es parecido en algun sitio. Porque mi experiencia me dice que si esto no se hace es porque en este negocio pesa demasiado el trabajo de consultoría o de desarrollo de proyectos a medida.

Fabricas de Software

Estoy buscando una "Fábrica de Software". No confundir con una "Software Factory", que de esas sí, de esas hay a patadas, pero no es lo mismo.
Mas bien me refiero a un lugar donde se desarrolle software de acuerdo a los principios más básicos de la organización industrial.

La única pista que tengo es que esta empresa (u organismo, fundacion o lo que sea), tiene que desarrollar productos propios. Lógicamente, una entidad que se dedique a desarrollar hoy un proyecto J2EE, mañana otro SAP, pasado "vende dos recursos" a un cliente y al otro día una consultoría de seguiridad, malamente va a poder industrializar su proceso de desarrollo.

Partiendo de esta pista, de que se trata de desarrollar productos software, el siguiente paso es localizar a algún responsable (algún jefazo con despacho propio) que se haya planteado que, software o no software, un producto es un producto, se trate de una aplicación informática, una rosquilla o un todo-terreno.
Existen un montón de técnicas y de principios de cara a la organización de una fábrica. De hecho, existe toda una rama de la carrera de Ingeniería Industrial dedicada a este tema y que además, tiene relativo éxito en el desarrollo de una muy variada gama de productos: coches, bolis, acero, botellines de plástico, yogures, bandejas de poliespán, muebles, relojes, etc. ¿Por qué no software?.

Si por casualidad alguien conociese un lugar donde se apliquen estos principios al desarrollo de software, le estaría muy agradecido si me deja un comentario, un enlace, algo...

Spring si o no? El tema de Spring y frameworks similares siempre parece que trae polémica. Me apetecía poner un reply a la noticia: http://www.javahispano.org/news.item.action?id=1036958573, pero como al final se me hacía un poco largo y, como llevo tanto tiempo sin contribuir a este blog, pues ahí van mis "dos centimos" al respecto del tema:

Una aplicacion "profesional" no es algo simple ni sencillo. ¿Por que nos echa para atrás una tecnologia "complicada"?, Coger cualquier cosa que tengais a mano (un boligrafo por ejemplo) y abridlo, vereis la de piezas que tiene y coño: es un puñetero boli!! ¿Alguien sabe la película que se montan los ingenieros de coches para poner en el salpicadero un medidor de la gasolina? con lo facil que es poner un agujerito en el deposito y meter una varilla como con el aceite!!

La informatica es compleja, los programas son "maquinas" muy potentes y por lo tanto muy complejas y es necesario tener un monton de sistemas, capas, componentes que tienen que interoperar. Los programadores tenemos que especializarnos (o ser muy listos). No vale deshechar las soluciones "complicadas" porque nos cuesta tiempo aprenderlas.
Cierto que Spring mete mas complejidad a una aplicación, pues a lo mejor sí, pero es una complejidad controlada. Yo se Spring, y se que si cojo una aplicacion que utilice Spring, saco el Spring IDE y con los grafos de beans enseguida me puedo figurar como es mas o menos la aplicación (su estructura, arquitectura, etc).  Ahora bien, si es una "sencilla" aplicación hecha artesanalmente, ¿por donde empiezo a mirar? vete tu a saber.

Todo el día llorando porque queremos que la informática sea considerada como una ingeniería como las demás y luego decimos que es "demasiado compleja". Pues claro joder, por eso es una ingeniería, por eso la carpintería no es ingeniería, porque un tablón es un tablón y es mas simple que un idem. ¿Sabeis la pila de tesis doctorales que hay sobre tornillos? Tornillos!! un trozo de metal con una espiral! Y hay empresas que viven solo de diseñarlos!! Y algien dice: "Yo paso de la norma DIM de tornillos porque total, para pegar un par de piezas de metal leerme ese tocho..." o "Los tornillos de roscachapa del 12 son una putamierda porque los fabrica una multinacional corrupta, yo es que soy  de los de estrella de toda la vida porque son mas humanitarios y progresistas, así que en esta obra yo quiero poner tornillos de estrella del 5", pues NO.
En otras ingenierías, el que trabaja el hormigón se dedica al hormigón y el que trabaja el acero se dedica al acero y el que se dedica al hormigon no dice que el acero es una porquería porque el calculo de resistencias es demasiado complejo, cuando con un buen muro de hormigón se arregla todo y el encofrado es mas sencillo.
En fin, esta es mi opinión, aunque no se si mi explicación ha resultado un pelin compleja...

Eventum ¿Conoceis Eventum? Yo he empezado a utilizarlo hace relativamente poco, reconozco que lo desconocía, pero no está mal.
Eventum es una herramienta de "bugtrack" desarrollada por MySQL. La idea inicial es parecida a Bugzilla, pero proporciona alguna funcionalidad más:
- Integración con CVS a través de los comentarios "de commit". Poniendo la etiqueta (issue: <numero de bug>), automaticamente se captura el mensaje y se añade al historial del bug al que hace referencia.
- Control de tiempos y planificaciones. No es que sea una herramienta de gestión de proyectos, es mas bien algo sencillo, nada ambicioso en este aspecto.
- Integración con canales de soporte telefónico. Que permite separar la parte dedicada a desarrolladores y la parte para el público.
- Gráficas. La verdad, que muy sencillas también.
- Capacidad para adjuntar "notas internas" a los bugs (o issues, como se llaman en Eventum).
- etc.

Eventum es muy sencillo de instalar y manejar. Es únicamente una base de datos MySQL + unos scripts PHP relativamente sencillos, lo que permite ampliar la funcionalidad que viene por defecto. Por ejemplo, yo he añadido un pequeño script que coge todos los comentarios de cierre y genera Release Notes para cada versión (o para todas) de un producto.

Cambio de aires Hace bastante tiempo que no echo unas líneas a este blog y, la verdad es que tengo excusa: "he cambiado de trabajo". Definitivamente, he dejado el Framework del Principado de Asturias para pasarme a un campo completamente diferente: la "Inteligencia Analítica" (o extracción del conocimiento para la ayuda en la toma de decisiones).
Este mes de abril, he dejado a mis amigos y compañeros del equipo del FW-PA (gracias a todos por los buenos momentos) para incormprarme con "armas y bagajes" al Centro de I+D+I de la empresa NeoMetrics Analytics SL, en Asturias.

Pues bueno, por el momento, eso es todo. Deseadme suerte.

Cambio zapato por vivienda Hace tiempo que no posteo y me apetecía escribir algo. Como es domigo, no me veo con fuerzas para escribir sobre nada "de trabajo", así que voy a aprovechar para hacer un poco de promoción de la nueva página de mi amigo Raúl: www.cambiozapatoporvivienda. es. La idea es cachondísima, utilizando el antiguo mecanismo del trueque, y partiendo de un zapato (como homenaje a las famosas "Kellyfinder" del Ministerio de Vivienda), quiere conseguir una vivienda digna en Gijón.
Parece una chorrada, pero ya tiene más de 40 (cuarenta) ofertas de todo tipo (desde un pollo de goma hasta un Vespa).

XML no muerde Leyendo los comentarios al post de mi colega David sobre Spring 2.0, me he dado cuenta de que existe gente, programadores, con cierta "manía" a los ficheros XML.
Esta gente suele hablar de "programar en XML" y es que, sencillamente, no es cierto. No se trata de programar en XML, sino de configurar determinadas librerías (o componentes), utilizando XML.
¿No es mas cómodo decicar, en la medida de lo posible, el código Java a implementar la lógica de la aplicación sin meter por medio código de configuración (o de inicialización o lo que sea) de las librerías que se utilizan?
Si cada librería tiene sus propios ficheros XML, con sus DTDs, donde se puede configurar todo, ¿qué necesidad hay de mezclar nuestro código con llamadas a APIs de terceras partes, sujetas a cambios de versiones, actualizaciones, etc?.
En mi opinión, es mucho más cómoda la aproximación de Struts, con su fichero struts-config.xml, donde están mapeadas todas las URLs de la aplicación, su navegación y los objetos (Actions) que van a ejecutar la lógica, que la aproximación de Servlets, donde cada Servlet se encarga de todo: navegación, lógica, etc. y donde no puedes disponer, en un punto concreto de toda la configuración de navegación de la aplicación.
La ventaja de herramientas como Spring es que te permiten aislar casi por completo tu código de implementaciones concretas de las librerías que estás utilizando. Sinceramente, el precio de tener que escribir XML en lugar de Java no me parece excesivo, solamente es una mera cuestión de sintaxis.

un saludo

Continua la controversia con Spring Hace no mucho tiempo, un tal Bob Lee, publicó un post en el que exponía los motivos por los que no le gusta el contenedor Spring. Como no, el que busca polémica la encuentra y ya empiezan a aparecer las primeras respuestas (aparte de la de un servidor es este mismo blog). Ahora es Keith Donald (del equipo de Spring Web Flow) quien, en su blog, contesta a las preguntas que se plantea Bob.

Dimensionamiento de aplicaciones Tal y como se me sugería en un comentario del anterior post sobre puntos negros, sí que es cierto que  el dimensionamiento de aplicaciones es un tema que puede ser un punto negro importante, mas que nada porque se suele dejar de lado por parte de los desarrolladores.
Otro tema aparte es el rendimiento que, desde mi punto de vista, preferiría tratarlo por separado.
a) Rendimiento. Yo, por mi parte, lo tengo claro: es importante tener en cuenta el rendimiento a la hora de diseñar e implementar aplicaciones empresariales (web, J2EE). Pero, claro, plantearse un mal diseño para conseguir una mejora en rendimiento (en un proceso que no sea crítico ni tenga requerimientos específicos de rendimiento), no tiene mucho sentido. Más que nada, porque lo que se ahorra en máquina se gasta después en mano de obra (a la hora de hacer el mantenimiento).
b) Dimensionamiento. Independientemente del rendimiento, no hay escusa para no evaluar los parámetros (tiempo de respuesta, productividad, etc.) en los que se mueve la aplicación. Por ejemplo, en el FW-PA (el Framework J2EE del Principado de Asturias), se incentiva (vamos, que se exige) la realización de un detallado informe de rendimiento para todas las aplicaciones que se desarrollen.

Por cierto, respecto a este último asunto: en el FW-PA, como herramienta para la implementación de pruebas de rendimiento se recomienda OpenSta. ¿Conoceís alguna otra herramienta (libre) alternativa?