Mostrando entradas con la etiqueta software. Mostrar todas las entradas
Mostrando entradas con la etiqueta software. Mostrar todas las entradas

viernes, febrero 18, 2011

Llegando lejos en el negocio del software

viernes, febrero 18, 2011 por Martín


Making it big in software es un libro de Sam Lightstone publicado en Prentice Hall. El libro lo terminé de leer la semana pasada. Se trata de un libro sobre las empresas de software y tecnología, muy orientado a como sobrevivir en grandes empresas tecnológicas que todos conocemos y como llegar lo más alto posible. Como conseguir vivir bien del software. Además de esto, el principal atractivo del libro son entrevistas exclusivas con personalidades bastante relevantes del mundo del software como John Schwarz, James Gosling, Marissa Mayer, Marc Benioff, Linus Torvalds o Richard Stallman, entre muchos otros.

El autor del libro tiene un currículum importante. Curiosamente en el libro destaca como primer punto el ser el creador del sitio web makingitbigcareers.com cuando esta persona es Program Director dentro del grupo de software de IBM, director de proyectos importantes relacionados con DB2 y fundador del IEEE Data Engineering Group.

lunes, enero 10, 2011

Slow Food vs. Software Craftmanship

lunes, enero 10, 2011 por Martín

Este año estuve dos semanas en Croacia recorriendo el país. Durante ese recorrido pude apreciar que los Croatas son unos grandes seguidores de un movimiento que hasta ese momento no había conocido: Slow Food.

Slow Food es un movimiento internacional fundado en Italia por Carlo Petrini en 1986. Nace como una alternativa al Fast Food y se esfuerza en preservar la cocina regional y tradicional, fomentando la agricultura ecológica y los ecosistemas locales. Según la entrada de la Wikipedia el movimiento se ha expanddido y cuenta con 100.000 miembros (que auto-financian la organización) en 132 países, incluido por supuesto España. Los objetivos de la organización son el desarrollo de un sistema alimentario sostenible y la promoción de los pequeños negocios locales en paralelo a una agenda crítica hacia la globalización de los productos agrícolas.

martes, noviembre 17, 2009

Estaré en la III Jornada de Tecnologías Java en la Universidad de Alicante

martes, noviembre 17, 2009 por Martín


Dentro de dos semanitas, el 1 de Diciembre tendré el placer de participar en la III Jornada de Tecnologías Java en la Universidad de Alicante a las que muy amáblemente me invitó a participar Domingo Gallardo.

El título de la charla es "Desarrollo y pruebas de proyectos Java en un entorno ágil" y bueno hablaré un poco sobre lo que voy contando aquí en este blog. Meteré bastantes batallitas irlándesas que es donde más me he empapado de todo lo que implica el agilismo, pero sobre todo intentaré explicar lo que significa para mi el ser un profesional del software, que es lo que siempre he querido ser, y como conseguirlo aplicando técnicas ágiles.

La charla lleva la coletilla Java pero será simplemente para poner algunos ejemplos. El 95% por cien de la presentación se puede aplicar a cualquier lenguaje. Pues nada, que os animo a pasaros por allí.

jueves, junio 25, 2009

Software Libre distinto de Software sin Compromiso

jueves, junio 25, 2009 por Martín


¿Quién no conoce a estas alturas la frase "Software Libre distinto de Software Gratis"? No creo que sea necesario explicarla. Pero a cuento de un hilo en una lista de un proyecto Open Source (que tampoco quiero mencionar, porque no importa demasiado y porque es algo que se ve en muchas partes), pues llevo varios días pensando en lo frecuente que es el ver como en las comunidades de Software Libre se utiliza el hecho de tratarse de software abierto para excusar otros problemas.

Es especialmente frecuente el ver aparecer este tipo de excusa cuando las críticas arrencian, cuando los usuarios reclaman funcionalidades que sería difícil implementar, cuando carecemos de los recursos necesarios para hacer dichas funcionalidades, o cuando simplemente no nos apetece gastar nuestro tiempo en eso. ¿Por qué afirmo esto? Pues porque lo he visto en infinidad de ocasiones, y voy más allá, porque tengo que confesar que he utilizado dichas excusas en muchas ocasiones.

Cuando estaba en pleno desarrollo de jLibrary, era común el que llegase gente pidiendo cosas que podrían hacerse. Y la verdad es que siendo un equipo pequeño, no te queda más remedio que filtrar. A veces te llegaban sugerencias fenomenales, pero es que no te quedaba más remedio que cerrar la conversación con un "es un proyecto de Software Libre, puedes contribuir". Que conste que más de una vez funcionó, pero la mayor parte de las veces, la petición queda ahí, en una simple petición, y nunca recibías ningún parche.

Y no creáis que no me daba rabia el tener que sacar la excusilla de marras. Al contrario, me daba muchísima. Cuantas veces tengo pensado, ojalá tuviese aquí diez commiters totalmente motivados o un buen presupuesto para implementaros todo lo que pedís. Pero por desgracia, ni los tenía, ni parece que tuve la capacidad de convicción para atraerlos. Pero entonces, ¿por qué esa rabia? Pues porque para mi el Software Libre, por mucho que tengas esa excusa tan a mano y tan socorrida, no está exento de responsabilidad.

Cuando creas un proyecto abierto en Internet, eso tiene una responsabilidad enorme. O quizás soy yo que simplemente me lo tomo muy a pecho. Pero para mi, al abrir un proyecto le estás pidiendo a la gente que lo pruebe. Estás creando una comunidad. Una comunidad de personas que ponen su confianza en ti y en tu producto, aunque sea sólo para invertir treinta minutos en descargárselo, instalarlo, y probarlo. Si pasan de esa fase, incluso puede que lo comiencen a usar, y esos minutos pasan a ser horas, días, semanas, meses o años de confianza en tu software.

Y tú, como creador del software, necesitas de esa comunidad y su confianza. Porque al final lo que quieres es que tu producto lo usen más y más personas. Y después, con suerte, te harás famoso, podrás vivir de ello o vendrán y te comprarán por varios millones de euros, como ya ha pasado con muchas empresas. Pero sin confianza ni compromiso, nada de nada.

Pero hay gente que piensa que como es Software Libre, pues ya está, lo usas si quieres y punto, y si quieres mejorarlo pues no te quejes tanto y ponte a ayudar. Este argumento, tiene alguna base cuando utilizas un proyecto que lo mantienen cuatro gatos, sin ningún tipo de apoyo, pues como era el nuestro, y que a fin de cuentas es gente dedicando su tiempo libre a hacer algo que a otros les reporta un beneficio económico. Y digo alguna base, porque a fin de cuentas el creador siempre tiene sus motivos para crear el software e iniciar ese compromiso con sus usuarios.

