Es ya recurrente en mis posts el insistir sobre el tema de la calidad en nuestro trabajo como único recurso para crearnos de verdad un buen currículum y una buena carta de presentación.

Aunque la calidad no deja de ser un concepto demasiado interpretable, en software viene a ser equivalente a que el sistema o aplicación que se entrega funciona según los requerimientos del cliente y, por supuesto, que no tenga fallos, que sea fácil de mantener, evolucionable, etc. Esto a mí me parece evidente aunque no siempre se tiene en cuenta en el día a día de un desarrollador.

Ahora bien, no siempre se ve claramente la relación entre la gestión de un proyecto software y el resultado final de este. En mi opinión no sólo es importante sino también determinante.

Desarrollar software no es sentarte ante un ordenador y pasarlo bien escribiendo líneas de código (bueno, también, pero lo que quiero decir es que no sólo es eso). Cuando tenemos que entregar algo para una fecha determinada, hay que planificar, cuando trabajamos en equipo las tareas hay que repartirlas coherentemente, o sea, hay que gestionar la carga de trabajo, cuando se ponen las bases de un nuevo sistema hay que tomar decisiones de diseño y antes de todo eso hay que tomar, interpretar y traducir al lenguaje del desarrollador las especificaciones de un cliente que en ocasiones no tiene del todo claro lo que quiere o necesita.

Todos esos puntos no son más que la punta del iceberg y absolutamente todos están relacionados con la gestión de un proyecto software, sin hablar de la responsabilidad que conlleva ya que ciertas malas decisiones pueden tener efectos catastróficos.

Ingenuamente hay quien piensa que eso de gestionar consiste en ordenar mandar lo que otros tienen que hacer para sentarnos cómodamente a esperar que las cosas se hagan solas porque sí. Bajo esa concepción, el desastre de un proyecto software está asegurado.

Aunque hay tantas particularidades como proyectos y puesto que un proyecto de software tiene su propia idiosincrasia, básicamente cuando alguien se enfrenta a la gestión por primera vez no tiene una idea clara de lo que se espera de él.

Este verano me pidieron que evaluara una sencilla tienda online para estimar el coste y esfuerzo necesarios para añadirle nuevas características (y corregir de paso algunos detalles que no funcionaban bien) y, para mi sorpresa, me encontré con algo que es habitual en nuestro sector: aplicaciones que están mal planteadas, mal hechas, escritas de cualquier forma, a pesar de que con ella el cliente final había facturado en el último año más de veinte mil euros en pedidos.

Es ya recurrente el siguiente ejemplo: cuando compramos un coche nos interesamos por muchos de sus acabados, prestaciones y, cómo no, detalles de su mecánica interna (fabricante del motor, etc); del mismo modo para la construcción de una casa se necesita la firma de un arquitecto colegiado (al menos en España) cuya función se supone que es la de supervisar todos los aspectos técnicos de la construcción.

Me pregunto entonces por qué para un proyecto software a casi ningún cliente se le ocurre preguntar o preocuparse por la calidad del proyecto que se le entrega, sin saber en realidad que según esa calidad, el coste de evolucionar o mejorar en el futuro la aplicación será asequible y razonable o desorbitado (cuando no se termina por tirar el sistema a la basura y realizar otro de nuevo desde cero).

De este modo, en muchísimos casos en nuestra profesión, para clientes de pequeño tamaño, medianos o grandes corporaciones, se entregan aplicaciones que en realidad son una manzana envenenada que explotará más adelante en cuanto el cliente necesite modificaciones o cambios, que es lo normal para casi cualquier tipo de software.

¿Compraríamos un coche que no se puede reparar o mantener? Absurdo.

Me planteo varias preguntas en relación a esto. ¿Cómo demostrarle a un cliente la calidad del software que se le entrega?

¿Cómo destacarnos de los competidores garantizando al cliente que nuestra solución va a ser más mantenible ante cambios? Este es un tema que da para mucho y es uno de esos asuntos recurrentes con los que nos encontramos día sí, día no.

