Cuando 2 + 2 no son 4... ¿Software Exitoso o Software Excelente?

En desarrollo de software a veces los clientes o algunas áreas de las compañías consideran que si hay más hombres en el área de desarrollo de software, entonces todo se hace más rápido.

Es parte del concepto erróneo de considerar al software como un producto, y es muy fácil caer en el error.

Si dos pintores terminan una pared en la mitad del tiempo, entonces ¿por qué dos programadores no terminan un software en la mitad del tiempo? (se pregunta siempre el cliente)

La respuesta es muy simple, lo qué está mal formulado es la pregunta en sí, y es por ello que se cae en el error tan facilmente.

Partamos del hecho de que un software no es un producto como tal... no es un tangible, y aunque es considerado como una obra literaria (en Colombia, porque "está escrito", con sus respectivos derechos de autor), es más bien una "obra intelectual", que nadie va a ver ni su arquitectura, ni sus miles de líneas código, ni sus conexiones a otros software, ni su literatura (o videos) de usuario final para aprender a manejarlo... y eso que no incluyo aquellos software que ni siquiera tienen interfaz de usuario (como los API, Web Services o Clases).

Entonces... ¿dónde lo clasificamos?

En 25 años que llevo desarrollando software, siempre me lo han preguntado. Hoy me atrevo a contestar que es "Un servicio impersonal escalable que aporta soluciones a problemas temporales". Ya sé... ya sé... esta debe ser la expresión que el lector debe tener:

En este punto es donde todos los teólogos de ingeniería de software comienzan a tirarme papelitos, tomates y hasta piedras...  el razonamiento viene por lo siguiente:

1. Un software nunca está terminado.  ¿Por qué? Simple, se comenzó a construir pensando en resolver un problema. Cuando la solución se presenta, por lo general hay nuevas variables, nuevas personas, nuevas políticas, nueva tecnología, nuevas circunstancias que ponen al problema inicial en otro nivel de importancia y aparecen nuevos problemas, por lo tanto, el software requiere de nuevos ajustes... y esto puedo continuar eternamente... hasta que se ve necesario "hacer una nueva vesión" o en el más drástico de los escenarios "hacer otro software". Sencillamente porque "los problemas son otros".
2. No existe un software perfecto. Para el usuario, si el software falla en la ventana 435, de la opción 34, en su computador de hace 5 años: "El software está malo" (así tenga 123 mil líneas de código que funcionan perfectamente).  Pero para hacer un software perfecto debe cumplir tres reglas específicas: (a) Tener un solo botón, (b) un solo cuadro de texto y (c) ningún usuario... Si no cumple con esas tres reglas, el software es imperfecto.  La razón es muy simple, es imposible considerar todos los escenarios, todas las necesidades, todas las formas de pensar de todos los usuarios, al momento de que todos los desarrolladores de software lo tengan en cuenta, en el mínimo espacio de tiempo que hay para hacer el diseño.
3. No es un trabajo lineal de producción. Solamente considerando los puntos anteriores, se da uno cuenta que no es un muro que se va a pintar en forma lineal, con el mismo tono de color de principio a fin.  Es muy probable que mucho antes de terminar el proyecto del software, aparezcan nuevos tonos, pinceladas de nuevos colores, 2, 3 o 25 ladrillos salidos del muro que también hay que pintar. Porque es natural que en el camino se detecten cosas que nunca se consideraron en el planteamiento inicial.  Aquí en Antioquia (Colombia) hay una frase que la han usado popularmente durante cientos de años los arrieros y es "En el camino se arreglan las cargas" y ellos por experiencia sabían que una vez cargado el animal con los bultos, en el camino hay que ajustarlos.
4. Las expectativas del cliente subestiman la labor del desarrollador. Mi mayor pecado como desarrollador es decir que "todo se puede hacer" y hasta ahora no ha existido un proyecto que no pueda hacer (por lo tanto, aplica! jejeje). Pero para el cliente, que piensa en el software como un producto lineal, no se da cuenta de que le ha pedido a una persona que le resuleva un problema... y al desarrollador se le pasa por alto ese detalle... Y si al cliente se le ocurre mover un ladrillo del muro, aunque sea solo un poco, entonces ya el desarrollador debe pensar que ya no puede usar el rodillo de pintura, incluso ni una brocha grande, va a tener que sacar nuevas herramientas de pintura y dedicarle un rato especial solamente a "ese ladrillo"... y aquí viene la máxima del cliente "No me puede cobrar de más, es el mismo muro!".
5. 2 + 2 no son 4. Entonces en este punto del proyecto comienzan los cuestionamientos: ¿qué se hizo mal? ¿hay que poner más gente para que se termine más rápido? ¿Es necesario pulirlo tanto?  Mientras se mire el software como un producto, estas preguntas y muchas otras que resultan parecen no tener respuesta clara o justificación alguna... por el simple hecho de que está mal planteado el cuestionamiento!  Dejemos de pensar en el software como un producto, pensémoslo como una solución a un problema y volvamos a hacer las preguntas: 

• ¿Qué se hizo mal? Obvio: hacer las preguntas correctas del problema y tener todas las respuestas concretas al comienzo del proyecto, y el mismo cliente dirá: "es posible que esto cambie en el camino, puesto que estamos esperando que... etc, etc".
• ¿Hay que poner más gente para que se termine más rápido? Eso es como preguntar si dos madres educaran el mismo niño en la mitad del tiempo. La respuesta es la misma, el niño podrá tener más herramientas en un menor tiempo, pero no en la mitad del tiempo.  Un problema no se resuelve en la mitad del tiempo por le hecho de poner a dos pensadores a trabajar en él... es posible incluso que hasta se demore el doble, porque entre los dos, le encontraron más ladrilos salidos que uno solo!
• ¿Es necesario pulir tanto?  Una petición de mediocridad en un proyecto de software es un fracaso inminente.  Es por ello que no se puede considerar como un producto, no se puede esperar que sea un software exitoso, pero si es una norma de oro que sea un software excelente y la excelencia no es de productos, es de servicios! Entonces me aparecen opiniones como "Es que el éxito se mide al cumplir el proyecto en el tiempo estipulado", yo respondo: "El exito se mide cuando todos sus usuarios están contentos con el funcionamiento" y qué significa que están contentos: "que nunca les falló nada y que no se dan cuenta que están usando un software" (solo un usuario se da cuenta que está usando un software cuando se le daña en la ventana 435, de la opción 34, en su computador de hace 5 años). Incluso es mejor tener una misión espacial excelente que una misión espacial exitosa!.

Todo esto, no es un compendio de razones para justificar una entrega demorada... es un llamado a la excelencia y a ponerle nombre, razón y justicia a aquellos detalles que el cliente no puede ver, porque sencillamente nunca nadie se los mostró!

Cliente: Es un muro pintado simplemente!
Yo: Eso es lo que usted quiere pagar, pero no es solo eso. Lo que usted pide es una barrera de contensión lumínica, que evitará que sus visitantes tengan calor, les de el resplandor en la tarde y los conductores puedan sentir que viajan por una galería de arte cuando pasan por aquí.

Recuerden: "Es solución de problemas... no trabajo lineal"!