Pero sin embargo, ¿qué argumentos se puede tener cuando tienes capital de sobra?, ¿o cuando te han comprado?, ¿o cuando eres una gran compañía? Por ejemplo, digamos que te compra una compañía que acaba de recibir varios millones de euros en inversión, tus usuarios te piden que redirijas un poco el proyecto para solucionar determinados problemas, y ¿tu respuesta es pedirle a los usuarios que en vez de protestar ayuden? Mal vamos. Más bien habría que pedirle a quien te ha comprado que ponga recursos para que el proyecto salga para adelante.

Os soy franco, para mi el argumento de "es software libre, puedes ayudar" no es válido cuando el proyecto pasa una determinada raya, la raya de la inversión, la raya del mega-éxito, o cuando simplemente están sustentados por compañías enormes. Proyectos como Alfresco, Spring, JBoss, Glassfish, MySQL, ... Señores, en muchas de estas compañías, ni te aceptarán los parches en caso de que los tengas, pues porque quizás no tengan tiempo, o porque sean parches que hagan conflicto con otros clientes, etc. (en una empresa en la que trabajé nos pasó algo de esto con Hibernate). Ellos han elegido el camino del Software Libre, y el Software Libre, ni es gratis, ni está exento de la responsabilidad hacia sus usuarios.

Un porcentaje de estos usuarios, seguramente alto, serán gorrones que no aportan nada, ni hacen contratos de mantenimiento, ni van a cursos oficiales, ni tienen sus certificaciones, pero.... son tus usuarios. Tú has escogido el modelo de negocio. Para bien o para mal. Y si los usuarios protestan normalmente es que el río agua lleva.

Perdón por el rant, pero es que el topicazo de "es libre, menos protestar y más ayuda" lo llevo fatal. Hasta cuando soy yo el que lo tiene que decir.

Imagen via schoschie@flickr

martes, junio 23, 2009

UBS y Citi deshaciéndose de parte sus departamentos de IT

martes, junio 23, 2009 por Martín

Hoy me he encontrado con un par de noticias muy interesantes, dan para mucho que hablar. Reportaban en Finextra que Citi está intentando vender su plataforma IT a alguna multinacional India. Mencionan Tata Consultancy Services y Wipro como posibles compradores. También referenciaban a UBS como otro gran banco que se está intentando deshacer de sus plataformas de IT, más concretamente de sus centros de Polonia y la India.

Si consiguen vender sus departamentos, serán unos genios. Porque a ver quien se cree que sus plataformas las pueden vender a otras firmas. Bueno, tampoco hay que ser talibanes del software, todos sabemos lo buenos que los vendedores pueden llegar a ser, y si nos dicen que la plataforma de trading del Citi va a funcionar sin problemas en el Banco Etxeverria, pues seguro que habrá algún directivo que hasta se lo crea.

En fin, a mi estas noticias me hacen reflexionar. Pensar lo abajo que estamos en la escalera de decisión y lo poquita cosa que puede ser un programador para un super-banco como este. Y es que el ahorro de costes en IT parece que no tiene fin. Empiezas con tu cubículo en Suiza, el banco ahorra costes y te subcontratan a una empresa Suiza, el banco ahorra costes y te subcontratan a un centro de producción en Polonia, el banco ahorra más costes y te venden a una empresa de subcontratas India.

De hecho es una pasada todo lo que han crecido estas empresas de subcontratación como Wipro. Resulta sorprendente que sean estas compañías las que estén pujando por el software de estos gigantes bancarios...

Nada, unas reflexiones a golpe de Martes.

domingo, junio 21, 2009

Los superprofesionales del software

domingo, junio 21, 2009 por Martín

Domingo después de una dura semana de trabajo. Repasando mis feeds pendientes por leer me encuentro con este post de Javier Garzás sobre los superprofesionales del software.

Responsabilidad, conciencia, honestidad, resistencia, imparcialidad, perspectiva y pragmatismo. Excepcional lista. No puedo estar más de acuerdo.

Es difícil escoger sobre uno de estos puntos. Creo que todos son realmente importantes, y la falta de alguno de ellos puede desencadenar muchos problemas. Lo que sí que estoy seguro es que el de resistencia bajo presión es el más difícil de dominar.

viernes, diciembre 05, 2008

Mapa de Startups: España vs. Irlanda

viernes, diciembre 05, 2008 por Martín

Los de Crunchbase han creado una aplicación de Google Maps muy chula, CrunchVision, que muestra un mapa de Google donde se ven las startups que están registradas en su base de datos.



En el mapa del mundo se puede apreciar claramente cuales son los hervideros de startups. La zona de California con 2109 compañías registradas mientras que la costa Este se va a las 1815. En Europa, la zona central acumula 965 startups de las cuales 485 se concentran en el área Londres/Paris. España se posiciona bastante en la cola con un total de 58 startups registradas. Esto no quiere decir que sólo existan 58 startups, ni mucho menos, significa únicamente que tan sólo esa cifra se ha registrado.

Echando un vistaza al mapa de España se puede ver lo que todos nos esperamos, y es que la mayoria se concentra en torno a Madrid y Barcelona. 27 compañías en la ciudad Condal.



Por curiosidad y para los más vagos, un par de capturas de la localización de algunas de las startups en Barcelona y Madrid.







Si nos vamos a Irlanda, un país con alrededor de la novena (contando irlanda del norte) parte de habitantes, pues resulta que está muy, pero muy cerca en número de startups registradas. Un total de 49 compañías, que son tan sólo 9 menos. O sea que tenemos una compañía menos por cada 9 millones de habitantes. Vaya estadísticas que me saco :-)



Haciendo un poco de zoom, pues lo esperado, la mayoría se concentra en el centro Dublín donde hay unas 28 compañías registradas.



Esto no es ningún tipo de estudio ni nada por el estilo ni se deben sacar conclusiones precipitadas, pero ¿por qué no tenemos más compañías registradas? Mi opinión personal es que es un tema de falta de nivel de inglés y concentración exclusiva en el mercado local. Dos factores que limitan enormemente las exportaciones de software. Pero esta es simplemente mi opinión. ¿Cuál es la vuestra?

lunes, septiembre 22, 2008

Spring cambia el modelo de mantenimiento, ¿y qué?

lunes, septiembre 22, 2008 por Martín


