Archivo de la categoría: desarrollo software

Qué funciona haciendo software y por qué

En la pasada CAS hubo una keynote en la que se hablaba de estudios relacionados con el desarrollo de sofware, y de su “relativa” validez. Estoy muy de acuerdo en que algunos de estos estudios dan un poco de risa, y de hecho ya hice ese ejercicio de analizar dichos estudios hace unos años. No estoy muy de acuerdo con el mensaje, que se reducía IMHO a “No te fíes de nada, prueba con todo a ver si a ti te funciona” utilizando los mismos argumentos y estrategias que se critican cometiendo algunos errores de bulto, pero es no es la cuestión principal.
La cuestión cuando llegamos aquí es: ¿es posible medir los beneficios de determinadas prácticas desarrollando software?  San Martin de Fowler habla de la evidencia anecdótica para referirse a prácticas que funcionan en un caso como algo útil en ausencia de datos objetivos (dado que opina que no podemos medir la productividad). Efectivamente los equipos de software son sistemas muy complejos en los que es muy difícil medir como una práctica determinada influye en nuestro rendimiento más allá de sensaciones, no tenemos la regla de medir la productividad y así poder decir al finalizar una iteración que, por ejemplo, hacer programación por parejas a aumentado/disminuido nuestra productividad en un x%. Bajo mi punto de vista esto tiene varios problemas:
  • En primer lugar no tenemos esa regla para medir productividad. Normalmente funcionamos más por sensaciones, por lo que nos parece que funciona, que con datos objetivos, por lo que nos quedamos siempre en el terreno de lo discutible (y ahí seguimos, discutiendo).
  • Digamos que podemos medir la productividad en historias/puntos/loQueSea, siempre tendremos una medida relativa que para cada equipo y que sólo funciona para ese equipo, lo que limita mucho la validez y generalización de estas medidas. Eso suponiendo que funcione algo para ese equipo, porque en muchas ocasiones esas métricas no existen.
  • Aunque encontráramos esa manera de medir la productividad, si algo está demostrado es que el esfuerzo dedicado a mantener un software es mayor que el esfuerzo dedicado a su desarrollo inicial, por lo que habría que medir también la “mantenibilidad” de dicho software, lo que bajo mi punto de vista es aún más complicado.
Dicho esto, retomo la pregunta, ¿es posible medir los beneficios de determinadas prácticas? Parece complicado, y aunque existen muchos estudios de todo tipo, no hay conclusiones claras, o al menos y no las conozco. Es difícil aislar un estudio de todos los factores externos que hemos comentado, pero eso no quiere decir que sea imposible. Quizá no hemos encontrado la manera correcta de hacerlos, o quizá realmente no nos interesa contar con esos datos como industria, y preferimos movernos en el terreno de la incertidumbre, y seguir vendiendo humo que parece que funciona bien.
Hay personas en este mundo que han construido un acelerador de partículas para acelerar átomos a velocidad absurda para durante un tiempo infinitesimal podar visualizar elementos cuánticos como el Bosson de Higgs, y resulta que la industria del software no es capaz de comprobar si dos personas en el mismo ordenador programando rinden mejor que una. Francamente me resulta desolador, pero si existen intentos de llevar esta experimentación un poco más allá: https://vimeo.com/9270320 ( vía un tweet de @javisantana).

Predictivo Vs Ágil

Escuchando el podcast de Workos.cat sale el tema de si el desarrollo ágil es para todo tipo de proyectos (escúchalo, ellos también tienen su conclusión :). Parece evidente que no, si sabes exactamente lo que vas a hacer, como se hace y quién lo va a hacer, lo más razonable es usar una metodología predictiva. El diagrama de Gantt te va a quedar muy chulo, y encima lo vas a clavar (recordemos que sabemos el qué, el como y el quien de pe a pa, por lo que deducir el como es sencillo). No les quito la razón, pero yo opino que…

  • Es muy fácil “creer” que sabemos todo eso, cuando no lo sabemos. De hecho, nos hemos basado en que lo sabemos, o en que podemos averiguarlo rápidamente, durante décadas a la hora de hacer software.
  • Es muy fácil porque los humanos somos especialistas en distorsionar la realidad de distintas maneras: El cliente cree que sabe lo que quiere, el desarrollador cree que le entiende, el que sea que mida todo esto y lo traduzca a dinero cree que conoce la tecnología y lo puede estimar… Pero la realidad es que existen ciertas leyes en la gestión de proyectos software que insistimos en ignorar, y nos hemos dado tortazos contra esta realidad durante mucho tiempo (y aún seguimos).

Por todo esto, si crees que lo sabes todo, adelante, gestión predictiva. Pero asegúrate de saberlo todo, todo, todo.

