Dos textos en los que se habla de la madurez de las empresas: CMMI y El Principio de Peter. El primero la vende como admirable, y sin embargo el segundo la anatematiza.

Para CMMI, menos mal que las jóvenes empresas alocadas, a través del aprendizaje de su medelo, adoptan procesos-adolescentes, que con el tiempo, tras sucesivos ciclos IDEAL(1), desarrollan la capacidad que dará a la empresa la deseable madurez:  Llegará a ser sabia, y tendrá respuestas predecibles y de calidad. 

• Los modelos de calidad basados en el principio TQM (la calidad del software desarrollado se rige por la del proceso usado) son adecuados para las "factorías de software".
• Los principios ágiles funcionan en los "talleres de software".
• En las primeras, el valor de los resultados depende sobre todo de los procesos y la tecnología; en los segundos, de las personas.
• Algunos  productos o servicios de software necesitan eficiencia, resultados homogéneos y repetibles.
  Otros, valor innovador continuo.

Me pasa Luis la referencia de una interesante tesis doctoral: "Enhancing Intangible Resources in Professional Service Firms" que ha descubierto las sopas de ajo:
Resulta que a muchas empresas que venden conocimiento: consultoría, asesoría, publicidad, comunicación, management ejecutivo, procesos...
El conocimiento les importa un pito; que lo importante para ellas es facturar el mayor número de horas y al mayor precio posible.
¡Sorprendente!

La autora reconoce haber descubierto conclusiones pasmosas:

Al aumentar el tamaño del equipo del proyecto, disminuye la productividad personal. ¿Es porque en los equipos grandes los programadores son peores? ¿Porque la gestión los entorpece?.

Algunos productos tienen factores de escala escasos: aumentar el número de unidades realizadas, supone incrementos de proporciones similares en el coste de fabricación.

El software tiene un factor de escala prácticamente infinito: cuesta lo mismo producir uno que mil.
Si mi tratador de textos, o mi solución de correo, o… es lo mejor del mercado, venderé, cien, mil o diez mil veces más programas, con la misma inversión de desarrollo; algo que sin duda no le ocurre, por ejemplo, a una empresa de construcción, o a una joyería.

Cómo afecta esta característica a la ratio coste de prototipado / valor del producto.

Si el producto necesita el máximo valor posible, un modelo de plan y requisitos cerrados, para hacerlo bien a la primera, y evitar costes de modificaciones; puede ser un ahorro miope. El feedback continuo, los requisitos siembre abiertos, la apertura al cambio, y la inyección de valor continuo durante todo el desarrollo es una gran inversión.

Estos días leo por varios sitios críticas a Google sobre protección de datos...

Inquietante.

"...hasta el presente, las fronteras de la privacidad estaban defendidas por el tiempo y el espacio. El primero procuraba, con su transcurso, que se desvanecieran los recuerdos de las actividades ajenas, impidiendo, así, la configuración de una historia lineal e ininterrumpida de la persona; el segundo, con la distancia que imponía, hasta hace poco difícilmente superable, impedía que tuviésemos conocimiento de los hechos que, protagonizados por los demás, hubieran tenido lugar lejos de donde nos hallábamos. El tiempo y el espacio operaban, así, como salvaguarda de la privacidad de la persona..."
 

Hay empresas con buena estrella que casi no tienen que gastar tiempo ni recursos para incorporar a nuevos programadores. Les basta con poner un anuncio y en un "plis-plas" ya han incorporado a la plantilla el nº de personas que necesitaban.

A otras, con peor suerte, les cuesta sudor dar con los técnicos que necesitan.

Se me ocurre proponer a consideración un indicador indirecto de la calidad técnica de una empresa de software: el coste de incorporación de personal.

¿Pero entonces por qué están matriculados en ingeniería informática?.
Es la pregunta que el último final de curso nos hacíamos en una junta de evaluación. ¿Si no tienen interés por aprender, una motivación profesional intrínseca, porqué se han matriculado?.
La respuesta: El mercado laboral. No están interesados en adquirir conocimiento sino un "título", un salvoconducto para puestos bien remunerados.
Por eso los modelos que basan la calidad del resultado en la solvencia de los procesos y no en la de las personas lo tienen más fácil.

Esta semana encontraba por varios blogs el anuncio de la innovadora (?)  idea de los chicos de Microsoft Live: "Windows Live Barcode", y lo cierto es que aunque no es una idea original de ellos, y los códigos semacode y PDF417 llevan ya algún tiempo en marcha; el concepto tiene su gracia y muchas posibilidades.

Al leerla me he acordado de "signum", un componente de una consultoría de nuevo producto en la que trabajé hace más de un año, y en cuya investigación descubrí los semacode. Ha pasado ya un tiempo prudencial desde entonces, y como además no tengo obligación de confidencialidad porque el cliente canceló a mitad el trabajo lo comparto con los que no lo conociérais, porque para la construcción de "mecanos" innovadores ayuda mucho disponer de un buen fondo de "piezas".

Hace algunos meses, vía Fernando, leí el artículo The Day Programmer vs. The Night Programmer en el que Mitch Denny clasificaba a los programadores en: programadores de día y programadores de noche. Y definía a los programadores de día como personas:

Para las que la programación sólo es un trabajo
Que no suelen participar activamente en las comunidades profesionales
Tampoco hacen pruebas o instalan las herramientas de trabajo en su casa
Tienen dificultades para manejar ideas complejas
No pueden visualizar o concebir una solución

En esta página se describe cómo "hackear" un Pilot de 3$ para transformarlo en un Montblanc de 200$. Resulta curioso. Las posibilidades son tres y todas tienen sus adeptos:

• Usar un Montblanc original: Yo sé que es un Montblanc, y los demás ven el nivel del bolígrafo que uso.
• Usar una imitación: Yo sé que no es un Montblanc, pero los demás piensan que sí.
• Usar cargas de Montblanc: Escribo con un Montblanc y los demás no lo ven.