archivo

Archivos diarios: septiembre 24, 2011

Uno de los principales problemas de las organizaciones es que estratifican a sus empleados en: fundamentales, clase media y “a despedir”.

Los fundamentales son los que destacan sobre manera por encima, a ellos les corresponden los retos más motivantes y los premios a sus resultados y productividad.

Los “a despedir” son los que destacan sobre manera por debajo, generalmente son miembros de extensa clase media a los que se les ha notado demasiado su falta de eficiencia e implicación en el trabajo. Todos ellos, terminarán en la calle.

Y después está el grupo más injustamente numeroso: la clase media. A este grupo se le suele aplicar la misma política, el mismo trato, algo que es un error tremendo ya que precisamente son el motor de la organización.

El tamaño considerable de la clase media provoca que en el amparo de la misma se esconda personal netamente improductivo individualmente y para el grupo, pero que tienen la suficiente habilidad (incluso en muchos casos tampoco hace falta tener excesiva) para que no se les note.

El hecho de que a personal productivo que pertenece a este grupo se les trate como a los que no lo son afectará más pronto que tarde a la productividad general de la organización porque por mucha ética personal y del trabajo que tengan, son personas y todas necesitan una motivación para dar lo mejor de sí.

Para solucionar este problema, las organizaciones deben dejar de formar estos grupos virtuales (en la mayoría de los casos lo hacen sin darse cuenta, simplemente porque una gestión de esas características requiere menos esfuerzo y menos implicación personal por parte de los gestores) y realizar hasta donde sea posible un política que motive y premie a todos los que lo hacen bien, independientemente del lugar que ocupen en la organización, independientemente del tiempo que lleven en la misma, independientemente de los contactos que tengan.

Me hace mucha ilusión apoyar a proyectos realizados por mis amigos.

Me encanta ver como lo que tienen en la cabeza se ve materializado posteriormente en un producto.

El desarrollo de la informática ha sido provocado en gran medida por personas que un día decidieron pasar sus sueños a código fuente.

En este caso ha sido un juego, mañana puede ser otra cosa.

Si queréis ver en qué consiste el juego, podéis acceder a un trailer que está disponible en su sitio web.

Mucha suerte Jorge.

Pienso que una de las consecuencias de la creatividad que tenemos los que nos dedicamos al mundo del desarrollo de software consiste en pensar que lo más interesante es el proceso de análisis y construcción del software (más lo segundo que lo primero).

Esto lo puedo entender de personas que hayan comenzado hace poco en este mundo, sin embargo, lo entiendo mucho menos cuando lo piensan quienes llevan ya años trabajando en este negocio.

El desarrollo de software va más allá del IDE. La codificación es importante, pero hay otros muchos aspectos tan importantes o incluso más que ella (ya que pueden condicionar sobre manera la realización de esta actividad: una mala venta, un mal análisis, la selección de una metodología de desarrollo no adecuada, una mala elección del equipo de proyecto, una mala comunicación entre los integrantes del equipo de proyecto, una mala comunicación con el cliente, una deficiente respuesta ante situaciones de crisis, etc…).

Otro aspecto que considero importantísimo es el testing. Que el equipo de proyecto esté formado en este disciplina lo considero fundamental, que apliquen técnicas y buenas prácticas relacionadas con las mismas es importantísimo y que la metodología de desarrollo aplicada tenga integrada la realización de este tipo de tareas es necesario.

La detección de errores, lo más próxima posible a su origen, ahorra dinero, tanto que justificaría, por sí solo y como mínimo, lo especificado en el párrafo anterior y en el caso de sistemas de un tamaño importante o de una empresa de desarrollo de software con multitud de proyectos en cartera justificaría la existencia de equipos específicos para la realización de esta actividad, ya sean propios (pero debidamente formados) o externos.

Y ya no es solo es ahorro de dinero tangible, sino también la importante pérdida de imagen ante el cliente, por errores perfectamente evitables y que, por supuesto, directa o indirectamente afecta a la cuenta de resultados del proyecto.

