Cuando éramos cracks

No sé cuántas veces habré oído/leído eso de que los técnicos no sabemos vendernos (al menos los de por estas latitudes – ya conocéis el rollo ese de que los americanos son grandes comerciales de sí mismos y fuck yeah amazingly awesome). Pero el hecho es que basta con sumergirse ligeramente en la comunidad techie vía Twitter, conferencias o blogs, y resulta que no, que somos (con perdón) los putos amos. Toda esa incapacidad para ponernos un lazo de cara al extraño se torna en confianza ilimitada de puertas adentro. Seguro que habéis leído mucho sobre “cracks” y “talento” en los últimos años: pues eso.

Ahora bien, ¿y todo ese orgullo? ¿Tan interesante, importante es lo que hacemos? Pues en un principio sí. La informática ha revolucionado nuestro concepto de sociedad. Las comunicaciones, el comercio, el trabajo, todo depende ahora de un modo u otro del software, y siendo nosotros los responsables de crearlo y mantenerlo, que menos que sacar pecho, ¿no? Pues francamente creo que no. Hoy vengo a defender que el desarrollo de software está hecho unos zorros, y que sobra autocomplacencia.

Worse is all you get forever

Me ha encantado la expresión, sacada de este curioso post de Mike Hoye (sobre cómo acabó triunfado el 0-indexing de los arrays), para quejarse del estado actual del software con un guiño al clásico worse-is-better (todos habéis leído ya The Rise of Worse is Better, qué duda cabe, pero si no fuese el caso ya estáis tardando). La aproximación worse-is-better al diseño de software viene a postular que empezar con algo sencillo de implementar aunque no sea del todo correcto conceptualmente aumenta las posibilidades de éxito frente al acercamiento teóricamente correcto pero difícil de concretar en código. Explica cómo Unix y C triunfaron sobre Lisp, vamos. El guiño, y la queja, están en que worse-is-better se supone una manera práctica de iniciar algo, pero es una chapuza a largo plazo, cuando habría de ser reemplazado por una solución correcta, completa y robusta. Pero ese reemplazo nunca se ha dado.

Echemos la mirada atrás en el tiempo, allá por los 70. El inicio de la computación moderna. Aparecen el microprocesador, los primeros ordenadores personales, C. Los primeros y muy rudimentarios videojuegos (te miro a ti, Pong). Interfaces de texto en fósforo verde, frecuencias de reloj por debajo del megaherzio, herramientas muy básicas. En fin, el año cero de todo este tinglado (nunca mejor dicho, el 1/1/1970 marca epoch). Visto desde nuestro prisma actual, con interfaces táctiles, en 3D y a todo color, móviles ultra-potentes, videojuegos que simulan el mundo real con un nivel de detalle ridículo, y redes de velocidades absurdas, es la prehistoria. Todo ha mejorado de manera radical, irreconocible, le parecería magia a un fulano de los 70. ¿Todo? Bueno, todo no. Las principales herramientas de desarrollo de software son las mismas. C sigue dominando el panorama de sistemas, Unix está en el corazón de nuestros móviles de última generación, y Lisp sigue siendo un ideal al que todos aspiran. ¡Es el día de la marmota!

No deja de ser frustrante. Sí, ahora tenemos mejores IDEs, frameworks de la leche, buenas herramientas, pero el núcleo del desarrollo de software, los lenguajes, apenas han cambiado desde los 70. Más de 40 añitos ya. C lleva ahí desde siempre, y sigue partiendo buena parte del bacalao. Lisp es la principal fuente de inspiración de los lenguajes de alto nivel. Y de ahí no salimos. De hecho hemos entrado en una suerte de barrena de ideas, y todo nuevo lenguaje es una mezcla o refrito de los de siempre, con poca o ninguna voluntad de ir un poco más allá. ¿La nueva técnica molona y reveladora del momento? Se inventó en los 60, no falla. Clausuras, continuaciones, corrutinas, trampolines, TCO, todo inventado desde hace medio siglo. Otra cosa es que la gente no las conozca y las descubran por primera vez con el lenguaje cool del semestre, pero a eso ya iremos luego.