Desde luego, mira que egoistas somos. Tenemos un proyecto que probablemente hoy por hoy el 90% de los desarrolladores Java se está aprovechando de él, directa o indirectamente, y justo cuando el proyecto anuncia una nueva forma de ganar dinero nos lanzamos a criticarlo ferozmente por vendidos.

Claro, al fin de cuentas uno se acostumbra a tener unos cuantos esclavos de primera clase haciendo el trabajo que a nosotros nos llevaría años y sin cobrar ni un céntimo; y ojo con retrasarse en las releases que a nosotros nos gusta estar a la última; y apurando con esa actualización de la versión 1.1.0.2 de hace dos años que tengo un cliente un poco pesadito y necesito que me arregléis un bug que tenéis pendiente. Así que venga, que tenéis capital de riesgo y hay que ganarse el pan.

Estos dos párrafos derrochando ironia vienen a cuento de las reacciones en ese nido de trolls en el que se ha convertido lo que en su día fue una gran comunidad como TheServerSide y en el que no han tardado en despellejar a Spring por el anuncio de su nueva política de mantenimiento. Claro que tampoco es de extrañar ya que el portal ya se dedica sólo a noticias de lanzamientos de productos y rumores.

En InfoQ hacen un resumen mucho más pausado y tranquilo de el nuevo modelo de mantenimiento que básicamente viene a ser:

  • Los usuarios normales (que no pagan) de Spring tendrán acceso a todas las builds de versiones mayores del producto.

  • Los usuarios normales (que no pagan) tendrán acceso a las actualizaciones (bug fixes) de estas versiones durante los tres meses desde su lanzamiento.

  • Los usuarios "enterprise" (de pago) tendrán acceso a todas las builds de todas las versiones incluso tras tres meses después de su lanzamiento.

  • Todo sigue accesible en el repositorio de fuentes del proyecto, así que cualquier usuario puede descargarse un proyecto con los últimos parches y construirlo el mismo.


Teniendo en cuenta el último punto, en mi opinión no hay ninguna razón para protestar. A mi me parece una muy buena idea para monetizar el proyecto y estoy seguro de que muchos clientes decidirán subscribirse al mantenimiento para evitar el engorro de tener que descargarse los fuentes de una determinada versión y poder descargarse directamente una versión que puedan desplegar directamente.

Por lo demás, se supone que esto podría perjudicar a algún proyecto Open Source que necesita indirectamente los últimos parches, pero bueno realmente no creo que a los administradores de proyectos Open Sources les moleste demasiado descargarse Spring para tener los últimos parches; lo último es aplicable a cualquier persona que le guste estar a la última en cuestión de este framework.

Eso sí, ojo porque los chicos de SpringSource ya nos han sorprendido con un servidor de aplicaciones y con un nuevo modelo de mantenimiento más comercial. ¿Qué será lo siguiente?

martes, septiembre 09, 2008

Un pequeño problema informático de esos que valen millones

martes, septiembre 09, 2008 por Martín


Hoy me voya desviar un poco de la temática habitual, aunque me mantendré de cierto modo dentro del mundo del software. Una de mis aficiones es la economía. Me encanta seguir los mercados, las noticias, las inversiones y todas estas cosas.

El Lunes fue uno de esos días emocionantes en las bolsas. Las empresas financieras americanas Freddie Mac y Fannie Mae se habían desplomado en la bolsa en la pasada sesión y el gobierno de los Estados Unidos había acudido a su salvación. El Lunes se esperaba una carrera de compras como no se había vivido en meses (o años). Aún así, no fue un día muy feliz en el London Stock Exchange ya que fueron incapaces de operar durante prácticamente toda la sesión.

En la prensa se comenta que la caida duró unas siete horas, y que muchos traders se vieron forzados a moverse a sistemas de la competencia para intentar operar. Wow, siete horas de inactividad en la bolsa valen miles de millones. Parece ser que todo se debió a un fallo informático dentro de un aplicativo llamado Infolect que es el sistema de envio de datos que utilizan.

En ZDNet tienen un artículo interesante que comenta más detalles sobre este sistema. Y en CIO comentan que es un sistema lanzado hace un par de años (no sé en donde leí que lo habían actualizado este verano) basado en .NET, SQL Server y desplegado en más de 100 servidores Proliant Intel 32 bits.

Parece que hace poco que LSE ha encontrado verdadera competencia en dos exchanges alternativos, Chi-X y Turquoise que se animaron a comentar el fallo y no dudaron en recomendar a todo el mundo migrar a sus redes más modernas y más baratas.

La verdad es que independientemente de si el fallo estaba en el software, en los servidores, en la red, en lo que sea, lo cierto es que este tipo de noticias son esas que leeremos en años en los libros ya que te demuestra como pequeños fallos, o sistemas no preparados para picos de carga enormes pueden generar perdidas millonarias al tiempo que impactan enormemente en la imagen de las compañías y proporcionan jugoas oportunidades a la competencia para captar a tus clientes.

A ver si algun publicación online nos desvela un poco más sobre este fallo.

lunes, septiembre 08, 2008

El Arquitecto de Software en versión española.

lunes, septiembre 08, 2008 por Martín

En muchos países europeos, US, Japón y otros, la figura de Arquitecto de Software está realmente valorada. Ser arquitecto de software es el paso natural para muchos desarrolladores senior, y requiere sobre todo experiencia y buenas capacidades de análisis, raciocionio y abstracción. Coding de Architecture es uno de los mejores blogs existentes sobre el trabajo de Arquitecto de Software y tiene varias entradas donde se define el scope de un arquitecto o el perfil que debería tener un arquitecto.

Entre las tareas de un Arquitecto de Software destacarían:

  • Definición de la arquitectura.

  • Selección del software.

  • Selección de la infraestructura.

  • Requisitos no funcionales.

  • Liderazgo.

  • Mentoring.

  • Metodología de los proyectos.

  • Proceso de desarrollo.

  • Prácticas y estándares.

  • Análisis de las tendencias en desarrollo de software.

  • Aporte de experiencia.

  • Participar en el desarrollo.



Esta lista está recogida en este fichero PDF y es probablemente el último de los puntos que he puesto el que causa más polémica, aunque bueno más o menos está aceptado que es un bueno que un arquitecto participe de alguna forma en el desarrollo, aunque el dedicar más del 30% de su tiempo a dichas tareas indicaría que hay algo que está iendo mal.

Viendo como trabajan las empresas en el extranjero y sobre todo el reconocimiento que se le tiene a arquitectos y desarrolladores senior, a uno no le deja de sorprender el encontrarse ofertas en España buscando Arquitectos de Software con experiencia de al menos un año programando en J2EE. O mismamente la siguiente lista de requisitos para un Arquitecto J2EE en Valencia:

