Páginas

martes, 25 de febrero de 2014

Desarrollar software es como ser detective de homicidios (más o menos)

Hace unos días, viendo un capítulo de la serie Castle, llegué a una interesante a la par que absurda conclusión. Pensé en lo mucho que se parecen los trabajos de detective de homicidios y desarrollador software (al menos, en la parte de solución de incidencias).
El capítulo comienza siempre con un cadáver (una incidencia, algo no funciona como debe). Rápidamente la escena del crimen se llena de especialistas: víctimas (usuarios), médicos forenses (ficheros de trazas), detectives (informáticos), etc. Y la pregunta que todos nos hacemos es la misma: ¿Qué ha ocurrido aquí? Y empezamos a indagar... 

Las pruebas (los ficheros de trazas) revelan algunas cosas. Algunas veces, la información que recogen es insuficiente, por lo que es necesario repetir la situación de error (esto es algo que los detectives no pueden hacer, aunque en Dexter hacían algo parecido). 

Hay que tener muy en cuenta que, en ocasiones, las pruebas llevan a los detectives a conclusiones equivocadas. Esto traducido al mundo informático, puede equipararse a los llamados errores fantasma. Es decir, todo apunta a que la causa de la incidencia ha sido una pero en realidad esa causa está ocultando otra(s) que son las que realmente están tras el asunto. Y esto hay que tenerlo muy en cuenta antes de lanzarse a la piscina. 

Es entonces cuando los detectives, tras sus primeras pesquisas, detienen a un sospechoso y lo llevan a la sala de interrogatorios. En Castle lo habitual es que pasen por esta sala 3 o 4 sospechosos que cuando entran parecen culpables y resulta que no lo son tanto. Esto sería ponerse a revisar el código donde supuéstamente se encuentra la causa de la incidencia (por cierto, alguna vez hablaré de las diferencias entre incidencia y error, aunque ahora podemos considerarlos equivalentes). Investigas, revisas y, ¡por fin! es ese "if" el que está causando el problema. 
 
Aquí hay 2 tipos de desarrolladores, los que consideran al "if" culpable y lo borran directamente y los que se preguntan qué carajo hace ese "if" ahí, quién lo puso y por qué.

El primero es el detective que le da una paliza al sospechoso y lo mete al calabozo. Unas horas después el abogado acude a liberarlo y al poli le cae una demanda. 

El segundo es el que no se queda conforme con una respuesta fácil y no actúa sin estar seguro. Por cierto, casi siempre el que borra (o añade) algo sin saber lo que está haciendo la acaba liando. 

Así pues, lo suyo es verificar todas y cada una de las sospechas que uno tenga hasta dar con la clave del asunto y poder solventar la incidencia, resolviéndo así el crimen y atrapando al asesino. No sería la primera vez que se puede solucionar una incidencia sin tocar código, teniendo en cuenta tan sólo los datos de entrada o configuraciones. 

 En fin, ahí lo dejo, para desmitificar un poco a los desarrolladores de software ;-)

No hay comentarios:

Publicar un comentario