¿Estaría el cliente dispuesto a un mayor coste si se le garantiza mejor calidad interna en lo que se le ofrece? ¿Tendrían sentido auditorías externas de calidad para poder dar un producto por terminado con su correcto certificado acreditado de calidad software? Vale, sí, sé que exiten auditorías así y que se suelen usar en grandes proyectos para grandes compañías pero eso es una gota en el océano.

En el caso que comentaba al principio, un simple vistazo a la estructura de la aplicación me hacía temer lo peor...

Quizá estamos pasando una época en la que el mismo concepto de éxito se está redefiniendo de una manera totalmente distinta. Hasta hace bien poco, se consideraba una persona de éxito aquella que económicamente ha conseguido reunir una gran fortuna o patrimonio (sin importar la forma), una empresa de éxito aquella que ha crecido con dos dígitos porcentuales de año en año (sin importar la satisfacción laboral de sus ejecutivos, empleados y clientes), una familia de éxito aquella que vive rodeada de comodidades y maravillosas vacaciones en hoteles con todo incluido (sin importar tampoco la falta de conexión entre sus miembros), por poner algunos ejemplos. Al mismo tiempo el downshifting laboral comienza a ser un fenómeno cada vez más común.

¿Y qué demonios tiene esto que ver con el desarrollo de software?

Como en cualquier otra actividad profesional proyectamos en ella muchos defectos y virtudes que heredamos de nuestra vida diaria, aunque la relación no la veamos directamente.

Recientemente El Libro Negro del Programador ha recibido un comentario bastante elogioso desde Amazon.com y que, con permiso de su autor (al que agradezco profundamente), copio y pego a continuación:

"Lectura indispensable para los que nos dedicamos a la programación porque trata temas esenciales en cuanto a la productividad, la eficiencia, la calidad del software y el manejo del tiempo. La gran ventaja de este libro es que no es un libro mas sobre teoría de la ingeniería de software, sino que el autor aporta la gran experiencia que tiene y acierta en la solución los problemas a los que nos enfrentamos los desarrolladores a la hora de afrontar proyectos de desarrollo, explica con detalle cuáles son las malas prácticas que llevan al fracaso de los proyectos y plantea soluciones efectivas. Un punto clave que platea el autor es la importancia de nuestra profesión en el contexto actual mostrando las ventajas de ser un buen profesional del desarrollo, estas ventajas las muestra presentando un panorama muy positivo con grandes expectativas en el entorno productivo."

Para mí que el éxito se tiende erróneamente a asociar más al efecto que a la causa que lo provoca y de ahí que cometamos recurrentemente el error de embarcarnos en un proyecto sólo por su remuneración económica (vale, vale, ya sé que la pasta es importante, pero ni mucho menos es lo único), o ser amable con alguien para conseguir algo de esa persona, o apuntarnos a un intenso programa de ejercicio para adelgazar esos kilos de más, etc.

Reconozco que siempre he estado muy interesado en el desarrollo web y, de hecho, hice mis primeras aproximaciones a título personal allá por el 2006 hasta caer en los brazos del magnífico Drupal con el que comencé una start-up (que, como tantas, no terminó de cuajar). Aunque dirijo un grupo de desarrollo como responsabilidad principal en la compañía para la que trabajo, mantengo como uno de mis mantras eso de no desvincularme nunca de la fontanería y conceptos de bajo nivel del desarrollo de software. ¿Cómo si no se puede gestionar un proyecto software si no se conocen con total profundidad los building blocks que lo constituyen? Se puede dirigir, claro, pero entonces el riesgo de tomar malas deciciones, incurrir en desviaciones, etc. será mucho mayor. De esta forma, he seguido siempre de cerca ciertas tendencias, inciativas que han perdurado y otras que cayeron en desuso relacionadas con el mundo web, aún dedicándome casi siempre a realizar aplicaciones pesadas con tecnologías .NET, fundamentalmente.

Cuando decimos que la economía se está moviendo a lo digital, a veces no captamos las implicaciones enormes que tiene esto para un desarrollador profesional de software: significa que se están volcando recursos económicos de manera masiva a la implantación de proyectos empresariales y negocios en Internet y, por tanto, la demanda de buenos profesionales con expertise demostrable será cada vez mayor.

