¿Y si la culpa de los errores de diseño y desarrollo no son de la tecnología que está detrás de un proyecto? ¿Y si estamos utilizando mal toda esa potencia que nos da la tecnología? Hagamos un poco de autocrítica y reflexión para intentar mejorar el sector.
El refranero español es muy sabio; tanto que casi cualquier situación, por rocambolesca que sea, podría ser representada con uno de sus refranes.
Como muestra un botón, el título alternativo de este artículo, que iba a ser "Donde fueres haz lo que vieres". Aunque pueda parecer poco o nada relacionado con el diseño web, tecnologías o técnicas punteras de desarrollo backend… ¡Vaya que lo está!
Siempre nos han enseñado que hay que amoldarse, adaptarse a los entornos a los que vamos; intentar formar parte de lo que tenemos entre manos o de la Comunidad a la que pertenecemos.
Si dibujásemos un árbol de comunidades en el ámbito tecnológico, todos los que leemos Octuweb pertenecemos a una muy grande, la del diseño y desarrollo web. En ella hay cientos de eventos, congresos, herramientas y gente.
El caso es que de un tiempo a esta parte veo cómo nos echamos piedras unos a otros, entre “sub-comunidades” (por diferenciar estas ramas del árbol que mencionaba antes).
Habitualmente aprovechando los posibles problemas que pueda tener la herramienta que utilizan unos u otros, o algún punto “débil” de la misma, criticamos no sólo la herramienta sino que dudamos de la profesionalidad de quienes la utilizan.
He leído cosas como “Si usas Bootstrap no sabes CSS”, “No eres diseñador web si no usas Sketch”, “Si usas WordPress no eres desarrollador”. Seguro que conoces estos ejemplos y podrías añadir algunos más, ¿verdad?
La herramienta no hace al profesional
Lo primero que hay que entender es que hay mercado para todos los perfiles, para todos los niveles y para todos los gustos (sí, te puede gustar más un perfil de proyecto que otro).
Lo segundo, es que hay que saber la situación o circustancia que ha llevado a utilizar según qué tecnología en un proyecto. Quizá había poco tiempo, o poca inversión, o se necesitaba destinar ese presupuesto en un pilar más que en el resto con la intención de, a posteriori, mejorar los más flojos cuando el proyecto empiece a dar frutos.
Y NO PASA NADA, seguro que el equipo profesional que está detrás hizo lo mejor que pudo, de la mejor manera posible dentro de las posibilidades y circustancias del proyecto. Que ni todos trabajamos para una multinacional, ni todos somos Tim Berners Lee.
Lo que si está claro es que en el mundo del desarrollo web la culpa no es de la tecnología, que está para ayudarnos a ser más eficientes, reducir costes o salir del paso en momentos puntuales; sino en quién la usa (más concretamente, en cómo lo hace). En este punto, lo mejor que podemos hacer es ayudar, para crear mejores profesionales.
Claro que hay tecnologías que son peores que otras (entiéndase peor hablando de lo puramente técnico; a nivel de cómo está desarrollada o cómo se implementa), pero prefiero pensar que no hay tecnología mala, sino un mal uso.
El punto al que quiero llevarte en este artículo es exactamente este.
Quizá seas el mejor programador del mundo, pero si no te adaptas a la forma de trabajar de la herramienta que estás utilizando, tu trabajo no sólo valdrá la mitad en calidad, sino que la reparación de tus errores multiplicarán y minarán el presupuesto del proyecto a medio o largo plazo.
¿Qué quiero decir con adaptarse a la forma de trabajar de la herramienta? En resumen, aprender a utilizar su API, sus guidelines, sus “normas de uso”, su forma de desarrollar.
Si hablamos de un framework estándar, estoy seguro de que tiene una documentación en la que habrá información sobre cómo trabaja, cómo se utiliza y cómo desarrollar adecuadamente con él.
Pongamos que el framework del que hablamos guarda los contenidos en una tabla de la base de datos, de una manera concreta, los metadatos en otra y los datos del autor en otra.
Si desarrollas un módulo o script para un proyecto con este framework y guardas la información en una tabla propia porque te parece que tus consultas son más óptimas que las del propio gestor, en realidad lo que estás haciendo es:
- Por un lado, estropear esa información y que no pueda ser utilizada y accesible por el resto del ecosistema.
- Por otro, y de forma más dolorosa a largo plazo, que cuando dicho framework se actualice con un cambio relevante a nivel de arquitectura, tu desarrollo deje de funcionar, implicando un sobre coste al desarrollo inicial que posiblemente el cliente no pueda asumir.
Y a ti, que eres desarrollador y sabes un montón de php, SQL y otras tecnologías, te parece que el framework en cuestión es una porquería, porque no trabaja como tu quieres. Pero… ¿te has preocupado de adaptarte a su forma de trabajar? ¿Te has informado de por qué y cómo hace las cosas?
¿El resultado? Un proyecto lento, con errores “irreparables” casi con total seguridad por falta de presupuesto, ya que se gastó en el desarrollo inicial y se tomaron malas decisiones.
Minimiza tu huella
Todos hemos hecho cosas mal, y todos hemos aprendido de errores propios y ajenos. Debemos minimizar nuestra huella, porque de ello dependerá la continuidad del proyecto.
Mi balón, mis normas, no aplica en el diseño y desarrollo web. El balón es del cliente y hay que mantenerlo no perecedero a tecnologias, aunque las utilicemos.
Que los contenidos se visualicen bien es importante para el proyecto, por supuesto. Pero que se puedan exportar, tratar, procesar, migrar… es vital.
Que las funcionalidades perduren sin necesidad de refactorización es importantísimo para la duración del proyecto. Si has desarrollado sin seguir los estándares del framework, ten por seguro que tocará refactorizar ese código en alguna actualización del mismo, porque se romperá.
Y muchas empresas que hicieron un tremendo esfuerzo para desarrollar ese proyecto, no podrán asumir el coste.
De las implicaciones en temas de seguridad hablamos otro día.