Creatividad

Estuve pensando bastante sobre el ultimo post que escribí, así que me gustaría comenzar este con una auto critica:

Primero, como comento Hernan Parra, deje de lado que uno de los principales damnificados en la historia es la empresa que necesita de la funcionalidad del software.
Segundo mezcle en una misma historia dos cuestiones distintas:

• El problema que tenemos como país latino-americano en relación a las potencias. Respecto a esto, creo que el reverso del iPod lo dice todo: "Designed by Apple in California. Assembled in China".
• El problema del marketing de tecnología y de como una y otra vez nos tragamos el cuento de la "nueva bala de plata". Problema que también tienen los países del norte.

Mas allá de esta auto critica lo que me dejó pensando fue la siguiente cuestión: ¿Qué puedo hacer desde mi posición de desarrollador/arquitecto de software?

Se me pasaron por la cabeza varias cuestiones:

• Tener un pensamiento critico hacia las tecnologías que usamos.
• Capacitación e investigación constantes, para fundamentar las decisiones que tomamos.
• La importancia de pensar primero en el problema de dominio y luego en las tecnologías que se van a usar para resolverlo.
• Una mayor comunicación, con los clientes y la gente de ventas, sobre todo para explicar por que la tecnología X no resuelve magicamente todo.
• ... etc.

Pero después llegué a la conclusión de que todas estas cuestiones se pueden resumir en una: creatividad.

Es necesario que quienes hacemos software seamos más creativos.
Por "creativos" no me refiero a la creatividad sin limites como en el arte.
Me refiero a la creatividad de preguntarse como hacer las cosas mejores, sin limitarse a lo conocido. Eso no significa que el camino que recorrieron otros este mal, si más bien significa no aceptar axiomas del tipo: esto se hace así... por que siempre se hizo así (punto).

En el desarrollo de software somos extremadamente conservadores, por ejemplo:

Definición de requerimientos y casos de uso.

La definición de requerimientos es muchas veces así: alguien se sienta con el cliente/experto/futuro usuario y le hace una o varias entrevistas, de ahi se va sacando la funcionalidad. Luego dependiendo del grado de "burocracia" que tenga el proceso de desarrollo se hace un documento de requerimientos, uno de caso de uso o de historias de usuario, un product backlog, etc.

¿Es esta la única forma de hacer las cosas?
Si uno lee libros sobre diseño industrial o IxD, puede ver que hay muchas otras tecnicas para saber que necesitan los usuarios. De hecho, ninguna gran empresa de diseño industrial se quedaría solo con una entrevista al usuario: es un camino al fracaso.
Entonces... ¿Por que nosotros seguimos haciendo solo eso? ¿Hay formas mejores?

Ahi es donde entra en juego la creatividad: hay que salirse del molde que uno conoce e irse otros planos como por ejemplo libros de diseño industrial, de psicología, antropología, etc. (como diria Alan Kay moverse al plano azul)

Comunicación.

La comunicación en el desarrollo de software es muy importante, lo dice Fred Brooks, lo dice Alistair Cockburn, y otros más.
Tambien lo dice Booch et. al. y por eso crearon una notación y una forma de transmitir un diseño a varios niveles: UML.

Ahora venimos nosotros: alguien nos dice que tenemos que documentar.
Entonces leemos libros largos y complicados sobre como documentar arquitecturas y sus diferentes vistas usando UML y otras notaciones. Hacemos un curso de UML y nos aprendemos toda la sintaxis. Pero... ¿Nos detenemos un momento a preguntarnos si es la única forma de comunicar? ¿Cuales son las formas de comunicar?
Hay gente que dedico muchos años a investigar la comunicación entre personas: educadores, sociologos, lingüistas, etc. ¿Que puedo aprender de ellos?

Desarrollo.

A veces veo desarrolladores que pasan horas tratando de hacer funcionar un framework, sin plantearse nunca ¿Que valor agregado me da? ¿Lo necesito? ¿Puedo hacerlo mejor? ¿Qué problemas me trae el framework para expresar el modelo de dominio?
Aca el ejercicio creativo es muy importante. No para re inventar la rueda una y otra vez, si no para darse cuenta como funcionan las cosas, y llegar quizás a mejores alternativas.