En muchas ocasiones (2) me he encontrado con gente que ya lo sabía todo o casi todo. En la mayoría de los casos, programadores, desarrolladores, analistas o lo que seamos, que sabían más que el usuario, que se equivocan nunca o casi nunca, que hacen notar los errores ajenos más que los propios… y a los que el desarrollo ágil les parece ineficiente, “por que ya sabemos como hacerlo” (y más cosas, pero el tema es el que es). Siempre les digo lo mismo: si estamos seguros, es mucho más eficiente la gestión predictiva. Siempre pasa lo mismo (las dos veces que me ha pasado), seguimos igual, tan seguros no estaríamos.

BilboStack 2012

Los chicos de webDevBilbao, junto con PlainConceptsSimettric y la colaboración de la Universidad de Deusto se han liado la manta a la cabeza y ahn organizo el BilboStack Developers Conference. En una mañana, 10 charlas en dos tracks con lo mejor de los desarrolladores de por aquí. Además me han dejado hablar a mi sobre “Programación Extrema”. Un montón de gente conocida, intercambio de opiniones y puntos de vista, y en mi caso una huida temprana por compromisos familiares.

Este tipo de eventos siempre son bienvenidos, y si es al lado de casa, más. Aunque creo que el nivel de los ponentes era muy alto, resulta que a algunos les a parecido que mi charla estuvo bien (ya ves, hay gente para todo). Es curioso que preparé una presentación, pero como veía que no aportaba nada más que un guión para mi, la deseché, y salí a hablar con un puñado de tarjetas en la mano. A algunos eso les ha parecido “vintage”, mientras que otros me dan un diez e incluso creen que lo hice “como los machos”. Simplemente creo que era lo mejor, lo malo es que ahora no tengo presentación para poner aquí (jaja),  aunque creo que si que se publicará un video, y tengo unas notas que escribí por si quieres saber más sobre la programación extrema.

Un asistente me preguntó cuanto de lo que había contado aplicaba en el día a día. La respuesta es todo, auqnue con matices. Evidentemente no todas las técnicas las domino perfectamente, y siempre no se puede conseguir todos los medios deseados, pero en cierta medida lo aplico todo: Tdd, integración continua, diseño simple, pruebas automaticas, historias de usuario… pero la idea principal no es esa, sino que revises como lo haces, pruebes cosas nuevas y te quedes con lo que te funciona, siempre con espíritu de mejora continua, que es lo que te llevará a hacer mejor software.

PD: A este le gusto, y este otro me pone un diez.

Actualización: Ya está disponible el video gracias a Fran Mosteiro:

Etiquetado ,

Plain concepts en el WebDevBilbao

Ayer asistí a una nueva edición del WebDevBilbao. Esta ocasión contabamos con la presencia de la gente de PlainConcepts, que como ellos mismos explicaron, son una empresa que da muchos servicios como consultoria, formación, coaching y desarrollo de aplicaciones a medida.

En la parte de desarrollo a medida utilizan metodologias agiles, como no podía ser menos con la gente que cuentan: Rodrigo Corral, Ibon Landa, Vicenç García-Altés… Al final de todo lo que cuentan me quedo con lo que valoran la excelencia en todos los terrenos, con especial incidencia el terrreno técnico. Pruebas unitarias a tope, integración continua tope… Todo esto cuesta dinero y atraer al personal necesario para poder hacerlo es difícil, y uno de los retos es el crecimiento sostenido manteniendo la calidad. Y motor o todo esto es… “el egoísmo” porque cuanto mejores sean, más y mejor trabajarán y el producto obtenido estará en consonancia con este esfuerzo, y por eso se empuja al personal a buscar esa excelencia.

Se comento también cuanto más produce un buen programador con respecto a uno normal, o uno malo. ¿El malo resta? Yo creo que sí, que el malo resta y además produce sensación de frustración en el resto, al tener la sensación de que no avanzamos porque tenemos un lastre con el que cargar.

A nivel personal me quedo con la duda de como lo haría yo en una empresa de este tipo, si podría seguir el ritmo. Hace mucho tiempo que estoy seguro de que hay que ser “el peor saxofonista de la banda”, como dice Chad Fowler, porque así aprenderás más y seguirás progresando. Igual tengo que buscar otra banda.

Etiquetado , , , ,

En Pensamientos Ágiles comentan cinco preguntas a realizar en tu próxima entrevista de trabajo, para conocer mejor la empresa a la que vas a ir. Yo he probado a hacérmelas pensando en mi actual puesto de trabajo, y la respuesta da pena. En general, la conclusión es que en un departamento de tecnología la propia tecnología importa poco, lo importante son los procesos ignorando las ventajas que nos puede dar un uso apropiado de la misma. En mi opinión este error es una de las causas principales de que los desarrollos de software realizados no respondan a las expectativas creadas, con retrasos, baja calidad, problemas de mantenimiento… esas cosas que les pasan a todos los proyectos El principal problema es que no sé si será posible reconducir el rumbo, aunque la pregunta principal es si la gente que lleva las riendas tiene la misma opinión que yo, cosa que dudo, porque entonces ya se habría hecho algo. En fin, si están ahí será porque saben mucho más que yo, esperemos que sea yo el que este equivocado y esto no sea como el mar muerto.