Descripción de la oferta
Buscamos un arquitecto en las tecnologías Java/J2EE, para proyectos de primer orden y pioneros en el ámbito de desarrollo de software. El candidato seleccionado se responsabilizará de:
-Captura y análisis de requisitos técnicos y de negocio
- Análisis y diseño funcional y técnico de proyectos de desarrollo de software
- Definición y ejecución de planes de pruebas
- Desarrollo Java/J2EE
- Realización de la documentación técnica asociada al proyecto
- Impartición de formación a usuarios y técnicos implicados en el ámbito del proyecto


Es decir en este caso Arquitecto = consultor, business analyst, tester, programador, documentador y formador. En fin, que cualquier parecido con la realidad del mundo exterior a nuestro peculiar país es mera coincidencia. Aunque está claro que en muchas empresas sí se reconocen los puestos de desarrollador senior y arquitectos, lo cierto es que todavía son la mayoría las que desconocen completamente lo que es el mundo del desarrollo de software, sus perfiles, el trabajo que se debe realizar, los roles y responsabilidades, etc. El arquitecto de software no deja ser "el que controla" o "el que nos saca las castañas del fuego".

Así nos va.

miércoles, septiembre 03, 2008

97 cosas que todo Arquitecto de Software debería conocer

miércoles, septiembre 03, 2008 por Martín


Vuelta de vacaciones y tengo que reconocer que me ha costado volver a postear, y es que como leía hace poco un blogger constante necesita tener un ego suficientemente inflado para alimentar esa situación engañosa de creer que la gente necesita realmente leer lo que escribes y no podrá vivir sin ello, y al tiempo entrar en esa inercia de posteo que te permite postear frecuentemente pero que si la abandonas por un rato te será difícil recomenzar a postear.

En fin, que dicho esto voy a continuar inflando un poco más mi ego con una entrada más, que seguro que de todos modos alguno la encontrará interesante y que pasados unos meses siempre me sirven para repasar mis ideas sobre determinados temas.

El caso es que me he encontrado con una iniciativa verdaderamente interesante de O'Reilly, y que no sé si alguno la conocería ya pero que a mi me ha sorprendido gratamente. Se trata de la creación de un libro mediante un wiki comunitario en el que puede escribir cualquier persona siempre y cuando el moderador apruebe la entradas. El libro trata sobre un tema tan interesante como la arquitectura del software y se llama 39 things that every software architect should know.

El moderador que se encarga de seleccionar las entradas más valiosas es Richard Monson-Haefel. ¿Alguien se acuerda de él? Seguro que más de uno sí. Este hombre fue durante muchos años la cara de J2EE (cuando todavía se llamaba así) y escribió lo que claramente se pueden llamar biblias sobre los EJB. Que tiempos aquellos! Si hasta le había hecho una entrevista yo mismo en el 2004 (creo que el contenido no está accesible) y recuerdo bien que aunque fue amable en contestarme sólo me respondió la mitad de las preguntas dejándome bien claro que no tenía más tiempo que perder :-) Yo creo que esa entrevista le hizo replantearse las cosas y pocos meses después abandonó el mundo de Java para shock de la "comunidad".

Volviendo al tema, la idea de O'Reilly me parece realmente buena porque de esa manera muchos autores anónimos y no tan anónimos pueden compartir sus experiencias creando un libro que seguramente se convertirá en referencia de una u otra manera. En el foro que han preparado se puede ver como se pueden sugerir nuevos axiomas y también leer los comentarios sobre los existentes.

Las entradas que hay ahora mismo son realmente interesantes, y por comentar una, la más votada de todas (No pongas tu curriculum por encima de los requisitos) me ha recordado a un Arquitecto de Software con el que coincidí y que no dudaba recomendar el utilizar WebSphere MQ y Coherence para una determinada tarea porque le apetecía aprender esas tecnologías. No cabe lugar a duda de la validez de las tecnologías, pero en este caso estas tecnologías no se escogieron, para suerte para el bolsillo del cliente y para las personas que tendrían que lidiar con éstas y disgusto de esta persona en particular.

¿Algún axioma que echéis en falta en la lista?

viernes, junio 27, 2008

IONA

viernes, junio 27, 2008 por Martín


IONA (Technologies) es una de esas compañías que ha marcado una era. Surgida del Trinity College en Dublin como startup allá por el 1991, es una de esas compañías que a los de mi época comenzaba a sonarnos un poquillo cuando andábamos por la Universidad, y que al salir y descubrir un poco el mundo exterior y empezar a leer las revistillas, y las páginas web, pues descubrías que era la empresa donde más se innovaba en el momento. La empresa donde cualquier ingeniero de software le gustaría trabajar, la empresa que acaparabalos titulares de los TheServerSide de la época.

En Answers.com tienen una biografía excepcional de la compañía. Su mayor éxito fue Orbix ORB. Top ventas donde los haya y que todavía se vende. La primera implementación comercial de un estándar, que empezaba a sonar en la época, llamado CORBA. Esa innovación, el ser los primeros en adoptar un estándar avalado por HP, IBM, Sun, Apple, y todo el resto de miembros del OMG, les valió el convertirse en la empresa del momento, y una de las de mayor éxito de la década de los 90.

Un Object Request Broker, nada más y nada menos, lo que ahora mirado desde lejos parece lo más sencillo del mundo, pero que en aquella época era algo que daba vértigo sólo de pensarlo. ¡O al menos a mi me lo daba en las prácticas de CORBA! Leyendo la biografía es sorprendente todo lo que crearon durante esa época. OrbixTalk lo que suena a los modernos Event Driven Servers que nos venden hoy en día, Orbix Transaction Monitor, Orbix MX (multimedia, video streaming, ...), Orbix COMet (para crear aplicaciones Windows y ejecutarlas en otros sistemas operativos), partnetship con Visual Cafe (¿quién se acuerda de ese IDE?), Homebase EJB, ... y otro montón de productos que supongo que pasaron con más pena que gloria.

Según comentan los irlandeses, y en general todo el sector, el golpe del 2000 fue demasiado para ellos. Nunca consiguieron levantar cabeza al nivel de antes (5ª compañía en el Nasdaq 1997), y muchos de los miembros aprovecharon para canjear las acciones y comprarse unas buenas casitas como cuenta Joe Drumgoole en su blog. Como también comenta, el gran fallo es que nunca supieron realmente como unirse al carro de Java y EJB, y probablemente hayan lamentado el no comprar WebLogic en su momento si son ciertos los rumores.

