El autor, programación, circa 1988

¿Deberían los diseñadores codificar?

No, primera parte.

Hay un debate recurrente en nuestra industria sobre si los diseñadores deben escribir código o no. Algunos desarrolladores plantearán la pregunta en Twitter, luego los expertos, los profesionales y los gurús la responderán. Todos tienen una opinión, el temperamento estalla, luego la gente acepta no estar de acuerdo, y la discusión disminuye. Pero unas semanas más tarde, alguien más plantea la misma pregunta y las redes sociales florecen con otra repetición instantánea del argumento inútil e incesante.

El debate sigue un patrón característico: las personas discuten una cuestión de gusto personal como si fuera una verdad universal. Es como alguien que afirma que, como a ellos no les gustan personalmente los aguacates, los aguacates son un alimento terrible y que otros también deberían rechazarlos. El problema, obviamente, no está en el aguacate sino en el individuo, sino que las emociones ocultan lo obvio.

Veo dos razones por las que no podemos ignorar este debate sin sentido. En primer lugar, es importante porque los jóvenes, mal equipados para evaluar adecuadamente la pregunta, pueden desperdiciar mucho esfuerzo y oportunidades. En segundo lugar, el hecho de que se repita, siempre disfrazado de una pregunta amplia y seria, me convence de que su persistencia oculta algunos problemas más profundos, algunas motivaciones al acecho.

Me considero excepcionalmente calificado para comentar sobre la pregunta. Antes de desarrollar la práctica del diseño de interacción, desarrollé una carrera exitosa escribiendo algunos de los software más innovadores para computadoras personales en los años setenta y ochenta. A pesar de mis calificaciones, mis propias tormentas de tweets son inadecuadas para este desafío. Hay demasiados problemas y demasiados matices para breves exposiciones. Por lo tanto, mis pensamientos sobre este tema están aquí.

Hay varios argumentos en contra de la premisa de que los diseñadores deben codificar, pero solo veo un argumento para ello. El problema que ninguno de los argumentos aborda es que toda la pregunta no es realmente relevante. Es un síntoma de otros problemas en el arrastre. El efecto principal es ocultar la cuestión importante e importante de cómo los profesionales deberían trabajar juntos. Hablaré de eso más tarde.

Los principales argumentos contra la codificación de los diseñadores son los siguientes:

  1. Puedes saber sin hacer. Hay muchos ejemplos de entrenadores, coreógrafos, entrenadores y ejecutivos que dirigen el trabajo de los profesionales sin realmente hacerlo ellos mismos.
  2. Realizar una tarea no le enseña automáticamente las implicaciones de realizarla. El hecho de que codifique no significa que comprenda automáticamente los efectos de su código en los demás o en la organización.
  3. Hay una enorme variedad de habilidades, tareas y roles laborales en el mundo del desarrollo de software y hacer afirmaciones en la dualidad simplista de "diseñadores" o "desarrolladores" no reconoce la complejidad y el matiz de estos roles.
  4. ¿Por qué estamos haciendo esta pregunta? Siempre parece ser planteado por los profesionales con la menor empatía por los demás, pidiendo empatía del grupo mucho más empático, mientras ignora el desafío verdaderamente importante de empatizar con el usuario.

El único argumento para favorecer la codificación de los diseñadores es realmente una amplia generalización de que hacer el trabajo de otra persona por un tiempo es una buena manera de comprender los desafíos que enfrenta la persona. Entonces, sí, generalmente es bueno que los diseñadores pasen algún tiempo codificando. Por supuesto, con este mismo argumento, los codificadores deberían pasar algún tiempo diseñando. Y al diseñar, no me refiero a diseñar pantallas. Me refiero a entrevistar a los usuarios y luego dar sentido a lo que aprenden.

Sin embargo, no creo enfáticamente que los codificadores de producción deberían hacer el diseño de producción. Eso sería equivalente a pedirle al programador que haga la contabilidad. Claro, probablemente son capaces de hacerlo, pero ¿por qué? Qué desperdicio de buen talento de programador en la contabilidad común. Los buenos programadores y buenos diseñadores son raros. Es tonto y derrochador hacer que trabajen fuera de su habilidad especial particular.

El verdadero problema.

La falla realmente grave con todos estos argumentos es que evitan la pregunta más importante: ¿cómo creamos software?

Se construye una gran cantidad de software todos los días en el mundo, pero eso no significa que realmente sepamos lo que estamos haciendo. Las cosas se construyen, y la naturaleza humana es lo que es, lo consideramos normal. Pero infamemente, en el mundo en cascada del desarrollo empresarial, cerca del 80% de todos los proyectos de software fracasan. Hemos estado construyendo sistemas de software deficientes durante décadas, y todavía parece que no podemos encontrar la manera de hacerlo de manera efectiva. Los proyectos típicos nunca salen por la puerta. Los que se implementan a menudo son versiones patéticamente débiles que carecen de potencia y flexibilidad.

Los agilistas se regodean con el fracaso de los métodos convencionales de desarrollo de software, pero sus métodos más modernos para crear software no son significativamente mejores. La mayoría de las fallas son más pequeñas, más rápidas y más fáciles de ocultar. No quiero entrar en una discusión sobre este punto, porque creo que ágil es un salto maravilloso y tremendo en el mundo del desarrollo de software práctico. Pero seguro que no ha estado a la altura de su facturación. Confunde a la gerencia. Es notoriamente difícil de realizar a escala. A menudo deja de lado el diseño real centrado en el usuario. Es reactivo más que proactivo. Y lo peor de todo es que muchos de sus practicantes utilizan reclamos gerenciales y técnicos para agitar las manos, soplar humo, falsas y prestidigitación como una hoja de parra para ocultar la ignorancia, la incompetencia y la negativa a trabajar bien con otras disciplinas necesarias, especialmente, diseño de interacción (Sí, esto es una maravilla en ágil, pero, en aras de la perspectiva, creo que ágil es mejor que todos los demás métodos de desarrollo que tenemos).

Peor aún, es que los equipos están constantemente discutiendo sobre el territorio, culpando a las diversas disciplinas por su incapacidad para cumplir con los plazos. Hay personas que afirman que los “plazos de entrega de software” son un oxímoron, y establecerlos es evidencia prima facie de una falta de comprensión del medio. Francamente, soy una de esas personas. Casi todos los esfuerzos de codificación son una salida a lo desconocido, y generalmente se necesitan un par de viajes para conocer el territorio. La predicción es imposible. Me gusta comparar el desarrollo de software con caminar por un campo minado: si no pisas una mina, es rápido y fácil. Cualquiera que le dé una predicción de cuánto tiempo llevará el desarrollo de software está disimulando. Y si le pregunta a alguien esa predicción, está alentando la prevaricación y está manteniendo el mito de la industria de que el desarrollo de software es predecible.

Espero escribir más sobre este gran tema, así que estad atentos.

Aquí está la segunda parte.

Aquí está la tercera parte.

Aquí está la cuarta parte.