Wednesday, March 13, 2019, 10:51 AM
Quienes se dedican al desarrollo de software conocen bien los conceptos de abstracción, analogía y metáfora. Entienden la necesidad de eliminar lo superfluo y quedarse con lo esencial, así como el poder que tienen las buenas analogías (y metáforas) para ayudar a entender y utilizar artefactos complejos.
También conocen de sobra la manida analogía entre desarrollo de software y construcción (manida al menos aquí en España) según la cual en el desarrollo del software (al igual que en el mundo de la construcción) hay quienes trabajan en planos de abstracción elevados (y bien remunerados) frente a quienes trabajan en planos mucho más concretos (y peor remunerados). Esa analogía compara a distintos profesionales del software con arquitectos, arquitectos técnicos, capataces y albañiles, y haciéndolo minusvalora el trabajo de algunos (casi siempre los albañiles/programadores) señalando que hacen tan solo lo que se les manda y que se limitan a "poner ladrillos" o "picar código".
Esa analogía es tremendamente perniciosa.
Dejando a un lado el tufo clasista (que ya es un demérito importante) lo cierto es que ignora la realidad tanto del mundo de la construcción como del desarrollo de software: ni los albañiles se limitan a poner ladrillos y hacer lo que les mandan ni "picar código" es una actividad desprovista de esfuerzo intelectual.
Además, mientras que nadie espera que un albañil haga las tareas de un arquitecto (ni un arquitecto las de un albañil), es de esperar que quien comienza "picando código" evolucione en su carrera hasta tareas más alejadas del código y más próximas a gestión de equipos y proyectos.
Por último, el hecho de presentar una estructura jerárquica tan rígida (casi un sistema de castas) se corre el riesgo de que muchas personas consideren que no tienen un puesto acorde a su titulación además de que se minusvalore el trabajo de quienes "sólo" programan.
Por todos esos motivos deberíamos abandonar de una vez por todas el símil de la construcción en el desarrollo de software. En su lugar propongo que usemos el de la restauración en su sentido de "Actividad de quien tiene o explota un restaurante". Obsérvese, además, que indico restauración y no simplemente cocinar, veamos por qué.
Si el desarrollo de software se plantea como análogo a la restauración parece claro que el objetivo de los distintos planes de estudio conducentes a títulos formativos, de grado y máster en informática sería formar a personas que puedan trabajar en un restaurante, dirigirlo o incluso montar su propio restaurante.
Está claro que muchxs de lxs egresadxs querrán ser chefs justo al terminar sus estudios pero también está claro que sin experiencia previa eso es poco menos que imposible (salvo en una empresa, quiero decir, restaurante muy pequeño o muy nuevo).
Todxs esxs tituladxs deben conformarse inicialmente con tareas poco glamurosas dentro del restaurante y, al menos al principio, seguirán instrucciones de profesionales con más experiencia. Sin embargo, gradualmente, según ganen experiencia también irán ganando en autonomía y recibirán tareas de mayor responsabilidad.
Al igual que en el desarrollo de software, las tareas de mayor responsabilidad tienen poco que ver con cocinar/programar. Tienen que ver con gestionar equipos, tratar con clientes, proveedores, inversores, tomar decisiones que afectan al negocio, etc. Pero eso no significa que la cocina no sea importante, la cocina (el desarrollo de software) sigue siendo la actividad primaria pero para que ésta pueda llevarse a cabo de manera eficiente, a escala y con un rendimiento económico hay que saber hacer muchas más cosas que simplemente cocinar/programar.
¿Significa eso que el chef ya no cocina/programa? Por supuesto que no, significa que su tiempo es más valioso si se dedica a otras tareas pero siempre tiene como objetivo producir a escala una cocina de la mayor calidad y, si el caso lo requiriera, siempre podría aproximarse a alguien novel y enseñarle un truco de cocina o dos.
Tan sólo con estos ejemplos debería quedar claro que la restauración es una metáfora mucho más útil sobre desarrollo de software que la construcción pero aún ofrece algunas ventajas más.
Dije que el desarrollo de software es como la restauración pero no como la cocina. ¿Por qué? Porque aunque mucha gente puede cocinar razonablemente bien no todo el mundo puede llevar un restaurante. El típico sobrino que cocina/programa muy bien puede servir para un apaño artesanal pero no para un desarrollo profesional (no le encargarías el cátering de una boda, por ejemplo). Y sí, está muy bien intentar que todo el mundo cocine/programe desde edades tempranas pero eso no significa que en el futuro vayan a ser chefs/desarrolladorxs de software de manera profesional.
En resumen, sí, en desarrollo de software hay roles claros pero no es un sistema de castas inmutable y no hay nada indigno en picar código/cocinar (como no lo hay en ser albañil).
(Puedes encontrarme en Twitter como
@PFCdgayo)
Back Next
uniovi.es
