La pregunta que se hace allí es: los desarrolladores son (somos) artesanos, operarios o ingenieros?. O dicho de otra manera, la mejor manera de pensar el desarrollo de software es con desarrolladores que hacen lo que les dicen traduciendo ‘algo’ a código (operarios donde la productividad está ligada al tiempo empleado en la tarea), con desarrolladores concentrados en los detalles y en el pulido de su trabajo utilizando una experiencia poco formalizada o ingenieros, que usan tecnología y se nutren del conocimiento científico para construir algo que antes no existía con un montón de objetivos en mente (muchos de ellos contradictorios)?.
Yo encuentro importante la búsqueda de metáforas, pero no puedo evitar sentir cierta incomodidad cuando escucho cosas del estilo de “en nuestra actividad, a diferencia de la actividad de los ingenieros civiles, tenemos un entorno cambiante”, “nosotros lidiamos con el cambio constantemente, no como los médicos: a ellos no les sale un órgano nuevo cada año”. Las frases anteriores son ejemplos de dos extremos que encuentro cuando escucho las metáforas que comparan nuestra actividad con otras: la primera frase es razonable y la segunda profundamente estúpida e ignorante. Aún con las que considero buenos metáforas, no puedo evitar la incomodidad que me causa ver que quienes se ponen a desarrollar isomorfismos usualmente conocen uno solo de los conjuntos (no es el caso de Juan G. que es ingeniero de los de verdad, no informático).
Yo creo que la metáfora del operario se ha demostrado inútil: la productividad no está asociada a la cantidad de tiempo. Además (y esto puede que sea un problema mío) encuentro terriblemente difícil separar las actividades de diseño y programación. No digo que tenga que programar hasta el último detalle para diseñar, pero si no tengo feedback rápido de un diseño, no me sale bien (y no recuerdo conocer a alguien que sí le salga bien). Eso, emho, hace un poco complicado aplicar las ideas de ese simpático cuáquero en nuestra actividad.
Soy menos terminante en cuanto a la metáfora ingenieril: no diré que los ingenieros civiles no se enfrentan con una forma de construcción nueva cada año entre otras cosas porque trato de no confundir marketing con ciencia (o aunque sea tecnología), pero pienso en dos cosas muy particulares de nuestra actividad:
• Es muy difícil imaginarse el producto terminado
• Hay una percepción (creo yo que con bases en la realidad) de que el software es fácil de cambiar. Ante un error en un puente, se lo usa como está (o no se lo usa) en cambio el software siempre parece fácil de cambiar.
• La naturaleza maleable del asunto hace que quienes tengamos ese ‘problemita’ de no poder diseñar sin construir no seamos inútiles completos.
El modelo de ‘operarios’ de una ‘software factory’ aporta poco valor, en eso estamos de acuerdo. Ahora, que hay del modelo ingenieril?. Yo diría (lo sufrí en la facultad) que es alejado de la realidad, algo inútil y de un optimismo bastante nabo e irritante. Así las cosas, si bien nos vendrían bien las metáforas dudo en encontrar alguna. Que somos? Ingenieros, artesanos o la reserva moral de la organización? (supongo que si hay algún lector joven se perderá la última referencia). Que el enfoque de 'trabajadores del conocimiento'? Y si vemos a que nos parecemos después de pensar cuales debieran ser nuestros valores?
Nota de un par de días después: Debido a algún problemita que arrastro desde mi más tierna infancia que me impide manejar medianamente bien cualquier tecnología que tenga que ver con la presentación de contenidos, he cometido algún error que hizo que blogger (que tampoco es the ultimate editor, admitamoslo) se comiera los saltos de línea.
2 comments:
"alejado de la realidad, algo inútil y de un optimismo bastante nabo e irritante..."
Es buenísima la frase, todavía me estoy riendo.
Ahora en serio, tienes razón. Creo que puestos a elaborar una simple lista de "lo que deberíamos ser" comenzaríamos a las trompadas en breves instantes.
Ok, el link y las frases referenciadas al final son muy lindas. ¿Pero un profesional independiente que trabaja en solitario no es un informático? ¿Y si mi cliente no quiere que sea su "partenrship", hago el programa en dos o tres trazos gruesos y se lo vendo cerrado (previa verificación de su parte) y sin mantenimiento está mal?
El desarrollo de software es una herramienta tan omnipresente que es difícil de definir per sé. Sería como tratar de englobar en una profesión a toda la gente que usa un martillo en su trabajo.
Tenemos ingenieros navales, civiles, electrónicos, nucleares... y por otro lado programadores, peléandose los que desarrollan el código de control del lavarropas con los que hacen páginas web por la propiedad de la palabrita.
Y así y todo "algo hay", porque al menos intuitivamente todos nos reconocemos y nos diferenciamos del resto. ¿Qué somos? (insultos aparte) Ni idea, me gusta más lo de artesanos, pero es sólo por elegir algo del menú.
A mí me gusta lo de reserva moral de la compañía por citar a mi finado amigo E.
Bromas al margen, me gustaría detenerme en dos puntos. Cuando mencionás al fulano que trabaja solo creo que es por oposición al punto del manifiesto donde habla de la comunidad de profesionales. Yo no creo que se oponga, entiendo que el manifiesto habla de que es imposible ser un buen profesional aislado del entorno y de la comunidad (creo que compartimos eso, por eso tenemos blogs, y estamos en este intercambio). A mí me recuerda a 'aislacionismo y desarrollo'.
Con respecto al partnership, lo veo uno de los puntos menos claros del manifiesto. Lo puedo entender como una invocación a apostar a una relación cliente/proveedor donde ambos se benefician, pero 'partnership' (tal vez gracias a los marketineros que todo lo corrompen) me parece una de las palabras más vacías que he escuchado.
Post a Comment