Alguien que lee todo esto podría objetarme lo siguiente:

No hay tiempo. Si cada desarrollador hace esto, entonces no terminamos nunca. Si cada uno se pone a "ser creativo" el desarrollo es un caos.
Si queres escribir un documento de requerimientos, segui el template. Si queres desarrollar, aca usamos el framework X, trabajamos siempre asi y no lo vamos a cambiar, asi que ni pierdas el tiempo en ver que problemas puede tener X, o en evaluar alternativas distintas.

Es cierto que a veces hay que balancear: tiempo y otros requisitos. Tambien es cierto que para trabajar en equipo hay que respetar las normas del equipo.
Sin embargo no vi ninguna empresa/producto exitoso que no hay roto el molde en algun sentido, por ejemplo:

• Linux surgio por que Linus Torvalds quizo experimentar creando su propio SO. Imaginense que hubiese sido si Torvalds decia: "ey para que perder el tiempo en esto si ya existe Minix".
• El framework Spring, surgio para resolver problemas de J2EE... hoy se usa en todos lados y la gente que lo hizo pudo haber dicho: hagamos todo como lo dice el Blueprint de Sun.
• Si Jeff Sutherland se hubiese quedado solo con el modelo un proceso tipo "cascada", hoy no existiría SCRUM.
• 37signals, comenzo a hacer sitios web usando Ruby (cuando lo no conocia nadie), para esto diseñaron su propio framework: Ruby on Rails. Si querian usar Unix se podian haber quedado con Perl.
• En el 99/2000 la tendencia de todos los buscadores*: Yahoo , AltaVista, Lycos, Excite , etc., era la de hacer portales. De hecho la palabra portal se puso de moda con esos sitios: un portal era el punto de partida a Internet. Asi que la "portada" del portal tenia que tener de todo: noticias, directorio de busqueda, acceso a servicios (y sobre todo publicidad). ¿Que hubiese pasado si Google hacia otro portal más?
  
• Ebay usa bases de datos sin constraints para mejorar la performance, planten esto a un DBA y les va a tirar el manual de Oracle por la cabeza.
  
• GMail uso JavaScript para mejorar la interactividad de la aplicación y comunicarse con el servidor... cuando todos usaban JavaScript solo para hacer un "roll-over". (bueno en ese momento ya habian varios ejemplos y tutoriales de AJAX por la web, pero creo que GMail fue en primer web mail en hacerlo bien).
• Tanto con el iPod como con el iPhone, Apple decidio ser más creativo que el resto: en lugar de hacer otro MP3 Player u otro celular, se plantearon ¿Como puedo mejorar la experiencia del usuario?... y para responderse esa pregunta experimentaron mucho.
  

Hay que tener en cuenta que las empresas que crearon esos productos "exitosos" no tenian el camino tan claro cuando empezaron (claro que estoy tomando para el ejemplo "exito"="mainstream", lo cual no necesariamente es asi).

Por ejemplo el libro de Bill Buxton (Sketching the user experience) cuenta un poco la historia del iPod: se necesitaron varios experimentos y modelos distintos para lograr un exito. Lo mismo sucede con las historias que cuenta Designing Interactions (nota: los capitulos de este libro se pueden bajar del sitio... tiene muchas historias de como se diseñaron la mayoria de las cosas que usamos en la compu, realmente es una buena fuente de inspiración).

La conclusión importante de todo esto es:

No se puede hacer algo bueno sin plantearse primero como mejorar lo que existe.

La respuesta no va a ser obvia, y se requiere de prueba y error (que puede ser costosa). Pero si uno mata esa creatividad y se queda con lo "estandard" o lo dado, sin si quiera hacerse un re-planteo, entonces siempre vamos a seguir con los desarrollos mediocres... atrapados en el modelo de negocios orientado a buzzwords.

* los links apuntan a las versiones del 2000, es interesante comparar algunos con la version 2009... Por ejemplo el exito de Google hizo que AltaVista (en el 2000 tan conocido como Yahoo hoy) avandonara el estilo "portal".