Nicaraguan Sign Language

Surely you are aware of this story. San Judas, Nicaragua, in a neighborhood called Managua was opened Villa Libertad. Quite a name for a school and what a school for deaf children.

This was a success story for the users and a big fail for the authors. Teachers tried to train students in lip-reading and speaking Spanish. While adults get involved in this unfruitful game, the children became to communicate with each other creating their own conventions. This way was born a new and fascinating language. Over time, this language gain in complexity and developed verb agreement and a lot of grammars.

Here we have a lot of lessons and for linguists a science fiction opportunity to explore human communication but without the fiction.

Listen to your users

Nicaraguan government and the school staff didn’t saw what was going on within the children, they didn’t hear or had attention to what those small creatures were doing. In those years, children and crazy people had no voice.

With users of computer software we have a very similar tradition, even now you can hear some technical people using the word “user” as a pejorative. It was not until the recent years that developers became aware of the importance to listen what their users have to say.

People want to communicate

You don’t need to force people to communicate, they will do it all by them selves if you just allow them to interact. Of course, if you make easy communicative interactions then surely people will communicate more.

It is an uncontroversial conclusion that “social media” systems are so successful because of the communicative opportunities they create or extend among people.

People adopt communicative conventions

The first children at Villa Libertad just used a few signs, but as soon other children adopted those signs, more and more were added and a grammatical structure were created to communicate more efficiently. All those linguistics artifacts are conventions adopted and “upgraded” by generations of children.

Twitter

Not an awesome story as the one of Nicaragua children is that of Twitter, where users have created a lot of “alternative” functionality integrated later by the developers.

Of course, users have influence from previous experiences, the same as speakers of a language import words and grammars from other languages. I remember when IRC were the “social media” available at the time. Those days, people used “@” sign to “address” a person in a message. Hash “#” where channels and a lot of emoticons were used.

Reading Scrumban

Reading Scrumban: Essays on Kanban systems for Lean Software Development

I’ll be honest. I didn’t enjoy this book. Nevertheless, there are a lot of interesting ideas on it, enough to recommend its reading.

In the introduction, Corey Ladas resumes his book as a critic to the so called “old Agile methodologies” and presents his own work not only as the new proposal being different, but as the finest paradigm for software development. Reading further seems that the one Agile methodology that the author knows is XP, I guess he knows a lot more, but the only one he talks about is XP. I find difficult to criticize the Agile movement taking only a very partial sample as XP.

The Agile movement is more than a single methodology, but a form of thinking and living software development. You can be an old fashioned Agile developer or a vanguardist one, but Agile the same. The “costume” is a matter of personal and team preferences.

Scrum-ban is just another strategy of organizing workflows that indeed seems to be a good one, but present it as an anti-pattern for Agile is absurd and by no means necessary.

Scrum-ban takes almost everything from Kanban, a methodology more focus on product development than software. The main idea is to enforce auto-control of the workflow by the team using a quite simple pull system.

The attractive of Kanban and Scrum-ban is their simplicity of implementation. You can become your team a Srum-ban team even if this is your first experience with Agile methodologies with no sophisticated tools or an extensive knowledge.

The protocol of Scrum-ban is inherited from Scrum, but evidently you can be as protocolary as in XP or as free as in Crystal. In fact, Scrum-ban tries to reduce the protocol in Scrum reducing the time that meetings require. This protocol reduction leaves you in a scenario more alike to Cockburn’s self-made methodologies, which is my personal election, to have a self-made Agile methodology with a Srcum-ban pull system.

Some Links:

Scrumban at Amazon: http://www.amazon.com/Scrumban-Systems-Software-Development-ebook/dp/B004SY63BY/ref=sr_1_2?ie=UTF8&qid=1316368812&sr=8-2

De la poesía Aimará al desarrollo de software

Vicente Huidobro, poeta chileno considerado el padre de la primer vanguardia latinoamericana, rescató la frase de otro poeta del que parece que nadie conoce el nombre, seguro porque no fue el padre más que de sus hijos.

El poeta es un dios; no cantes a la lluvia, poeta, haz llover

La frase se la oí a un maestro cuando me decía que los artistas son creadores de realidades, “¡no digas que llueve, haz llover!” manoteaba emocionado.

Desde entonces, he pensado que no sólo en la poesía y en el arte valen estas enseñanzas, sino en todo lo que hacemos.

Los malos escritores nos dicen que llueve, los buenos nos empapan en la tormenta; los malos profesionales nos hablan de sus mil virtudes y habilidades, los buenos hacen las cosas como se deben hacer, sin andar cantándose loas.