En los últimos años la esperanza de IONA ha sido el Open Source, pero siempre dando esa impresión de no tener un rumbo fijo. La compra de C24 y ServiceMix parece haber enfocado su negocio en el mundo de la integración, interoperabilidad entre estándares y el Open Source. Tiene productos interesantes (casualmente esta semana he estado en un seminario sobre uno de ellos), pero siguen dando exactamente esa impresión de no saber realmente donde está su negocio.

Esta semana IONA ha sido comprada por Progress, por un precio de 163 millones de dólares, o lo que es lo mismo sobre 4 dólares por acción, en lo que claramente es una operación para deshacerse de la compañía. Un precio bastante miserable para una compañía que en el 1997 valía 1 billón de dólares. Mucho me temo que en la oficina estarán ya pensando en cuando caerán los despidos. Malos tiempos para Irlanda que pierde a lo que ha sido la compañía de software más importante que ha salido de la isla.

sábado, mayo 03, 2008

Cinco preguntas para tu próxima entrevista de trabajo si te gusta el software

sábado, mayo 03, 2008 por Martín


Durante las últimas semanas le he estado dando la vuelta a un tema relacionado con la búsqueda de empleo. Normalmente cuando a uno le preguntan en una entrevista de trabajo si desea saber algo sobre la compañía, se suele caer en las típicas preguntas sobre horario de trabajo, vacaciones, pensiones, comidas, bonuses, etc.

Pero, a parte de esto, cuando uno se dedica al mundo del software ya sea como programador, arquitecto, jefe de proyecto o manager, lo que le gusta es caer en un sitio donde se pueda aprender cosas nuevas, evolucionar técnicamente, trabajar con las últimas tecnologías, estar expuesto a sistemas interesantes o integrarse dentro de ciclos de desarrollo racionales con metodologías de programación modernas. Atendiendo a esto, probablemente merezca la pena dedicar estos últimos minutos de la entrevista a realizar otro tipo de preguntas que den una pista de si tu futuro entorno laboral va a ser enriquecedor o no, desde punto de vista técnico.

Pero, ay, y ahí está el problema, el entrevistador probablemente intentará maquillar cualquier punto negro de la empresa, ya sea para cazarnos o para no exponer sus vergüenza. Por ejemplo, si vamos a una entrevista y preguntamos "- ¿Utilizáis metodologías ágiles?", no sería raro recibir una contestación como "- Por supuesto, por supuesto, nuestros equipos practican XP", y dos semanas después encontrarse con cien folios de requisitos que tienen que firmar diez personas de diez departamentos diferentes para poder pasar al diseño de la aplicación.

El conjunto de preguntas deberían ser lo suficientemente claras y directas para no dar lugar a error sin llegar a ser ofensivas o sin llegar a poner en peligro nuestra candidudatura. Es decir, preguntarle al entrevistador que nos diga lo que es un assemblyen .NET puede resultar un poco incómodo para ambos :-)

A mi se me ocurren una serie de preguntas que nos pueden dar pistas de como funciona la empresa sin que el entrevistador se sienta realmente entrevistado. Estas preguntas son evidentemente técnicas. Si el entrevistador no sabe responderlas, titubea, se muestra dubitativo o esquivo, yo desconfiaría directamente de la empresa, especialmente si ese va a ser nuestro. Me voy a centrar en Java porque si pongo otro lenguaje de ejemplo al final soltaré alguna tontería. Aún así, las preguntas y sus explicaciones son lo suficientemente generales para ser aplicables directamente a cualquier otro lenguaje/plataforma. Ahí van:

  • ¿Qué framework de desarrollo utilizáis?:

    Atención, porque esta pregunta es la más importante. Si por cualquier razón la respuesta es "tenemos un framework propio", mal pinta la cosa. De hecho, hasta me atrevería a ser radical y decir que es hora de huir de ahí como del demonio. A 2008, el mundo del software no necesita otro framework casero realizado por mentes privilegiadas "porque Spring o JSF no se ajustan a los requisitos de la empresa".

    El tener un framework propio es indicador, en el 99% de los casos, de estar reinventando la rueda. De aceptar esto, tocará trabajar con tecnologías probablemente obsoletas, tocará corregir bugs que no estarían ahí de utilizar algo probado, o tocará "mejorar" el framework con cosas que ya están implementadas en otras librerías. Un framework propio, puede ser resultado de una mala elección, o quizás de una elección forzada debido a que el producto se creó hace muchos años.

    La respuesta ideal dependerá de lo que quiere hacer el desarrollador o del lenguaje, pero a cualquiera que se mantenga un poco al día le será fácil detectar nombres clave. En Java, Spring, Hibernate, JSF, WebWork, Seam, o incluso EJBs serían respuestas válidas. Struts, mmmmm, ok, todavía hay mucho Struts por ahí y siempre será mejor que un framework web propio. En serio, cualquier cosa que no implique corregir los errores del creador de un framework casero, será más que suficiente.
  • ¿Qué metodología de desarrollo utilizáis?:

    La pregunta, así de seca. Sin dar pistas. Así, si el entrevistador nos quiere engañar no podrá predecir nuestros gustos (salvo por nuestro CV). Si la respuesta no es clara, o es "bueno, nosotros tenemos nuestra metodología propia", etc. entonces ojo, peligro de caos, intentemos sacar algo más de información.

    Si la respuesta es cualquier cosa que implique desarrollo en cascada (e.g. métrica o similares), un punto por ser honesto. No tiene porque ser algo tan terrible si el resto de preguntas están a nuestro gusto, o si el ciclo de vida de los proyectos sigue un flujo racional. Es mejor que conteste eso que el que detectemos que nos intenta engañar.

    Si la respuesta es XP, yo estaría con la mosca detrás de la oreja, al fin y al cabo se lee más de esta metodología de lo que se usa en realidad. Si la respuesta es Scrum, o cualquier otra metodología o derivación que implique desarrollo ágil (e.g. RUP bien aplicado), seguramente estemos ante un buen lugar.
  • ¿Qué sistema de build utilizáis?:

    Si la respuesta es ninguno, o qué es eso, pues muy mal empezamos. En Java, si la respuesta es ant, desconfianza total (lo siento por los que todavía utilizen ant, pero los sistemas de build ya han avanzado bastante en los últimos años) ya que podría significar que el trabajo será realizar mantenimientos viejos, o que la empresa no se preocupa en mejorar sus herramientas. Respuestas como maven, ivy, etc. indican que se han preocupado de mejorar estas cosas. Si la respuesta incluye integración continua, de manera espontánea, será un excelente indicador.
  • ¿Qué entorno de desarrollo utilizáis?:

    Esta es la típica pregunta que, siendo bastante inocente, nos puede dar bastante información sobre como es la empresa ha evoolucionado desde el punto de vista del software. En una plataforma como Java, ha habido y hay montones de entornos de desarrollo, cada uno con una historia particular que nos puede dar pistas sobre la gente que lo utiliza.

    Intellij IDEA por ejemplo siempre ha sido un entorno de desarrollo que siempre ha tenido buena fama. Punto positivo si lo usan. Si la empresa utiliza NetBeans y Eclipse, se situará en el baremo de lo habitual, así que no nos indicará nada bueno o malo. Si utiliza alguna especialización de Eclipse (e.g. MyEclipse), puede ser un buen dato ya que Eclipse se deja muchas cosas en el tintero, y eso denotaría que lo saben y que han buscado una solución. Otros entornos que han ido quedando más en desuso si que nos pueden dar una pequeña alarma sobre la compañía.

    ¿Utiliza Visual Age, o Visual Café? Entonces es hora de huir. Estos son entornos desaparecidos hace siglos. ¿BlueJ, JCreator, ...? Hay algo raro. Son entornos que muy poca gente utiliza. ¿JBuilder, JDeveloper? Cuidado. Son entornos que han caido bastante en desuso y que la gente suele utilizar por el valor añadido de sus componentes, es decir, que quizás estén utilizando todo este "valor añadido" que es mejor evitar.

    ¿BEA WorkShop, WebSphere Studio, ...? Cuidado. Esto puede indicar tanto que la empresa aprovecha realmente todas las funcionalidades que ofrecen lo que sería muy bueno, como que la empresa no tiene ni idea de lo que hace y espera que las aplicaciones funcionarán mejor por el mero hecho de utlizar el IDE que viene con el servidor de aplicaciones.
  • ¿Cómo se prueban las aplicaciones?:

    Esta es una pregunta un tanto complicada porque resulta muy amplia así que habrá que estar atento a las respuestas. Si la respuesta incluye un departamento de calidad, con bastantes personas, eso será un buen indicador. Si no lo incluye, no tiene porque ser algo terriblemente malo, aunque dependerá de lo que nos diga a mayores.

    Si el entrevistador nos menciona explicitamente unit tests, tests de integración, tests de stress, será un buen detalle. Si nos menciona soak testing (dejar una aplicación ejecutandose durante semanas), será un muy buen indicador. Si a mayores detectamos la presencia de algún sistema de automatización de tests, ya sea Mercury, Selenium, DBUnit, etc. será un punto realmente muy positivo. Y ya si nos comenta que los tests se ejecutan dentro del sistema de integración continua que nos mencionó antes, entonces... ¿pagan bien? :)

    Si la respuesta no incluye nada de lo anterior, mucho cuidado. Puede ser una buena empresa con simplemente una falta de control de calidad, pero también una empresa caótica donde no queremos trabajar. ¿Ha respondido bien al resto de preguntas? Si la respuesta es "tenemos nuestro propio sistema de testing" (ver el primer punto), entonces habrá que plantearse seriamente el trabajar en esa empresa.