Cuando digo que somos culpables de la situación en la que se encuentra nuestra profesión no lo hago gratuitamente, no tiene que pasar mucho tiempo para encontrarme ejemplo tras ejemplo que demuestran que nuestra pérdida de imagen es consecuencia de la crisis del software y que la misma, lejos de estar superada, sigue estando vigente y donde los principales culpables de que décadas después se siga hablando de ella somos nosotros.

No hace mucho un amigo me habló de una conversación que tuvo con un responsable de un departamento de su organización en la que se discutía si el coste presupuestado para el proyecto era el adecuado o no.

La metodología para hacer el presupuesto fue la siguiente: dos grupos de personas hicieron un estudio del objeto del trabajo, que estaba por escrito y con un nivel de detalle aceptable, cada grupo lo realizó sin saber cómo valoraba la otra parte. Se pusieron en común ambos presupuestos y la diferencia entre ambos fue mínima.

Ambos grupos de personas estaban formados por personal de la organización, es decir, no se solicitó la colaboración de entidades externas que podrían ser interesados en minimizar sus riesgos y/o incrementar sus beneficios haciendo presupuestos con suficiente holgura. Esto quiere decir que no había ningún factor o interés que, hablando claramente, hiciera que los equipos que estaban presupuestando inflasen alegremente los presupuestos.

Teniendo en cuenta la experiencia de los equipos que realizaron la valoración y los resultados similares obtenidos en las mismas, desde mi punto de vista es más que suficiente para ser considerado el presupuesto base del proyecto. ¿Qué puede haber errores? Pues sí, puede haberlos, pero mejor siempre partir de situaciones como las que he descrito que de otras donde no se le haya dado tanto cuidado y mimo.

Entonces, si el cálculo del presupuesto se había hecho de manera rigurosa y por personas imparciales, ¿de dónde viene el problema? Pues de la mala experiencia que tiene el responsable del departamento con otros proyectos de desarrollo en los que ha estado vinculado, en donde los resultados obtenidos se han situado muy por debajo de la inversión.

¿Qué es lo peor de todo? Pues que tiene razón en la visión que tiene del desarrollo de software, si toda su experiencia (que no era poca, por otra parte) se basa en sistemas de información deficientes por los que ha tenido que pagar una importante cantidad de dinero y en donde el retorno de la inversión nunca se ha producido, todo presupuesto que le presentes le parecerá caro, independientemente de la buena fe y práctica con que lo hayas desarrollado.

Esta situación que he descrito la he vivido en primera persona y en otros casos, como en el caso de este artículo, me la cuentan otros profesionales y se produce de manera recurrente.

Por tanto, es importante que todos los que nos dediquemos a este negocio tengamos en cuenta que si desarrollamos basura, la basura termina salpicando a todos y que como suele pasar en prácticamente todos los ámbitos de la vida, hacen falta muchos buenos recuerdos para borrar uno malo.

Mutation testing es una técnica de pruebas de caja blanca que surgió en la década de los setenta que se utiliza para realizar una verificación de la calidad de los métodos y procedimientos de testing utilizados.

El motivo principal de la utilización de este tipo de estrategias es la de comprobar si las pruebas definidas son correctas y cubren los requerimientos del sistema que se está verificando. A veces se definen pruebas que efectivamente dan por válidas las salidas correctas de un determinado programa, pero que también dan por válidas otras salidas que deberían ser erróneas, es decir, nos centramos en comprobar que el resultados que esperamos se produce sin pensar en que lo mismo hay otras formas anómalas de producir resultados que además son incorrectos.

¿En qué consiste la técnica? En realizar ligeras modificaciones al código fuente original que deberían provocar unos resultados diferentes al normal y comprobar si la técnica de testing utilizada puede detectar estos cambios. Ejemplos de estos pequeños cambios lo podemos tener modificando el operador en las guardas de sentencias selectivas o iterativas, eliminando sentencias, etc…

