"Escribir libros o artículos no sirve en la empresa"

Desanimar constantemente a aquellos que trabajan en la empresa y pretenden, y les gusta, escribir y publicar en revistas, libros o incluso blogs, es algo que aún caracterizan a la industria de la España profunda del desarrollo software. Por desgracia, muchas cosas similares se escuchaban muy frecuentemente en mis primeros años trabajando en consultoría, donde aún más que ahora todo aquello que no fuese tirar líneas de código sin control hasta las tantas era… teórico. Y de ahí que a quienes decían estas cosas les daba igual lo que hubieses estudiado, leído, escrito, pensado, etc., todo eso eran teorías, “tu pica código”. Eso sí, lo que no hay duda que no era teórico eran luego las explosiones en producción, los retrasos de años, perder los fuentes, la gente huyendo de ciertas empresas, etc.
Como hay quien dice que si estás en una empresa tienes que olvidarte de escribir, “que eso es de teóricos y no ta va a ayudar en tu carrera profesional”, pensé que, si eso es así, seguramente los mejores libros de ingeniería y gestión de proyectos software no habrían sido escritos por gente de empresa. Aunque para corroborarlo quise revisar la lista de buenos libros escritos en ingeniería software, en la que, con “total seguridad”, encontraría que los autores serían unos teóricos con nula relación con la empresa. Y revisando sus currículums…
– Steve McConnell, que escribió Rapid Development, uno de los libros más vendidos en ingeniería software, lleva en la empresa desde el 84, y tiene una consultora que se llama Construx Software. No parece ajeno a la empresa. Será una excepción, seguro.
– Erich Gamma, escribió Design Patterns, trabaja en IBM, fue uno de los desarrolladores de JUnit y de Eclipse. Este, aunque escribiera uno de los libros más importantes de diseño software, tampoco parece teórico. También puede ser una excepción.
– Bertrand Meyer, Object-Oriented Software Construction, sí, en este caso sí, trabaja como profesor en un instituto tecnológico, y no en una empresa, lo que no quiere decir que sea “teórico” pero que seguro puede generar dudas.
– Brooks, The Mythical Man-Month, uno de los libros más importantes de gestión de proyectos… vaya, también es de empresa, dirigió nada menos que el desarrollo del sistema operativo OS/360 de IBM. Bueno, aun quedan autores, esto aun no ha terminado.
– Martin Fowler, que tienen numerosos libros importantes, trabaja en una empresa de consultoría llamada ThoughtWorks. Un consultor que ha escrito muchos libros.
– Kent Beck, Extreme Programming Explained entre otros, trabaja en Three Rivers Institute, desde donde da servicios de consultoría.
– Alistair Cockburn, tiene 3 libros premiados en los Jolt y se dedica a la consultoría.
– Berczuk y Brad Appleton, entre otros Software Configuration Management Patterns. A ver qué tal: Brad Appleton es ingeniero software en Motorola, vaya este también es de empresa, y Berczuk se dedica a la consultoría.
– Doug Rosenberg, Use Case Driven Object Modeling with UML, trabaja en una empresa de consultoría que se llama ICONIX.
Aquella frase de “no escribáis que eso es de teóricos” la escuché hace años a varios directores y responsables en empresas de desarrollo software. Y lo peor es que hace poco alguien me contaba que también se lo habían dicho. E incluso… también he escuchado esta frase a jóvenes ingenieros software que acaban de empezar a trabajar y piensan que escribir no les ayudará en su evolución profesional, que eso es cosa de Universidades.
Que se escriban muchas cosas teóricas, no implica que escribir sea de teóricos o que todo lo que se escribe con teorías. Es más, la mayoría de los “gurús” de la ingeniería del software que trabajan en la empresa se caracterizan por una alta cantidad y calidad de artículos, libros publicados y más recientemente post en blogs. Escribir les ha dado fama, les ha permitido ser identificados como “gurús”, popularizar sus ideas y experiencia, y promocionar sus empresas.