Quedan muy atrás aquellas webs de los noventa casi anecdóticas que apenas eran folletos publicitarios: ahora hablamos de una verdadera industria, desde hace años, que está cambiando el modo en que nos relacionamos y el modo en cómo la tecnología modifica hábitos sociales, como por ejemplo el concepto de economy sharing.

Hay mucho escrito sobre MEAN, de modo que me voy a centrar en las auténticas razones por las que para mí a un desarrollador que conozca bien este stack no le va a faltar trabajo en los próximos años.

Cuando nos enfrentamos a un nuevo tipo de proyecto en el que vamos a usar tecnologías que no dominamos del todo o es la primera vez que las usamos en un proyecto profesional, suele ser un error que tu primer proyecto con esas tecnologías sea precisamente el que vas a entregar a un cliente; este, sin saberlo, va a ser un conejillo de indias del proveedor que decide con acierto o no los mejores frameworks y librerías para ese tipo de proyecto, si es que esta evaluación se ha llegado a hacer.

Lo peor se presenta cuando quien decide usar un stack de tecnologías en concreto lo hace no porque se ajuste a ese proyecto en particular, objetivamente, dada su naturaleza, sino por sencillo capricho y porque se presenta así una oportunidad maravillosa de aprender en el trabajo sobre aquello que fuera de él no se tiene tiempo... Esto lo he visto varias veces y es una tentación demasiado grande como para no hablar de ello; igualmente, quien cae en esa tentación se podrá considerar desarrollador de software, pero desde luego no profesional. En ocasiones, los desarrolladores de software parece que juegan en su trabajo en lugar de buscar realizarlo con la mayor profesionalidad posible.

No hace mucho he leído en un libro sobre AngularJS la siguiente sendencia, aplastante e ilustrativa:

"Software development is hard. As developers, we need to juggle customer requirements and pressure of deadlines, work effectively with other team members, and all this while being proficient with multitude of software development tools and programing languages. As the complexity of software rises so is the number of bugs. We are all human and we will make mistakes, tons of them. Lower-level, programming errors are only one type of defect that we need to constantly fight. Installation, configuration and integration issues will also plague any non-trivial project."

(Mastering Web Application Development with AngularJS)

No lo habría podido expresar mejor: durante el desarrollo de cualquier proyecto, una de las tareas a las que nos dedicamos es a desarrollar nuevo código de producción, pero esta es una tarea más; al mismo tiempo se realizan muchas otras tareas relacionadas con el proyecto pero igualmente importantes. No obstante, en ocasiones se trivializa la importancia de esas otras tareas pensando que poco tienen que ver con el proyecto y que en realidad lastran el escribir nuevo código; porque lo divertido, lo que más nos gusta a los desarrolladores de software es "escribir código", ¿no es así?

Eso podría pensar una mente ingenua recién llegada a un sector en el que mirar hacia atrás varios años es ver la prehistoria por una renovación continua de nuevas tecnologías, flujos de trabajo y, por qué no, incluso nuevos tipos de proyecto.

Con la irrupción de los smartphones y tablets de los últimos años y el paso acelerado de parte de la economía tangible a la economía digital, el desarrollo web se ha visto tremendamente fragmentado, sectorizado y disperso en un conjunto cada vez mayor de tecnologías heterogéneas. No es raro que cualquiera que se acerque por primera vez a la programación web sienta cierto vértigo al decidir qué herramientas usar, qué tecnologías emplear. Aquí hay que hacer un auto de fe que en ocasiones te lleva a estudiar a fondo los frameworks más de moda con el riesgo que esto supone.

Muy lejos queda cuando alguien era capaz de definirse como maquetador web o web master (sólo pensar en estos conceptos trasnochados me chirrían los oídos), aunque no es raro que aún se incluyan esos términos en algunos currículums... El panorama ha cambiado radicalmente y ha evolucionado tanto que la industria ahora bendice todo lo que suene a estándar o tecnología no propietaria.

Hoy es tal la cantidad de opciones disponibles para comenzar un nuevo proyecto web que es tremendamente difícil acertar en las más adecuadas dada las características del proyecto. Algunas preguntas recurrentes suelen ser:

  • ¿Me baso en un CMS flexible como Drupal?
  • ¿Lo hago desde cero (...)?
  • ¿Diseño mobile first o desktop first?
  • ¿Evolucionará el proyecto mucho, poco o nada en el futuro?