Vaya, he repasado el post y me ha quedado realmente largo. Espero que al menos alguien lo encuentre interesante. A mi, personalmente, me interesan más aún vuestras preguntas, así que lanzo esto al aire a ver si alguien lo recoge: ¿Qué preguntaríais vosotros para evaluar a una empresa en una entrevista de trabajo relacionada con el mundo del software?

Imagen via melissa22@flickr.

martes, febrero 26, 2008

Y más sobre software en España...

martes, febrero 26, 2008 por Martín

Sergio Montoro escribe en La Pastilla Roja:

Ahora pongámonos en la piel del capo di tutti capi en la típica empresa española que vende software. La empresa típicamente se fundó hace 10 ó 20 años, hallá por los 80 ó 90. Empezaron como distribuidores de máquinas registradoras y poco a poco empezaron a escribir también el ERP de la gran superficie a la que se las vendían. Con el paso del tiempo aprendieron a ganar contratos públicos, y, a día de hoy, la empresa cuenta entre 50 y 500 trabajadores distribuidos en varias decenas de "cuentas vaca" que proporcionan el 80% de la facturación. El capo va camino de los 50 años (o más) y lo que tiene en mente a esas alturas de su vida es cuánto dinero le darán el día que venda la empresa, cantidad que depende casi exclusivamente del tamaño del fondo de comercio. Los mandos intermedios son una bandada de barracudas sedientas de poder motivadas principalmente por la cilindrada del coche y los metros cuadrados de despacho que obtendrán el año próximo. En tal empresa ¿cómo va a prosperar ninguna iniciativa de software? Cuando a la jefatura le proponen invertir 500.000€ en fabricar un software es casi como si le propusieran si quiere tirar el dinero a un vertedero nuclear. La empresa vive de los CONTRATOS (con mayúsculas) vive del software que se sabe que se va a cobrar, el comercial va, presenta una oferta económica, se acepta, se ejecuta y el cliente paga, la empresa no vive de ideas pajareras ni se puede permitir despilfarrar en proyectos de dudoso retorno de inversión, y no van muy desencaminados...

En la línea del post en el que buscaba empresas de software. ¿Alguna mención en el debate electoral a crear una industria tecnológica competitiva? O tenemos que esperar otros cuatro años...

jueves, enero 24, 2008

Saas, innovación o seguridad... o quizás ambos

jueves, enero 24, 2008 por Martín

En OnStartups publicaron ayer un post bastante interesante sobre multitenancy. Multitenancy es un término que denomina a la capacidad de alojar diferentes clientes dentro de tu centro de datos. En el artículo definen cinco niveles diferentes:


  • Nivel 0: Caos. Cada cliente en su propio servidor. Las actualizaciones se aplican a cada cliente y cada uno puede correr sobre una versión diferente.

  • Nivel 1: Caos controlado. Todos los clientes se ejecutan en diferentes servidores físicos, sobre la misma versión del software.

  • Nivel 2: Multi-tenant (vertical). El sistema es capaz de alojar múltiples clientes con la misma versión de software en el mismo servidor. Nuevos clientes se alojan en el mismo servidor. Tiene el problema de que sólo escala hacia arriba.

  • Nivel 3: Multi-tenant (horizontal). Se consigue la escalabilidad horizontal y múltiples clientes pueden compartir múltiples servidores utilizando la misma versión del software.

  • Nivel 5: Utopía. Es igual que el nivel 3 pero ahora además se consigue la forma de ejecutar diferentes versiones del software para el mismo cliente.



