Imagínate que quieres ir a comer a un restaurante.
Después de buscar un poco, te decides por una arrocería que tiene una pinta estupenda. Cuando llegas, un atento camarero te trae la carta y eliges un arroz con bogavante que, según te aconseja el solícito camarero, es magnífico.
- Tardará unos 10 minutos en prepararse, queremos asegurarnos de que todo está a su gusto – te advierte.
Te resulta extraño porque sueles cocinar bastante arroz y sabes que tarda unos 20 minutos en estar listo, pero prefieres pensar que aquí son muy eficientes, porque la alternativa de que tengan el arroz hecho y lo vayan a recalentar te pone un poco nervioso.
Cuando pasados más de 20 minutos allí no ha aparecido arroz alguno, se lo reclamas al camarero. Éste, disculpándose amablemente, te explica que ha habido algunos problemas pero que ya casi está. Empiezas a enfadarte: estaba claro que no podían preparar el arroz en 10 minutos y, una de dos, o te están engañando o no tienen ni idea de hacer arroz, pero bueno, prefieres no pensar mucho en ello y disfrutar de tu arroz cuando llegue.
Y por fin llega el arroz. Con pollo.
- Esto es pollo. ¿Y el arroz con bogavante que había pedido? – preguntas al camarero.
- Vaya, lo siento. Tiene que haber sido un error. Le preparamos un bogavante y se lo añadimos a este arroz, así no tiene que esperar otra vez y podemos aprovechar parte del trabajo que hemos hecho ya.
Respiras profundamente mientras vas asumiendo que vas a comer arroz con pollo y bogavante. No suena muy bien, pero tienes suficiente hambre como para aceptarlo.
Cuando llega el bogavante, te mira con ojos desafiantes mientras avanza hacia ti chasqueando sus pinzas.
- ¡Está vivo! ¿Me ha traído un bogavante vivo?
- Verá, señor, vamos justos de tiempo, teníamos que haber terminado con su mesa hace un rato, pero su proyecto, digo, su comida, está resultando más complicada de lo que esperábamos y…
- Quiero mi bogavante. Y, por supuesto, lo quiero cocinado.
- Sí, señor, no se preocupe que esto lo solucionamos enseguida. Pondremos a nuestros cocineros certificados en bogavantes a trabajar en ello para asegurarnos de que reconducimos su proyecto, digo, comida.
Ahora sí, el bogavante tiene un aspecto mucho más apropiado y, por fin, puedes empezar a comer tu arroz (ya frío) con pollo (bastante reseco) y bogavante… ¿dulce? ¿Han cocido el bogavante en agua con azúcar? ¿A qué clase de experto certificado en bogavantes se le ocurriría hacer eso?
- Perdone, pero este bogavante está cocinado con azúcar. ¿Es que sus expertos no comprueban lo que están haciendo? ¿Por qué siempre me traen cosas sin sentido?
- Verá, nosotros creemos en trabajar estrechamente con el cliente durante la fase de testing y control de calidad para asegurar que la comida ofrece el valor añadido esperado. Además, habíamos reservado unas determinadas horas para atenderle y esto se está alargando más de lo previsto, por lo que comprenderá que tenemos que facturarle…
La realidad del desarrollo de software
Por desgracia, así funciona la mayoría del desarrollo de software, al menos en España.
Casi siempre que nos juntamos unos cuantos desarrolladores y nos quejamos de nuestro trabajo acabamos hablando de comerciales que sólo se preocupan por vender, de clientes que no saben lo que quieren (y tampoco están dispuestos a pagar un precio justo por ello) y de usuarios empeñados en “romper” nuestros preciosos sistemas.
Pero sobre todas esas cosas, si echo la vista atrás, lo que más frustración me ha producido ha sido la relación con otras empresas de desarrollo o con los departamentos de desarrollo de otras empresas.
Pocas veces he sufrido tanto como cuando yo he sido el cliente de un desarrollo.
Y eso que, se supone, algo sé del tema y debería estar preparado. O a lo mejor es justo por eso, porque sé algo del tema y sé que hay otras formas de hacer las cosas. En cualquier caso, cuando pienso en lo que debe de sentir alguien que contrata un desarrollo de software a la típica empresa del sector, me da lástima.
La mayoría del software que te entregan tiene una calidad ínfima.
Comprendo que definir correctamente la funcionalidad de un sistema no es una tarea fácil, requiere una buena comunicación y estoy dispuesto a asumir mi culpa como cliente por no haberla expresado bien o incluso por no haber sabido lo que realmente necesitaba, pero hay cosas que claman al cielo.
Aplicaciones que nadie se ha molestado en probar. No digo ya probar a fondo y cubrir cada caso extraño que pueda producirse, sino simplemente ver que se ejecuta y hace algo mínimamente lógico. No puede ser que se entregue una aplicación que a duras penas funciona en el caso más simple, y que, por supuesto, en cuanto fuerzas un poco, explota por mil sitios diferentes.
Los fallos de regresión están a la orden del día, y conseguir estabilizar un sistema se convierte en una auténtica labor de malabaristas; por cada cosa que se arregla se rompe otra.
Interfaces de usuario diseñados a patadas. No todos contamos con un excelente equipo de diseñadores para hacer interfaces de usuario atractivos y originales, pero qué menos que molestarse en mantener los controles alineados, revisar errores tipógraficos, ser consistente en los patrones de interacción. No hace falta ser un experto diseñador, con aplicar un poco de sentido común y poner algo de interés basta.
Usabilidad inexistente. ¿Que hay que obligar al usuario a dar 40 pasos para hacer una tarea que tiene que repetir 30 veces al día? ¿Que los mensajes de error son incomprensibles? ¿Que dejamos que el usuario destruya toda su información por no validar lo que introduce en el sistemma? Da igual, es su problema. Que aprenda a hacer las cosas bien y ser eficiente.
Gestión del ciclo de vida del producto nula. Lo he dicho antes: desarrollar es sólo el principio y entregar una aplicación es sólo un primer paso. Estoy cansado de que nadie haya previsto un plan para actualizarla, que no haya forma de diagnosticar errores en producción o que, ni siquiera, sea posible saber qué versión se está ejecutando en producción.
Y ojo, que en ningún momento estoy hablando de la calidad del código o la metodología empleada. Como cliente, me da igual la calidad del código, me importa el resultado que obtengo.
Me gustaría decir que estos problemas sólo se dan en determinados tipos de empresas, pero me los he encontrado trabajando con empresas grandes y con empresas pequeñas. Con empresas que tenían un organigrama tradicional, con una separación muy clara de roles entre comerciales, analistas, programadores, etc., y con empresas mucho más planas. Con empresas waterfall y con empresas agile. Con empresas desconocidas y con empresas “Business Golden Partner of the Century” del fabricante de turno. Con empresas caras y con empresas baratas.
Mi experiencia es que, desde el punto de vista del cliente, el panorama a la hora de contratar un desarrollo de software es desolador. No creo que se trate de un problema técnico. Tampoco de un problema comercial o de negocio. Es una cuestión cultural.
Y, sin embargo, funciona
Lo sorprendente de todo esto es que, al final, el mundo funciona. Y funciona a base de software. ¿Cómo?
Ha llegado un punto en que se asume que contratar un desarrollo de software será algo que requiera un esfuerzo enorme por parte del propio cliente para obtener un resultado final dudosamente aceptable. Como decía antes, es una cuestión cultural: hemos asumido que esto es lo que hay. Los clientes no son conscientes de que hay otra forma de desarrollar software.
Así, todos esos problemas que mencionaba antes y que a mi me parecen tan graves, no los son tanto para otros clientes. Están dispuestos a asumir que tendrán que perder mucho tiempo en conseguir que el proyecto arranque. Que, es cierto, nunca funcionará como las aplicaciones “de verdad”, porque, claro, es una aplicación “que nos hicieron a nosotros, y tiene sus cosillas“.
No sé en qué punto decidimos los clientes y usuarios que no importaba que el software fallase, pero es algo que tenemos bastante interiorizado. En otros productos esperamos que el funcionamiento sea siempre perfecto y predecible. En el software aceptamos que a veces “pasan cosas”.
Esa idea de que es normal que el software falle la hemos llevado a la contratación de un proyecto. Si contratases a un pintor para que te pintara la casa, no permitirías que te dejara las paredes mal acabadas, con manchas y ronchones. Tampoco verías normal que la pared que habías pedido azul acabase de color rojo. He visto muchos clientes de desarrollos de software que, cansados de luchar para que la pared fuese azul, acaban quedándose con la pared roja. O verde. O lo que sea, con tal cerrar de una vez el proyecto y acabar con esa pesadilla.
Esta gestión de expectativas entre empresas de desarrollo y clientes es lo que permite que el sistema siga funcionando. Sí, te he entregado un producto deficiente, pero es lo que hay. Todas las empresas somos iguales y esto funciona así. A veces me recuerda al mundo de las operadoras de telefonía. Todas te tratan mal, pero saben que pueden hacerlo porque son todas iguales y, vayas donde vayas, acabarás en la misma situación.
¿Todas? No. No todas las empresas son iguales.
Hay empresas que intentan cambiar esto. Que intentan actuar con profesionalidad y responsabilidad. Por desgracia, estas empresas tienen que luchar con la inercia de un mercado en el que cuesta mucho vender calidad porque, simplemente, el cliente no cree que eso exista.
Por eso me frustra especialmente esta situación.
Porque, además de afectarme como cliente, me afecta como desarrollador. Llega un punto en que lo podría convertirse en una ventaja competitiva (intentar hacer bien las cosas), queda anulado por el escepticismo de un cliente demasiado acostumbrado a que eso no existe.
No sé cuál es la forma de cambiar esto. A mi me resultaría más agradable vivir en un mundo en el que la gente se responsabilizase de su trabajo y actuase con profesionalidad, pero hay que ser realista y asumir que los incentivos económicos son los que mandan.
Mientras los clientes estén dispuestos a convivir con este tipo de desarrollos, estas empresas seguirán existiendo. Aun así, no pierdo la esperanza de que, algún día, si hay suficiente gente actuando con un poco de sentido común, alguien se dará cuenta de que se puede trabajar de otra manera, mucho más productiva y satisfactoria.
Hasta entonces, siempre podré seguir escribiendo rants absurdos como éste. No solucionan nada, pero al menos ayudan a desahogarse.
Posts relacionados:
- Cuánto daño han hecho… los arquitectos de software
- Desarrollar es sólo el principio
- La otra podredumbre del software
![]()
Va un post rapidito, sólo para informar de un pequeño cambio que ha introducido ASP.NET Core RC2, recientemente lanzado, relativo al nombrado de variables de entorno de sistema operativo.
Ahí van los enlaces recopilados durante la semana pasada. Espero que os resulten interesantes. :-)
Hasta ahora, con motivo de la celebración del décimo aniversario del blog, como decía un amigo del blog vía Twitter, hemos 
Seguro que os suena 
Uno de los cambios que ha introducido ASP.NET Core RC2 respecto a la anterior Release Candidate es que dejaremos de utilizar 
La 
Este post es una reedición de 
