Aunque la tecnología permite esto de las conexiones 3G desde la playa, las vacaciones mentales hace que cueste ponerse ante el ordenador a escribir cosas medianamente bien razonadas.
Pero las pachanguitas en la playa y un post de yuki en el que citaba a un "programador terrorista" me han hecho recordarle, a él y a Romario. Y es que este programador era un "Romario": brillante pero poco estructurado. Recuerdo especialmente una pantalla que desarrollo en Clipper con un modo de funcionamiento similar al de la programación orientada a eventos de VisualBasic 3 (era lo que había). Espectacular, cada celda recalculaba toda la pantalla, con independencia del orden. Esto, que suena elemental, era bastante complicado en lenguajes de modo carácter. Brillante.
Pero el día que la pantalla falló, él no estaba. Y ninguno de los del equipo era capaz no ya de encontrar el error sino de simplemente entender como estaba desarrollada.
De ahí la duda de si es mejor tener un equipo de programadores estructurados, que siguen los estándares y aseguran un rendimiento aceptable del equipo (unos Makeleles) o es mejor tener Romarios, brillantes pero imprevisibles.
Posiblemente, este post está afectado por un exceso de exposición al sol, pero no me apetecía dejarlo pasar hasta la vuelta.

20 jul 2008 | 01:58 PM
No señor, no creo que tengas la cabeza recalentada :) Más bien creo que tienes preocupación por el desempeño de tu equipo humano y una buena dosis de autoconciencia: te preguntas ¿cuál es la mejor forma de organizar mi organización? en lugar de ¿cuál es la que más me gusta? o ¿cuál es la que más me conviene?
Personalmente, opino que si queremos convertir el desarrollo software en una industria, debemos fomentar los hábitos industriales. El problema, es que primar esta estrategia tiene un coste: lastra la creatividad (que también es importante, sobre todo cuando las metodologías no están maduras) y puede frustar a los desarrolladores que priman el lado izquierdo de su cerebro (¿o era el derecho?).
Además, hay un factor nuevo que hay que tener en cuenta: algunos artículos, ya han dado un toque de atención sobre las nuevas generaciones que ahora acuden al mercado laboral y su falta de costumbre de disciplina (espero que sea un tópico "cualquier generación pasada fue mejor y no un hecho)
20 jul 2008 | 04:04 PM
Yo lo tengo claro, en el 90% de los casos prefiero Makeleles ya que proporcionan fiabildad, previsibilidad, mantenibilidad,..., y sólo en un 10% me quedo con los Romarios, es decir, cuando hay proyectos en los que innovación y la brillantez son la clave del éxito.
El gran problema es algunos se creen Romarios y trabajan como tal y terminan por no ser ni Romarios ni Makeleles.
Hay que pasar de ser artesanos o artistas a ingenieros.
20 jul 2008 | 08:41 PM
Rafa, sin dudarlo prefiero los Makeleles como programadores. De la creatividad que se encarguen los de las áreas de diseño o ingeniería (independientemente del "título educativo" que tengan).
Conocí a un director de finanzas en Cruzcampo, de quien dependía la informática, que siempre se preguntaba si ésta llegaría a salir alguna vez de la situación preindustrial propia de la artesanía, por muy maestro que fuera el "artista". La ciencia y la tecnología no son arte.
Respecto de las nuevas generaciones que comentaba «patata», hay quien mira en India, de donde en UK se dice que El talento es su arma, cuando se refieren a sus jóvenes estudiantes.
21 jul 2008 | 12:19 PM
Hola Rafa:
Una máxima en esta profesión es que "el código del mejor programador del mundo lo comprende hasta el peor programador, mientras que el código del peor programador del mundo no lo comprende ni el mejor".
En mi opinión un verdadero programador virtuoso es un Zidane, Laudrup o similar, alguien espectacular pero elegante y organizado a la vez. Luego tenemos a los Makeleles, no tan vistosos pero resolutivos, trabajadores y organizados como pocos.
Como ejemplo de estos dos tipos tenemos a casi todos los contribuyentes a proyectos open source de primer nivel y trabajadores de la industria del software (en mi opinión no tanto en la de consultoría y servicios).
Lo has clavado con definir a esa clase de programadores a los que te refieres como Romarios. Personas capaces de hacer cosas brillantes, pero que siempre tienen un tufillo a chapucilla, desorganización y falta de método, algo que no es sostenible en ningún proyecto de cierto tamaño.
Por desgracia, la filosofía del sector (consultoría y departamentos de TI) en muchos casos, prima el bajo coste y la chapuza para conseguir algo "rapidito y que funcione", aún a costa de alimentar a estos Romarios.
Saludos.
22 jul 2008 | 03:10 PM
Coincido en parte con José en el tema de la creatividad y de que se debería encargar otra gente. Yo no diría diseño o ingeniería, sino más bien arquitectura de la aplicación. Desgraciadamente, en España y otros países, la tarea y figura del arquitecto se confunde con la del programador, analista, consultor, líder de equipo, jefe de proyecto y otros (la persona puede coincidir, pero el rol es distinto).
Otro problema que se da mucho es la falta de documentación. Creo que, por muy chapucera que fuera la pantalla, con buena documentación sería más fácil de entender. Desgraciadamente, puedo contar con los dedos de la mano la gente a la que conozco que les gusta documentar, y me sobrarían la mayoría.
De un comentario anterior me quedo con lo de "rapidito y que funcione" o como decían hace unos años, reducir el "time to market"
22 jul 2008 | 05:21 PM
Rafa:
Coincido en tu apreciación, y si bien ahora no tenemos Clipper, tenemos Java para todo el mundo. En este contexto, donde pones Java para todo, he vivido situaciones donde realmente nos llevó más de una semana de un programador experimentado en el lenguaje, descifrar qué y cómo trabajaba una porción de código.
Sin dudas hay que tener estandarizadas los procesos para crear código para lograr el salto definitivo.
Esta clase de personajes lo retratare en mi blog http://deconsultor.blogspot.com
23 jul 2008 | 12:29 PM
Hola Rafa,
Estoy deacuerdo en mucho de lo que se ha comentado, pero me siento en la obligación de hacer de abogado del diablo.
Empiezas con un "Espectacular"... y terminas dejando al pobre chico por los suelos.
Coincido en que habría que colgar de un arbol a todos los programadores con propensión a:
- llamar a las variables: pp, tt, kk ... o hasta kkk :)
- copiar y pegar tochos de código para modificar dos líneas
- entender la mitad de lo que le piden e inventarse la otra
- anidar if, while, for, switch ... desde el infinito y más allá
- "faltar a la verdad" en la documentación del código (es mil veces peor que no documentar)
- ...
Da igual que sean Romarios o Makeleles.
¿Tu Romario hizo estás cosas en el código aquél? Puede también que los Makeleles estuvieran demasiado verdes.
¿Qué pasó al final con aquella pantalla?
En cuanto a normalización, coincido en que estamos en la Edad de Piedra.
Desde hace un par de años trabajo en una empresa de control de calidad en la construcción. Es alucinante la cantidad de normas y reglamentación, todas ellas con años de vida, que se deben cumplir, sí o sí. Es más, existe la obligación de que haya una empresa independiente (nosotros) que realice los ensayos y las pruebas.
Puede que si todos programaramos en Cobol (como en construcción se usa el acero, el cemento, la arena, el ladrillo...) se habría impuesto un sistema similar. El problema es que se avanza tan rápido que los esfuerzos en normalización quedan desfasados al poco tiempo.
Bueno, puede que en bases de datos, los conceptos de tabla - columna - fila - índice - integridad referencial... estén más que maduros para que algún organismo oficial nos obligue a cumplir unas normas elementales de diseño y así evitar muchos disparates monumentales.
En el mundo de la construcción es obvio que el arquitecto no va a levantar una pared de ladrillos. Pero obviamente tienen el conocimiento de qué materiales debe utilizar, sabe que son los cimientos, que se empieza por el suelo, qué es una llana, un nivel, sabe que pintar se hace al final...
Lo que no he entendido nunca es por qué hay muchos informáticos que consideran un sintoma de "status profesional" el decir "yo no programo". Luego se permiten el lujo de "diseñar" soluciones basadas en herramientas de las que no tienen ni idea.
Para los pobres chicos recién salidos de la universidad, escuela de ingenieria, instituto de formación... se convierte en un infierno el descubrir que su formación está unos 5 a 10 años atrasada y que sus superiores no pueden ayudarles en nada. ¿Qué puede hacer un pobre Romario o Makelele si su entrenador no sabe lo que es un balón de fútbol?
La mejor cualidad de todo tipo de profesional dedicado a la informática es tener la certeza de que lo que sabes hoy, es vital para entender lo que debes aprender mañana. La hipoteca manda y hay que seguir teniendo trabajo hasta la jubilación.
Ufff, ¡vaya discursito!, ¡a bajar corriendo del púlpito! :)
Saludos,
Paco
23 jul 2008 | 04:31 PM
No tenía muy claro por donde iban a salir los comentarios, y me gustaría tener más tiempo (y mejor conexión) para entrar en detalles, pero lo del 3,5G en la playa es sólo para los anuncios. Pensaba que estarían más "empatados" y que algunos defenderían la creatividad a toda costa. Lo de las variables o ejecutables llamados kk o "solucion_rapida.exe" encaja con lo de "rapidito y que funcione" que todos hemos visto y vivido. Y si luego hay que modificarlo, ya vendrá otro.
Lo que es seguro es que un Romario no podría trabajar en una "software factory".
24 jul 2008 | 03:45 PM
No es igual programar que jugar al futbol. Respecto a la idea lo mejor es tener el equipo lo mas hetorogeneo posible, así puedes ser flexible para adaptarte a la producción.
25 jul 2008 | 06:10 PM
La verdad, lo ideal seria tener las dos cosas en una. Es decir, que no por ser creativo se descuidase la organizacion. Creo que el ejemplo que pones es extremo y lo mas comun es encontrar a gente que coge lo bueno de ambos lados, o por lo menos es lo que espero.
27 jul 2008 | 10:09 AM
Rafa, espero que lo estéis pasando bien en la playa. Aprovechad que tenéis hueco libre en la arena (me dicen que se nota la crisis en la densidad de toallas en primera línea de playa).
El tío era bueno (hablo del programador-terrorista), pero ¿era tan bueno técnicamente? Yo creo que la creatividad no está reñida con la estandarización y estructuración. Se puede ser creativo pero ajustándose siempre a los estándares de desarrollo de los proyectos. De todas formas la creatividad la veo más en la fase de diseño de los procesos, sistemas o programas, llamémoslo como sea, ahí es donde hay que ser creativo, para encontrar las soluciones más "excelentes". Sin duda, yo también creo que es mejor tener programadores estructurados (a la vez que creativos, proactivos, críticos y comprometidos) que programadores-gurú-pero-voy-por-libre que piensan que su genialidad no es para ser compartida con nadie. Las malas prácticas de los "romarios" se traducen luego en mayores costes para los departamentos TIC a la hora de evolutivo y correctivo y también, de alguna forma, en más "overtime". También en mayor "isostasia", concepto que comento en la entrada 22 del blog donde cuento mi historia.
Por cierto, veo que arranca otro blog de consultoría "Diario de un consultor"...... Ánimo!!!!
27 jul 2008 | 08:39 PM
Estoy de acuerdo con YUKI, la creatividad no está reñida para nada con la organización. Con respecto del “status” que menciona Paco, imagino que lo dirá alguien como lo dice un arquitecto, o un aparejados o un encargado de obras yo no pongo ladrillos, si se pone a levantar un tabique, dejará a 50 o 100 albañiles cruzado de brazos, y casi seguro que alguno de los 50 o 100 levanta el tabique antes y mejor que el arquitecto.
Para mi Romario era mi ídolo (a nivel de trabajador), con aquella fantástica entrevista que decía “si no tomo cubatas por la noche no meto goles”. Dejar el destino de toda una empresa (en aquel caso el f.c.b) en manos de una única persona que brillante hacía lo que le salía de los … cubatas, es mucho mas que una irresponsabilidad.
De todas formas hay tareas para la que un Romario sería genial (aún con su indisciplina), por ejemplo si la pantalla o informe solo va a utilizarse para una semana, y luego no se volverá a utilizar, los criterios de documentación y normalización se pueden flexibilizar, centrándonos en los resultados, ahora si el trabajo va a necesitar un mantenimiento, no se debe contar con alguien que valla por libre ¿quien le haría a Romario un contrato por 20 años?, así en USA, algunos jugadores de la NBA se contratan para uno o varios partidos, nos proporciona un buen refuerzo por sus buenos dólares y a casita.
1 ago 2008 | 08:55 PM
Hola a todos,
recuerdo aquello de "la potencia sin control no sirve de nada". ¿Era así la frase? La gestión y organización es fundamental para mejorar la productividad. Y desde un punto de vista de SLA, como pretende uno cumplirlo sin tener la documentación y los procedimientos bien preparados. Yo he visto más de una vez correr a mi director de TI en funciones de programador (si, inaudito pero real, ya lo comentaré en mi blog) para intentar solucionar problemas con unos reports justo antes de una reunión de dirección, y pasarlas canutas por no tener nada documentado. Y lo peor... ¡lo ha programado él! Y les aseguro que es un Romário en cuanto a conocimientos del workflow de la compañía, pero es un auténtico Romerito en cuanto a organización.
Insisto, la organización es indispensable para alcanzar los parámetros de rendimiento que se esperan de cualquier departamento, pero en TI lo es todavía más dado el amplio espectro de parámetros que pasan por nuestras manos.
Ahora, yo lanzo una pregunta: ¿Cuál es el grado de granularidad? En nuestro caso, dada la anarquía reinante, decidí tomarme la ley por mi mano y diseñé una metodología de gestión de proyectos que podía servir para los míos (sistemas) y para los más sensibles al caos (desarrollo). El problema es que, a pesar de definir más o menos lo indispensable, cada uno define el grado de especificación. Unos comentarán todo el código, indicarán referencias a otros objectos, etc. y otros se limitarán a hacer una descripción del proyecto y tan anchos, ya que afirmarán (seguramente con razón) que no hay que hacer del método el fin. Vamos, que se tiran más tiempo documentando que desarrollando, y mientras se amontona el trabajo encima de la mesa...