Estancados. Y si dijeras “bueno, es que lo tenemos ya es casi perfecto”, pues nada que objetar. Pero es que hemos llegado al punto en que la gente asume que el software siempre va a estar trufado de errores. Evidentes unos, sutiles otros, pero a cientos. ¿Os imagináis edificios o material quirúrgico de esa endeblez? Los lenguajes y sus entornos de ejecución deberían ofrecer garantías mucho mayores tras tantas décadas de refinamiento, pero en fin…

Problem Exists Between Keyboard And Chair

Los picos y palas andan algo oxidados, qué le vamos a hacer, pero todo se arregla si vamos sobrados de materia prima, de diamantes. Técnicos bien preparados, que conozcan a fondo los pros y contras de las herramientas disponibles. Con experiencia y criterio: una sólida base teórica y unos cuantos balazos en el campo de batalla, expuestos a tantas tecnologías como haya sido posible. El famoso talento del que todo el mundo habla y que tan extendido está, supongo. Y el tema es que yo no veo tantos perfiles de esos, la verdad sea dicha. De hecho creo que cojeamos en la preparación técnica, y que no se me enfade nadie.

No es que sea un experto en selección de personal, cierto, pero me he garbeado por unos cuantos eventos de diversa índole, aquí y en esa tierra prometida que es el Bay Area de San Francisco, y la imagen que me he hecho del desarrollador medio no es precisamente halagüeña. Charlas para entendidos en Javascript que nunca antes habían visto encadenamiento de funciones, grupos de amantes de HTML5 dónde es un misterio el funcionamiento del tag de script, eventos de la flor y nata del desarrollo web dónde no más del 1% de los asistentes se ha leído la especificación de HTTP, siendo optimistas. En definitiva, no la más sólida de las bases teóricas. Eso sí, los portátiles trufados de pegatinas de GitHub y otras hipsteradas molonas.

En fin, la experiencia es un grado, y supongo que se pueden hacer cosas decentes a base de prueba y error y muchas horas para compensar un conocimiento no tan vasto. Seguro que la gente ha probado cantidad de tecnologías, y a base de solventar problemas con unas y otras tienen ahora una buena base para escoger con qué afrontar cada tipo de problema. Pero de nuevo te paseas por eventos donde los técnicos explican y justifican las elecciones tecnológicas en sus proyectos. En mi experiencia no haría falta organizar más ediciones de esas reuniones: si es web, todo el mundo tira por PHP y MySQL por estos lares. ¿Por qué? Pues, y aquí son sinceros respondiendo, porque no conocen nada más. De vez en cuando un valiente reconoce haber echado un ojo a Ruby, o Python, o Node, o qué sé yo, pero el esfuerzo de aprender algo nuevo es grande, y el mercado para todos esos productos es pequeño, así que renuncia. En algunos casos alguno ha cambiado MySQL por MongoDB, porque ha leído en un blog que es más rápido (así, en general), y hasta ahí.

Se me antoja terrible. No por la elección de PHP (por mucha broma que haga, cada cual es muy libre de preferir una u otra herramienta), sino por el planteamiento. El mercado pide x, y sin plantear si hay opciones mejores, se escoge x cada vez. El mercado no lo pide porque lo considere mejor o peor, lo hace porque hay más oferta de técnicos, y hay más oferta de técnicos porque es lo que pide el mercado. Exacto, tenemos un pez que se muerde la cola, un idiota bucle acrítico. Me quejaba antes de que las herramientas más básicas en el desarrollo de software no avanzan, y me temo que el inmovilismo de los profesionales tiene mucho que ver. Aprender un nuevo lenguaje es relativamente rápido, dominarlo es un trabajo costoso. Y somos muy cómodos.

Back to the future

Hay un futuro por recuperar. Hemos rebajado el nivel de la profesión al mínimo común a todo hijo de vecino, en vez de elevar la barrera de entrada para obligarnos a seguir la estela de los mejores. Hemos vulgarizado el desarrollo de software. Lo prioritario es que todo el mundo pueda hacerlo, no que se haga bien. Los cirujanos se pasan la vida poniéndose al día porque de lo contrario se quedan fuera de juego, un ingeniero automovilístico estancado en la tecnología del 2000 está en el paro. Pero nosotros perpetuamos herramientas ya superadas en una industria que se mueve a velocidad de vértigo en todo lo demás. Paradójico.

Los 70 marcaron el inicio de una revolución, lo que necesitamos ahora es una demasiado postergada evolución.

Advertisements