Dejando un poco al lado el tema de multitenancy que ya lo he tratado otras veces junto al de virtualización. A mi lo que me ha interesado realmente en el artículo, y con lo que he charlado ampliamente con mi jefe, es el nivel 5.

La idea de tener una versión de tu software para poder mostrársela a los clientes es muy, pero que muy interesante. Aquí, no me estoy refiriendo a una versión demo de la versión estable de tu producto, sino a una versión demo quizás de la última snapshot o de la última semana. ¿Cuán es la razón? Time-to-market (TTM).

El TTM de un producto puede ser bastante grande, especialmente si hay bastantes funcionalidades. Las metodologías ágiles solucionan esto en cierto grado promoviendo las releases frecuentes en intervalos cortos de tiempo, pero aún así la realidad es que ciertas funcionalidades pueden tardar varios meses en ver la luz. Pero, aunque el TTM de un producto sea grande, eso no quiere decir que lo tenga que ser el TTS (Time to Sell, ojo que este término me lo he inventado). Siempre pasa que hay ciertas funcionalidades que están en el roadmap, y que ya se han implementado pero todavía no están en una versión estable, que pueden ganar una venta; y los comerciales se encuentran sin la posibilidad de demostrar dichas funcionalidades y teniendo que conformarse con un "eso lo tenemos para la próxima versión" (bueno en realidad dirán éso, y 100 cosas más :D).

Tener un sistema demo, con lo "último de lo último" puede valer una venta. Ahora bien, ¿vale la pena el riesgo? Porque evidentemente, lo "último de lo último" no habrá pasado unos controles de calidad tan minuciosos como puedan haber pasado las versiones estables de nuestro sistema. ¿Cómo puede reaccionar un cliente a un fallo en este tipo de demo? A un cliente razonable, probablemetne no le importará mucho, pero otros clientes pueden llevarse una muy mala impresión de nuestro producto. Una solución obvia es disponer de un sistema de demo con la última versión estable de nuestro sistema, esa que nunca falla, y utilizarla para las presentaciones. En el momento en que pregunten por algo "especial" que sabemos que les sorprenderá, siempre se puede sacar un "mmm... bueno, sé que no debería enseñarte esto, pero lo haré". El cliente probablemente se muestre complacido, ya que a fin de cuentas le estamos enseñando algo "especial", "sólo para él", y en caso de fallo bueno, la impresión no será tan mala :-)

¿Qué opináis? ¿Vale la pena apostar por una demo con lo último o mejor apostar por lo seguro?

miércoles, enero 09, 2008

Dos documentos sobre software factories y costes de desarrollo

miércoles, enero 09, 2008 por Martín

Tenía pendiente publicar un artículo sobre un documento que vi en el blog de Kybele Consulting y Javier Garzás me lo ha puesto hoy todavía más fácil.

La entrada que quería publicar era sobre la ponencia consideraciones económicas sobre la fabricación de software que Javier publicaba en el blog de su compañía hace unas semanas. Se trata de una presentación muy interesante y que analiza algo que muchas veces los técnicos nos olvidamos de pensar que es el coste real que puede tener el aplicar una refactorización, buena práctica o patrón para el negocio.



Hoy mismo, también se puede encontrar en su blog otro documento muy interesante. Es un mindmap de los principales factores a tener en cuenta a la hora de mejorar o implantar un departamento, equipo o software factory.

Ambos documentos muy interesantes.

martes, septiembre 25, 2007

Bug Driven Development

martes, septiembre 25, 2007 por Martín

Ayer leyendo el blog de Phil Haack me ha gustado mucho la respuesta imaginaria que le hace en su blog a un hipotético escéptico de toda metodología de testing y en la que se inventa el concepto de BDD:

I’m sorry, but I’m not a fan of Bug Driven Development. I think Test Driven Development is not without its challenges, but it’s a better alternative. Either you’re with us, or against us. Are you a bug lover? Bug Driven Development gives comfort to the bugs.

Yo no sería tan radical para decir que si no prácticas el Test Driven Development caerás en un proceso continuo de corrección de errores, pero lo que no cabe duda es que si no existe ningún proceso de calidad, si no existen unit tests, integration tests o una automatización mínima de los tests, se llega a un punto en el que el equipo de desarrollo entra en modo corrección de errores.

Quizás una de las peores consecuencias de esta BDD es que muchos de esos bugs, que no fueron testeados en su momento, ocasionarán cambios en el diseño y en la arquitectura del sistema, cambios que pueden requerir desde horas de código hasta muchos días. Y todo por no seguir un proceso de mínima prevención en un primer momento.

Al final esto de TDD y BDD no deja de recordarme en cierto modo a la medicina preventiva (TDD) y la medicina curativa (BDD).

viernes, septiembre 14, 2007

Eclipse y su infraestructura de testing

viernes, septiembre 14, 2007 por Martín

Hace tiempo hablaba del Eclipse Way y de como me fascina el proceso de desarrollo que siguen.

Repasando un ppoco las charlas de este año de la EclipseCon 2007 (ya ha llovido) me he encontrado con una bastante interesante de Sonia Dimitrov y Kim Moir donde hablaron sobre todo el proceso de QA que se sigue en Eclipse.



Se extraen varias cosas interesantes:

  • Tienen el rol de build engineer para proteger a los desarrolladores del proceso de build (este rol merece un post en si mismo).
  • 176.000 tests en 33.000 JUnit tests ejecutándose en cinco build machines con máquinas virtuales 1.4, 1.5 y 1.6.
  • 469 tests de rendimiento con 2345 tests que se ejecutan en cinco máquinas diferentes. Se ejecutan sólo unos cuantos días debido a que lleva unas 10 horas ejecutar los tests y procesar los resultados.
  • Para asegurarse la validez de los tests de rendimiento utilizan imágenes ghost que instalan justo antes de lanzar los tests.
  • Tienen un conjunto de tests de limpieza. Chequean que todo esté correcto: javadocs, licencias, políticas de código, etc.
  • Los desarrolladores escriben test unitarios, pero el código de los tests se mantiene separado en un CVS propio.
  • Los resultados de los tests de rendimiento se almacenan en una base de datos dedicada.
  • Para detectar fallos tienen un parser que analiza la salida de los tests y en caso de errores genera reportes y los envia a una lista de correo.
  • La mayor parte de los errores que obtienen no se deben en realidad a errores en el código sino a problemas con las máquinas, poco espacio en disco, actualizaciones de software, antivirus, etc.


