Recientemente, leí un post que hacia una analogía del panorama del desarrollo en España. ¿Por qué el desarrollador no es la estrella? En él, se hacia una comparativa entre España y otros países (principalmente Estados Unidos).
Hollywood versus Factoría
En el país americano se comparaba la industria del software con la del cine. Allí el que trabaja a pie de obra, el programador, es la estrella y el mejor pagado, de la misma manera que lo son los actores en un película.
Sin embargo, en España, la situación se asemeja más a la de una fabrica de coches, el que trabaja a pie de obra, el que junta las piezas para crear un automóvil, el operario, es el que menos cobra y el peor considerado.
¿Por que esa diferencia? Sin duda es un poco difícil de entender y más de explicar. Creo que es de sentido común creer que un programador muy cualificado, altamente motivado y muy bien pagado es mucho más productivo que un grupo de programadores junior, sin experiencia y sin la cualificación necesaria.
Esta claro que en España se prima más la cantidad que la calidad. ¿Es ese el modelo que queremos? ¿Donde está entonces la sociedad del conocimiento y los trabajadores que la tienen que hacer posible?
Todo este modelo de desarrollo en España impacta profundamente en la TI y sobre todo en lo que se refiere al desarrollo de aplicaciones de negocio. Y desde el punto de vista de un Arquitecto TI, que tiene que definir la arquitectura de desarrollo sobre la cual los programadores tienen que «armar» sus aplicaciones ya que si nos piden que nuestros usuarios (los programadores) sean operarios sin cualificar, debemos rebajar los skills necesarios para fabricar aplicaciones al mínimo. De la misma manera que un operario de una factoría automovilística no conoce los misterios de la combustión interna en un motor diesel, los programadores no necesitarían conocer los misterios de SOA, bases de datos, algoritmos de programación, etc.
Y en esta situación ¿Que arquitectura se debe hacer entonces?
Lo primero es reconocer la realidad y enfocarnos a nuestro «público objetivo», esto es, personas con poca experiencia y poca cualificación. Y para ello tenemos que desoír los «cantos de sirenas» que provienen de Estados Unidos ya que en muchas ocasiones gran parte de las tecnologías, nuevas maneras de fabricar software, lenguajes, etc. están enfocadas a su «modelo de Hollywood» no a nuestro modelo «de factoría».
Como creo que podemos afirmar que la complejidad del desarrollo de una aplicación se mantiene constante, la única solución pasa por ocultar esta complejidad a los desarrolladores. Pero esta complejidad no desaparece, simplemente cambia de lugar. Pasa a la Arquitectura y al framework de desarrollo que se pone a disposición desde el área de Arquitectura a los desarrolladores.
El problema de los estándares
Esto nos lleva a otra reflexión. Los estándares actuales de desarrollo de aplicaciones web (y hablo de la plataforma Java que es la que conozco) es tremendamente compleja y poco productiva. Por lo tanto, no podemos confiar únicamente en su uso para el desarrollo.
Por otra parte, se supone que estos estándares están al alcance de cualquiera (con internet esto es un hecho), y que todo el mundo puede aprenderlos. Por desgracia que estén al alcance de todo el mundo no significa que sean conocidos. Para ello se necesita una cualificación que muchas veces no se tiene.
¿Que alternativa nos queda entonces? Pues yo veo únicamente dos:
- O fabricamos un recubrimiento propietario de los estándares que sea muy fácil y productivo
- O creamos herramientas generadoras de código que sean capaces de «fabricar» una gran parte del código de la aplicación
El problema del aburrimiento
Esto nos lleva a otro problema, los programadores que tienen algún interés e inquietud, se verán frustrados e incluso aburridos y desmoronados en un usar una tecnología que para ellos no ofrece ningún reto ni motivación, de la misma manera que un operario de una fabrica se puede desmotivar si durante 8 horas se dedica a apretar un tornillo del motor de un coche (ver la película Tiempos Modernos del genial Charles Chaplin).
Conclusión
¿Que hacemos entonces?:
- Tecnología propietaria que oculte los estándares
- Generadores de código
- Pensar que el usuario de nuestro producto puede ser una persona con poca experiencia y conocimientos técnicos
- Pasar del programador al analista técnico
Blog de Andrés Hevia 
19/04/2011 at 22:14
Compañero esa es la gran pregunta. Desde mi punto de vista, en la trinchera, donde este un programador cualificado, motivado y que disfrute de su profesión. Es mil veces mejor que 1000 factorías con cmmi nivel 5.
Los problemas de tiempos y retrasos estoy convencido que se terminarían.
Dudu mucho que Google o Apple, deje su negocio en manos de factorías.
Es mi opinión.
19/04/2011 at 22:52
Entonces, lo primero que hay que hacer es reivindicar la profesión de programador.
25/04/2011 at 08:49
Coincido Totalmente con Jes. Mi experiencia en trabajo con factorías me dice que la cualificación de los técnicos es mínima, y que ha de incrementarse mucho el detalle en los diseños si se quiere recibir un software de mediana calidad por parte de las factorías, amén de que las pruebas realizadas por las mismas ( y debido al desconocimiento funcional de la aplicación) aportan poco al desarrollo de la aplicación (siempre.. y repito siempre… hemos tenido que volver a realizar las pruebas unitarias del software recibido por factorías)
No obstante y dado que lo que hay es lo que hay, es decir, esto no es Hollywood X-D. Me inclino mas por los generadores de código y la utilización de estándares (cuyo conocimiento ha de ser general).
Aunque tal como comentas eso incrementa la desmotivación de los programadores.
Muy buena entrada… creo que plasmas perfectamente cual es la situación actual.
26/04/2011 at 17:02
Antes de discutir sobre factoría vs otra cosa; lo importante sería analizar las hipótesis sobre las que se basan «las grandes» compañías del sector para hacer lo que hacen.
1) Los sistemas informáticos son críticos para su negocio: lo demuestran gastando millones con un ROI muy bajo, es decir no pueden prescindir de ellos.
2) El conocimiento del negocio es crítico para crear esos sistemas: se involucran en el día a día y desarrollan los sistemas en forma interna en lugar de comprar una solución a un tercero.
3) Los sistemas se pueden crear/montar/comprar como cualquier otro bien: aplican las mismas normas y procedimientos en la contratación que a otros proveedores sin considerar si son parte crítica o no.
Bajo estas hipótesis es bastante normal lo que ocurre, sin embargo al interiorizarse en el modelo se descubren falencias y problemas debido a asumir como válidas esas hipótesis.
Analizando cada una en forma individual se observa que:
Respecto al ROI, no es bajo debido al escaso valor que proveen sino a las altas y riesgosas inversiones que realizan. Las empresas saben evaluar muy bien sus inversiones y esos sistemas sin dudas son necesarios, el problema es que le cuestan mucho.
El negocio de cada empresa es sumamente importante, y es natural e importante que fluya hacia los equipos que crean las soluciones. Sin embargo en el modelo reinante los niveles de gestión intermedia hacen grandes esfuerzos por aislar a los «constructores» de la solución de ese conocimiento y llevar todo a especificaciones, contratos y otros instrumentos poco adecuados como medio de comunicación.
La tercer hipótesis es claramente contraria por definición a las dos primeras, ¿por qué tratar como un proveedor más a alguien que provee algo crítico?
Sin embargo el más grave de los problemas surge al analizar sistémicamente, ya que los problemas se potencian al interrelacionarse. Al aflorar problemas, las acciones que se toman suelen apuntar a justificarlos o a tratar de eliminar los síntomas, nunca a tratar de solucionar los problemas de raíz. Eso nos lleva a los siguientes resultados:
– Necesidad de factorías más baratas: porque el coste de sistemas mal construidos reducen el ROI
– Más capas de gestión intermedias: porque el entendimiento no es bueno, se crean más interlocutores
– Imposición de más estándares y normas: para trasladar la responsabilidad de hacer las cosas bien y conformarse con hacer lo que se haga en forma correcta.
– Presión sobre proveedores: para sopesar aumentar las obligaciones de los mismos
Mientras no se tome la decisión de afrontar realmente los problemas solo será una danza de metodologías, estándares, normas, procesos, más testing, más contrataciones, menores sueldos, más controles, herramientas y una larga lista de decepciones.
La solución pasa por crear los sistemas de forma tal que sirvan al negocio y para eso la gente del negocio debe trabajar en forma directa con los creadores de software.
No se necesita subcontratar hordas de programadores ni toneladas de papel ni cientos de reuniones si conoces cual es tu negocio y puedes trabajar en conjunto con una empresa que sepa hacer software.