Si la técnica de testing no ha detectado el cambio puede ser por dos motivos, por un lado que los cambios en el código fuente no han sido ejecutados (ya sea porque ese fragmento de código no se ejecuta nunca) o porque la estrategia de testing ha fallado. Para intentar que este tipo de situaciones no provoque falsos positivos lo que se hace es incluir mutaciones en zonas cubiertas por pruebas unitarias (y que se ha verificado que el código puede llegar a ejecutarse) o bien realizar mutaciones en diversas zonas del código.

Quien esté libre de pecado que tire la primera piedra.

¿Nadie ha copiado y pegado código de Internet en su aplicación y ha hecho adaptaciones del mismo hasta que lo ha hecho funcionar?, ¿lo mismo solo que en lugar de Internet el código procede de otra aplicación de tu organización o en la que has participado previamente?.

Soy de la opinión de que en lo posible hay que intentar entender lo que se está haciendo porque si no es así, no tendremos completa seguridad, salvo que realicemos una buena batería de pruebas, de que realmente el código funciona. Además, si no lo entendemos y toca hacer una mantenimiento evolutivo del mismo, nos encontraremos con la misma situación de partida solo que ahora probablemente no tendremos código que copiar y adaptar.

A veces los plazos se nos echan encima, queremos quitarnos una tarea de cierta complejidad que realmente no tiene mucha importancia dentro del proyecto o hay algo que no nos termina de funcionar. Esto provoca que en ocasiones se busquen soluciones donde sea y se da lugar a esta práctica que todos sabemos que aunque pueda ser efectiva en ocasiones, no es nada positiva en el proceso de desarrollo de software.

Hay quien entiende esto como reutilización de código. Si se quiere reutilizar código, yo entiendo que lo mejor es utilizar la fórmula de las librerías, de las API (cuando se delega funcionalidades en terceros), ya que se tiene más controlado el software que se utiliza. También podría entender esto como reutilización de código si se comprende lo que se está haciendo, es decir, lo que se hace es ahorrar un trabajo que no va a aportar nada, que es pesado, que sabemos como hacerlo y que ya está hecho en otro proyecto.

Sobre copiar y pegar código de otras fuentes (en este caso Internet), el desarrollador Mike Johnson realiza la siguiente reflexión: “Copiar y pegar código de Internet en el código del programa es como masticar chicle que has encontrado en la calle”.

Se pueden dar multitud de circunstancias en un proyecto de desarrollo de software para que personal del cliente o del proveedor se puedan enfadar y en más de una ocasión.

Hay veces que el enfado es como consecuencia de actos que pueden sobrepasar el umbral de la tolerancia de una persona, como pueden ser situaciones de falta de respeto o una negligencia reiterada. Pero la mayoría de las veces el enfado, aún estando justificado, es por situaciones que realmente no tienen importancia o no tienen impacto en el transcurso del proyecto.

Es cuestión de que cada uno de nosotros hagamos memoria y recordemos los enfados que hayamos podido tener en los últimos proyectos en los que hemos trabajado, ¿cuántos eran por nimiedades que se convirtieron en montañas por nuestro estado de ánimo o por la presión del proyecto?, ¿cuánta energía podríamos haber ahorrado si hubiéramos enfocado el problema de otra manera?, ¿cuánto tiempo perdimos en enfadarnos y desenfadarnos?.

Yo todavía no me he encontrado con ningún proyecto en que enfadarse haya servido de algo, en todo caso ha podido ser útil cuando ha dado lugar a decisiones (si han sido acertadas), pero no por el simple acto de enfadarse. En todo caso hay que tener cuidado con lo que se decide estando en caliente porque en estos casos nuestra capacidad racional se ve ofuscada por otros sentimientos, como por ejemplo la ira.

Enfadarse sin más no arregla nada, alimentar una espiral en la cual más personas se enfaden y a la vez el tuyo se incremente, menos.