... y esto si no caemos en el error que querer usar porque sí las tecnologías que más conocemos y que más cómodas nos resultan (por eso de evitar salir de nuestra zona de confort).

Ya el concepto de programador web tiene poco contenido, al menos a mí me dice más bien poco: ¿especialista en front-end, en back-end, en despliegue de infraestructura, en diseño, en usabilidad, SEO, etc.? Me temo que no todo el mundo puede ser excelente en todas esas áreas, de ahí la fragmentación y la realidad ineluctable para la que un proyecto más o menos extenso tenga que contar con perfiles diferenciados.

¿Somos los mejores profesionales que podríamos llegar a ser?

¿Aportamos valor realmente a la compañía para la que trabajamos o a los clientes que nos pagan los honorarios? ¿o nos limitamos a hacer lo que nos dicen y nada más y no sabemos tomar la iniciativa en ningún asunto?

Se usa a menudo la expresión aportar valor pero en la mayoría de las ocasiones sólo queda como un simple titular de promoción interna en los departamentos de recursos humanos. Queda muy bien, pero realmente no se cambia absolutamente nada para que exista una cultura corporativa que promueva el valor, el talento y la proactividad. Veo demasiada gente hablando de proactividad pero actuando muy poco proactivamente: decimos una cosa pero después hacemos otra totalmente distinta. A mí esto me suena al principo de la locura.

No sabremos aportar valor en nuestro entorno si no invertimos en nosotros mismos. Es, de hecho, la mejor inversión que podemos hacer.

Desde hace unos años participo en cierta medida en asuntos comerciales además de mi dedicación casi completa a dirigir un equipo de desarrollo, involucrándome, cómo no, en todo tipo de tareas técnicas, decisiones de diseño y arquitectura, toma de feedback de clientes, etc.

En este tiempo me ha llamado mucho la atención cómo bastantes clientes pontenciales de los productos que comercializamos se interesan por conocer el motor de base de datos que usa nuestro software. Los hay quienes le dan todas las bendiciones a SQL Server, otros que no cambiarían Oracle por SQL Server y unos pocos que nos han preguntado si el sistema podría funcionar con Cassandra (...). Nada que objetar, salvo su percepción completamente errónea de que el producto va a ser rápido y eficiente o lento y poco escalable según la base de datos que use, nada más.

Esta suposición, entendible para cierto perfil no técnico, la he visto también en otro tipo de perfiles muy técnicos y entendidos en software, para mi asombro.

Quizá nos han educado para buscar un empleo del que vivir, trabajar en algo con lo que ganarnos la vida y pagar las facturas a final de mes. Quizá, digo, no pusieron durante nuestra educación el énfasis necesario para que siempre busquemos trabajar en algo que no sólo nos guste, sino que nos apasione. Otra cosa distinta es que eso mismo lo busquemos como empleado o como empleador, aunque lo que aquí quiero recalcar es que la excelencia, la calidad, siempre surge cuando amamos lo que hacemos con una intensidad superior al resto de nuestras obligaciones.

No existe ningún trabajo en el que todas las tareas que tienes que realizar sean siempre gratas; para conseguir un objetivo final, un proyecto con resultados, hay que hacer muchas cosas diferentes, unas nos pueden gustar más, otras menos, pero si cuando terminamos el proyecto, dando paso a una nueva fase en él o comenzando otro completamente nuevo, no sentimos cierta satisfacción, orgullo personal o una sencilla alegría por haber terminado algo con calidad y lo mejor posible dadas las circunstancias, entonces es que no estamos dedicando nuestra vida laboral a lo que realmente nos apasiona.

En software esto tiene un impacto enorme, aunque no siempre nos damos cuenta de las consecuencias desastrosas que esto tiene para la ejecución con éxito de un proyecto.

Páginas

¿Por qué leer El Libro Negro del Programador?

Adquirir desde:
Amazon (kindle eBook / papel)
CreateSpace (papel)
PayHip (epub / mobi / pdf)

El libro negro del programador.com
Segunda Edición - 2017

Archivo

Trabajo en...