No sé que os parece, pero a mi me ha sorprendido especialmente toda la infraestructura dedicada al testing, incluido el dedicar un CVS específicamente para el almacenar el código de los tests. Está claro que toda esta infraestructura y este proceso tan elaborado debe tener algo que ver con la capacidad para estar lanzando versiones sin retraso durante cinco años.

jueves, julio 19, 2007

Pero... ¿alguien ha visto una empresa de software?

jueves, julio 19, 2007 por Martín

No me puedo resistir a comentar el debate de moda, si faltan o no programadores. Todo esto empezó con alguien que opinaba que faltaban prgramadores, y a continuación el artículo se propagó como la polvora por otros medios como meneame o barrapunto. Poco a poco han ido saliendo opiniones. Algunas críticas que todavía echaron más leña al fuego, aunque mucha gente está de acuerdo. Después también hay quien hace notar que lo que faltan son programadores motivados, y por supuesto quien critica a las empresas o quien opina que es simplemente la ley de oferta y demanda.

Yo, me voy a guardar mi opinión porque sería volver a marear la perdiz, una vez más. Más o menos comparto un poco la de todos. Está claro que las empresas no encuentran programadores, está claro que si pagasen más dinero aparecerían más, está claro que los jovenes quieren ganar lo máximo posible, está claro que hace años todos sufrimos cuando empezamos, y está claro que programar hoy en día no motiva a mucha gente.

Lo que me ha llamado la atención es que nadie (creo) haya sacado el tema de que faltan empresas de software en España. Porque, digo yo que el habitat natural para los programadores son las empresas de software, ¿no? Ahí es donde puedes encontrar a la mayoría de programadores en otros paises. Sin embargo en España, ¿dónde están las empresas de software?

La mayoría de empresas en España son consultoras, empresas de servicios, o por decirlo de un modo menos políticamente correcto: cárnicas. Esto tiene como consecuencia un mercado totalmente viciado. Es decir, un mercado en el que las empresas subcontratan, tricontratan o cuatricontratan gente para trabajar para el cliente final. Eso sí, si hay suerte igual puedes estar en una software factory, aunque en ocasiones casi seguro que es mejor que no. Un mercado en el que las empresas sí, crean software, pero que el software se quedará ahí, para toda la vida. Software que casi siempre es 1-1, un proveedor-un cliente, release (si hay suerte), mantenimientos, y fin de vida. Software que utilizarán los 1, 10, 100, o 1000 empleados del cliente. Todo ello aderezado con todo el politiqueo correspondiente, con todas las luchas de poder, con todas las luchas entre consultoras trabajando en el mismo cliente, y con la sensación de que lo que estás programando no lo utilizará ni el gato y que simplemente vale para que el dinero que se debería llevar el programador se lo vayan apropiando los diferentes escalafones. Difícil motivarse así, ¿no?

Porque al final a todo el mundo le gusta estar orgulloso de su trabajo. Y no es lo mismo el pensar que tu aplicación la va a usar sólo una empresa (por muy grande que sea), que hacer un software y ver como todo el mundo lo quiere utilizar, ver como se distribuye por internet, ver como aparecen clientes desde Japón interesándose por el mismo. ¿Por qué no pasa esto en España? ¿Por qué no exportamos software? ¿Por qué todos los programas vienen de US, UK, Irlanda, Alemania, Francia, Bélgica, ... si hasta voy a decir Italia? Fácil, porque no tenemos industria de software. Simplemente tenemos trabajo basura. Y así es muy complicado "encontrar programadores".

De todas las personas que conozco trabajando en esto de IT, al final los que están más contentos son siempre los que están en empresas que hacen verdaderamente software; que evidentemente las hay en España, pero como he dicho, ¿cuántas? ¿Cuántas empresas en España hacen software antes de venderlo? ¿Cómo está el capital de riesgo en España para crear verdaderas empresas de software? Las menos, y normalmente pequeñas, y que sufren para subsistir porque al final las ayudas y los concursos públicos se mueven como sabemos todos que se mueven.

Esto quizás sea la cosa que más me ha chocado al venir a Irlanda. El encontrarte con un panorama tan diferente. Un panorama en el que vas a las páginas de trabajo y sobran ofertas bien pagadas, en el que la gente se va de los trabajos y se coge meses sabáticos porque sabe que no va a tener problemas en volver y encontrar otro trabajo, incluso mejor. Y es que la mayoría de este trabajo son para empresas ..... de software. Empresas que consiguen capital de riesgo y arrancan un producto sin clientes, poniendo a trabajar la maquinaria comercial y acabando con un software que se vende en todo el mundo; empresas spin-off que surgen como consecuencia de inversiones de capital o de entidades que ven un nicho en el sector y que deciden invertir; empresas de emprendedores que aprovechan las suculentas subvenciones del gobierno irlandés.¿Subcontratación? Claro que la hay, y alguna oferta me llegó en su momento, pero es muchísimo menos habitual que en España. Y eso que aquí si que existe el fantasma del offshore y los equipos de programadores en la India (nosotros tenemos uno) o los paises del Este.

Pero bueno, sobre Irlanda e IT me reservo otro post para otro momento porque no es sólo esa la diferencia.

Concluyendo, que para conseguir un mercado, y una buena oferta y demanda, y que aparezcan los codiciados programadores, en lugar de discutir tanto sobre si necesitamos o no regularizar la profesión, crear colegios, irse todos a huelgas, o sobre si los programadores ahora son unos señoritos, mejor haría todo el mundo en reflexionar sobre si la industria del software es lo suficientemente saludable como para generar riqueza en España.

Me ha quedado un buen rant :)

miércoles, mayo 30, 2007

Recovery-Oriented computing

miércoles, mayo 30, 2007 por Martín

Recovery-Oriented Computing (ROC) es (más bien era) un proyecto de investigación para la creación de servicios altamente fiables en internet. ROC se centra en la recuperación ante fallos, de hecho asume que no importa lo sólido o robusto que sea el software o el sistema analizado, ya que siempre existirá la posibilidad de fallo (humano, hardware, software).

Sus tres leyes básicas son:

  • Las tasas de fallo de software y hardware son significantes y siempre aumentan.

  • Los fallos no se pueden nunca predecir por completo de antemano.

  • El herror humano, especialmente durante mantenimiento, es una de las mayores fuentes de errores.



Fuentes:
The Berkeley/Stanford Recovery-Oriented Computing (ROC) Project.
Wikipedia.