11 thoughts on “Cuando éramos cracks

  1. Gran post como siempre ,pero no estoy 100% de acuerdo con el último párrafo. Lo que pasa es que la diferencia entre un ingeniero automobilístico que se recicle o no es estar en el paro o no, pero para un informático es pasar de ganar 800€ a burradas.

    Totalmente de acuerdo en que nos flipamos con cualquier hypsterolenguaje que sale pero nos olvidamos de bases, de conceptos, de patrones, de principios y de estándares. A picar código que el viernes hay release y el cliente tiene este bug desde hace un mes….y así no

  2. Bueno, al final los micros se programan en ASM y C no? quizás se deberia empezar por interpretar python/java bytecode a nivel de chip no?

    Yo creo que aquí tambien se generaliza mucho, gran parte del software que existe y que permite que el mundo funcione como lo conocemos, es software en microcontroladores esparcidos por el mundo: switches, coches, trenes, estaciones transformadoras, distribución de agua, centrales eléctricas, semaforos, PLC’s industriales, torres de telecomunicaciones, procesos batch en bancos, ….. Es muy bonito querer usar las últimas técnicas de programación pero si tienes un micro que controla unas válvulas, quieres que sea eficiente, que funcione, que gaste poca bateria y que lo pueda hacer algun ingeniero que no sea de software.

    1. ¿Y en que otras disciplinas la solución eficiente, funcional y accesible no ha cambiado desde la creación misma de la disciplina?

      ¿Realmente C es simplemente insuperable y en 40 años no se ha dado con algo mejor? ¿O es que en realidad nadie lo ha intentado siquiera?

      Porque no conozco otro caso en la historia de la ingeniería. Todo ha sido sustituido constantemente por mejores aproximaciones hasta la saciedad, y por eso los coches son mejores que hace 50 años, la medicina es mejor que hace 50 años y los edificios son mejores que hace 50 años.

      C es prácticamente igual que hace 50 años, y por tanto la programación de microcontroladores también. Y eso, francamente me escama. Sin restar mérito a Kernighan y Ritchie, no creo que dieran con la perfección a la primera.

      La medicina es más crítica que la programación, y las técnicas quirúrgicas han evolucionado mucho más que C en el mismo tiempo, así que el argumento de la estabilidad no me sirve.

      1. Míralo de otra forma, en el sector automobilístico, llevan 100 años de evolución del motor de explosión. Realmente en 100 años no han hecho mas que hacer mas eficiente una explosión dentro de un cilindro y meter turbos? Quizás a nosotros nos parece que 40 años es una eternidad, pero en muchas areas de la ingenieria, desde el prototipo hasta la comercialización pasan 10 años … Un coche tendrá más electrónica, será mas eficiente, etc, pero no deja de ser unas explosiones controladas, que empujan un cacharro de 4 ruedas con 4 puertas …..

        Quizás el C es solo como el motor de explosión, una base que funciona, y sobre la que se mejora alrededor, pero no se cambia el paradigma.

        Xavi

  3. Uhmmm creo que mezclas dos cosas: el nivel de mediocridad en el sector informático y el “C aun sigue vivo”.

    1. La mediocridad en el sector informático.
    No voy a ser conformista diciendo que bueno, en otros sectores también existe. Hay médicos buenos, malos y mediocres. Pero ¿por qué existe esa mediocridad? y ¿quién se beneficia?

    – ¿Han mejorado en algo los procesos de selección para eliminar esa mediocridad?
    – ¿Hay empresas que compran mediocridad?
    – ¿Se valora el resultado final o los beneficios, sobre de dinero negro, cena de dueños?
    – Si encuentras a un buen profesional ¿se le valora tanto en resultados como en compensación o se le explota?
    – ¿Qué empresas saldrían perdiendo si se airease esa mediocridad?

    2. C sigue vivo.
    Y el español (pongo un idioma por poner uno) sigue vivo. Y aun vamos a la escuela como hace 100 años, aparte de los contenidos y de nuevos y mas bonitos libros (incluso electrónicos).

    – ¿Qué papel cumple C?
    – ¿Dónde funciona y donde no funciona como herramienta?

    Como profesionales debemos saber cuando utilizar una herramienta y cuando otra. Pero C no es C sin compiladores. Hay mejoras en los compiladores y en todas las herramientas que te permiten analizar código y decirte si se te ha ido la pinza.

    Sin contar que no solo hay nuevos lenguajes que implementan mejor las ideas, teorías y demás de hace años. Es como si eso no fuera un avance. Relegamos C para lo que es útil y usar otros lenguajes para otros problemas.

    Y algo que no he visto en tu post es la cantidad de conocimiento acumulado en bibliotecas y frameworks.

    3. Conclusión.
    Quitando al hijo del vecino que aprendió HTML o el que se metió en la carrera de informática por tener una carrera (Y hay muchos, y en muchas otras carreras). El resto avanza.

    El único problema es saber ser un buen profesional y saber lo que es bueno y lo que no sin dejarse llevar por modas o el olor a algo nuevo.

    Nota: En los últimos años no me ha hecho falta programar nada en C para hacer mi trabajo o para probar una nueva idea.

    Nota2: Siempre me ha llamado la atención C, y no solo C sino ensamblador, aunque me gusta mas el de RISC que es mas sencillito de entender que el de x86 que necesitas una biblia al lado.

    1. Vaya, parece que se está poniendo mucha el acento en lo de C, y no era la idea.

      La premisa no es si C se usa o no se usa o si suma o no méritos para seguir por aquí. La premisa es que el desarrollo de lenguajes lleva dando vueltas a los mismos conceptos, sin aportar soluciones netamente mejores (o diferentes al menos), más 40 años. C es sólo un ejemplo paradigmático para ilustrar esa idea, nada más.

      La industria ha avanzado a pasos agigantados en todo lo demás, y con pasitos de duendecillo en lo tocante a lenguajes (la base del software). Y creo que es por vagancia intelectual del personal.

      En cuanto a tu comparación con la educación, no puedo estar más en desacuerdo. Evidentemente la educación en su núcleo, transmitir información, lleva miles de años existiendo, tantos como el hombre. Pero en los últimos 100 años ha cambiado radicalmente en alcance (no era universal hasta principios del XX), metodología (la psicopedagogía y demás hierbas son de mediados del XX) y contenidos. Y aunque no lo hubiese hecho, la educación ha tenido miles y miles de años para pulirse y llegar a un óptimo, el desarrollo de software no.

      En RISC vs CISC estoy contigo, aunque ahí también se ha llevado el gato al agua el “worse” ;)

  4. Algo muy, muy parecido le oí decir a Uncle Bob no hace mucho en un podcast. Tenemos mejores herramientas pero hacemos el mismo trabajo. La limitación existe en que como humanos somos limitados y nos cuesta un montón salir de la rutina.

  5. Interesante post, como todos los tuyos :-).

    Un par de ideas: con respecto al tema de la evolución de los coches, hace un par de días leía esto: http://www.diariomotor.com/2013/11/05/el-gran-estancamiento-por-que-pensamos-en-coches-electricos-cuando-deberiamos-estar-creando-colonias-en-marte/, podrás ver que la sensación de estancamiento y de falta de innovación (hay evolución, pero nada disruptivo) aparece en otros sectores.

    Con respecto al conformismo en el sector, sí, claro. Da mucha pereza (o cuestan muchos puntos familia, la situación personal de cada uno aquí influye mucho) llegar a casa y ponerte a aprender tecnologías nuevas, invertir fines de semana y/o vacaciones para asistir a cursos o conferencias, …

  6. No sé hasta que punto está relacionado con la autocomplacencia o no, creo que es mucho más complejo que eso, pero totalmente de acuerdo en que el desarrollo de software está hecho unos zorros y espérate, porque llevamos una inercia guapa que no veas… y lo más deprimente es la complejidad que estamos generando con todos los ¨worses¨, en lugar de crear nuevos y mejores paradigmas en todos los sentidos: herramientas, stack, lenguajes, etc. (aunque también soy de la opinión de que eso no lo hace cualquiera…).

    En fin, siento ser tan escueto y abstracto pero solamente quería recomendarte un par de charlas y esto no lo vamos a solucionar aquí… Si te pasas por Sydney avisa y con unas cervezas una tarde, sí que lo solucionamos…

    Ah sí, las charlas, ambas del mismo tipo, Bret Victor, si es que no lo conoces y las has visto ya:
    * http://vimeo.com/71278954
    * http://vimeo.com/36579366

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s