En el mundo de la tecnología es arto común encontrarnos con pregonadores de las propias virtudes, virtudes que por cierto, difícilmente pueden demostrar. Es incluso posible que nosotros mismos hayamos caído alguna vez en este cliché que obliga a otros a decir “¡no me digas cómo se podría resolver, resuélvelo!”

De nada le sirve a nuestros clientes una cátedra de cómo se podría resolver un problema, o la enumeración de las mil y una soluciones que se nos ocurren para un determinado algoritmo. Lo que ellos necesitan es que dejemos nuestra pretendida erudición a un lado y manifestemos nuestra habilidad para concretar soluciones.

En la vida, saber y hacer son dos cosas muy distintas, o como dicen por allí, del dicho al hecho hay mucho trecho.

Reading Agile Software Development

About the book Agile Software Development by Alistair Cockburn

Since I started to read this book, there is no person which I talk to that I don’t invite to read it. It’s true that seems as a computer specialist book, but you can read it skipping the occasional technical details and I’m sure you’ll discover, as I did, that this book is plenty of knowledge about human beings, about creating and improving collaboration among human beings.

Being agile is being a productive team, that means, a team that communicates between each other and beyond the boundaries of that team: clients, sponsors, contractors, retailers; a team that delivers work, this can be a software or a book or even a service; a team that reflects on its own, how are they communicating, what can they do to make it better, what they don’t like, what they want to prove; a team that can react quickly to plan changes, maybe the market conditions are not the same as were at the beginning, maybe the sponsor has discovered a new priority.

Cockburn is a specialist on leading software development teams, and this is a skill not necessarily technical, but about human beings; how we learn, how we collaborate with each other, how we can improve our skills, and the most important: how we can communicate. This book is about communication; drives you through the concepts that motivates the Agile movement to a framework for creating methodologies that can be adapted to almost any team in any field, just translate to your own activity the words about software development.

Igualados y mandones

Andaba muy xinu-xanu por aNobii cuando me encontré un tema de discusión acerca de las traducciones de la interface. En aNobii, como en otros sitios sociales, permiten que los usuarios más emprendedores traduzcan la interface. Le copio aquí un fragmento escrito por Aljullu (el nombre de uno de los usuarios):

– Quan l’ordinador es dirigeix a l’usuari (a Sofcatalà aconsellen el tracte de “vós”, però per aquí havíem comentat que potser és millor, en aquesta web, el tracte de tu)
– Quan nosaltres ens dirigim a l’ordinador (crec que aquí tots estarem d’acord a utilitzar l’imperatiu, com demana Softcatalà i s’usa a totes les traduccions de programari en català, tot i això hi ha trossos traduïts tipus castellà, amb infinitius).

En efecto, un tratamiento respetuoso, lo que en español solemos llamar “hablar de usted” quizá es demasiado formal para un sistema que busca ser “cercano” a los usuarios, una herramienta más familiar, menos acartonada.

Se ha fijado usted que en las traducciones al español, los programas suelen hablarnos de usted, como si fuésemos señores o viejos. A poco no le gustaría que las máquinas le hablasen de tú, con respeto digo, pero sin insinuar edades. Nomás tantito igualados.

El segundo punto me llamó más la atención, dice Aljullu que en aquellos lugares donde nosotros le “hablamos” a la máquina, o sea, en los botones (llamados por algo: botones de comando, o sea, para dar órdenes), el tratamiento debe ser, precisamente, imperativo.

En las traducciones al español, ya se habrá percatado usted, avispado lector, que los programas suelen hablar en infinitivo, lo que no deja suficientemente claro que la máquina está allí para escucharnos y obedecernos. Quizá la confusión proviene, como provienen muchas otras, de que en inglés, el infinitivo y el imperativo son usualmente iguales.

No preferiría usted que el menú de Archivo dijese “Guarda” en lugar de “Guardar”. El imperativo le deja muy claro al usuario que ha dado una orden y que la responsabilidad de realizar la tarea es de la máquina. El infinitivo, en cambio, no nos indica quién o qué ha de realizar la tarea, ni siquiera es claro que hay que hacer algo, es como si usted le dijera a un amigo con el que va caminando por la calle “dar la hora”, ¿cree usted que su amigo lo va a mirar de lo más natural y le va a decir, como si tal cosa “son las cinco y cuarto”?

Personalmente prefiero el estilo “usuario mandón”, y en la medida de lo posible, de hoy en adelante trataré de hacer que los programas que programo le hablen de tú a los usuarios y que estos den órdenes al sistema. Una justa reivindicación a los usuarios.