A lo largo de esta web así como de El Libro Negro del Programador, se insiste mucho acerca de la necesidad de que una solución software sea mantenible. Es más, si no es mantenible fácilmente, el proyecto puede ser todo un fracaso y traerá consigo un cliente muy cabreado y enojado (que seguramente nunca volverá a confiar en ti) o una compañía que tiene un agujero económico que cubrir.

No se hace software para que funcione ahora, sino para que pueda ser evolucionado y matenido fácilmente con el tiempo. Esto para mí es un mantra que repito y un principio irrenunciable.

Mantener un proyecto software en producción es en definitiva conocer cómo se comporta, tener identificadas claramente las actividades de mantenimiento, poder detectar con sencillez dónde ocurren los problemas pero, sobre todo, tener la capacidad de hacer todo eso de manera eficiente y en poco tiempo.

Administrar, por su parte, está relacionado con lo anterior y es igualmente importante: si la administración de cualquier producto software es ineficiente, estaremos poniendo en peligro su viabilidad en producción.

Por muy bien que funcione aparentemente nuestro proyecto, si este no se puede ni mantener ni administrar correcta y eficientemente, habremos realizado en realidad un proyecto más bien pobre. Para que un software sea mantenible y administrable tiene que desarrollarse desde el principio pensando en su sencillez de mantenimiento y administración.

Realizando recientemente algunas actividades de mantenimiento de la web de la compañía en la que dirijo proyectos software, volví a tener presente este carácter intrínseco tan importante del desarrollo. La web está montada en Drupal y se tenían que actualizar algunos módulos desde hacía algún tiempo. A los que me conocen no les extraña en absoluto que dirija la realización de proyectos software al mismo tiempo que me meto de lleno es aspectos de desarrollo de bajo nivel, ¿acaso se puede dirigir algo sin conocerlo suficientemente?

Idea Concetp Development ProductDurante mis primeros años como desarrollador de software tuve la enorme suerte de participar en un equipo que estaba dedicado íntegramente al desarrollo de un producto. Incluso teníamos quienes se dedicaban exclusivamente a escribir pruebas (lo que era un auténtico lujo). Hace tiempo de eso y aunque usábamos tecnologías ahora obsoletas o de menos uso (Visual C++, ActiveX, COM, DCOM, etc), la dinámica para la creación de un producto software no ha cambiado en absoluto, aunque desde entonces he abrazado el desarrollo ágil como mejor forma de realizar software.

Estos dos últimos años, sin ir más lejos, me he dedicado íntegramente a dirigir un equipo de desarrollo para la creación de un producto software muy específico para compañías del sector eléctrico. Han sido dos años muy duros en los que hemos escrito muchísimo código, hemos sacado unas cuatro versiones comerciales del producto con éxito (con clientes consolidados) y hemos tenido siempre presente la necesidad de refactorizar, de esforzarnos por mejorar y ampliar las pruebas, de escribir una documentación de despliegue correcta y mantener una gestión de la configuración eficiente. Nada es perfecto, pero el resultado, en mi opinión, me indica que hemos hecho las cosas aceptablemente bien.

Programar algo que funcione es relativamente fácil, crear un proyecto muy particular para un cliente requiere de algunas habilidades más, hacer un proyecto similar pero de mayor tamaño con un equipo de varias personas añade un nuevo nivel de dificultad pero, sobre todo, realizar un producto software que sea válido no para uno sino para cientos de clientes distintos, es otro nivel completamente distinto que requiere de una dinámica muy diferente a la del trabajo en un proyecto particular.

Hay muchas diferencias técnicas y de gestión entre uno y otro escenario y no siempre se distinguen claramente.

Han pasado varios meses desde que se publicó oficialmente El Libro Negro del Programador después de año y medio trabajando en este proyecto. Desde entonces he recibido muchos comentarios, la mayoría afortunadamente positivos (algunos también no tan positivos); en general, todo me hace pensar que los desarrolladores de software nos quejamos casi siempre por las mismas razones independientemente de dónde realicemos nuestra actividad (Chile, Venezuela, Brasil, España, USA, etc.) y que la manera de entender el desarrollo de software desde el mundo corporativo viene a ser muy similar en casi cualquier parte. Cuanto más grande sea la empresa y su nombre se parezca más a "Consultoría de servicios IT", más se pierde el carácter de artesanía (craftmanship) en el trabajo que se realiza, lamentablemente.

En cualquier proyecto siempre se aprende algo, en ocasiones muchísimo, todo depende de la actitud que afrontemos durante el mismo. Incluso si repetimos el mismo tipo de proyecto, siempre podemos encontrar mejores formas de hacer las cosas, por tanto, el que sepamos aprender y mejorar más o menos depende directamente de nuestra actitud.

Sólo mejoramos si tenemos una motivación interna para ello, nadie, ni nuestro jefe, ni nuestros compañeros, ni nuestra empresa, etc. nos va a hacer mejorar profesionalmente si antes no tenemos esa predisposición. 

Creo que el mejor valor que podemos aportar a nuestra organización es el de mantener siempre una actitud de aprendizaje y adaptacíon continuos y esto se debería apreciar y tener en cuenta en los departamentos de recursos humanos.

Mientras le daba forma al libro fui poniendo por escrito muchas gemas de sabiduría que quería compartir; al mismo tiempo, se asentaban en mí ciertas ideas al tiempo que profundizaba en otras. Escribir un libro es ya en sí mismo toda una lección de humildad y cada capítulo te pone a prueba.

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.

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...

Mis novelas...