¿Por qué usar inglés en proyectos de software?

Pocas cosas me incomodan más en mi trabajo que ver un proyecto en spanglish, es decir, con partes en inglés y otras en español. La naturaleza del origen de la mayoría de la tecnología moderna hace que el inglés sea la «lingua franca» entre ingenieros, particularmente entre los que desarrollamos software, sin embargo, en México en particular, parece existir un complejo de identidad que no nos permite decidirnos por uno o por otro, o peor aun, mezclarlos terminando con resultados que dan pena.

Amo el español. Es una de las lenguas más ricas y románticas. La lengua de Cervantes es en definitiva compleja y extensa lo que la hace perfecta para todo tipo de expresiones artísticas como la poesía, la literatura y el canto. Una de las razones por las cuales escribo este blog aun en Español es precisamente mi gusto por dicha lengua y porque finalmente mi (poca) audiencia creo que se siente más cómoda leyendo en Español.

Pero resulta que también me encanta el inglés! Haber nacido y crecido en la frontera norte en México es una bendición ya que absorber el lenguaje de nuestros vecinos del norte es a veces algo casi natural. Salvo las clases paupérrimas de inglés que recibí en la escuela tanto en secundaria como en preparatoria, no tengo ninguna educación formal en dicho tema. Mis maestros, como les comento a quienes me preguntan dónde aprendí, fueron las caricaturas de los canales locales de Fox que obviamente estaban en inglés y el closed caption. Hartar a compañeros de escuela y familiares preguntándoles que significaba esto o aquello también me ayudó y finalmente, el venerable traductor, en papel claro está.

Equipo Mexicano… cliente Americano

Aunque al inicio de mi carrera no podría decir que dominaba el inglés, tenía suficientes armas para defenderme. Viajar por cuestiones laborales y también familiares y no poder hablar mas que inglés es la mejor práctica que pude tener. Otra de las ventajas de quienes hemos trabajado para compañías transnacionales o bien haciendo off-shore a compañías o startups norteamericanas es precisamente ese requerimiento.

La mayoría de las juntas y llamadas durante esa etapa, por obvias razones, han sido en inglés, y como es de esperarse, la definición de los requerimientos, los «boards» de SCRUM o Kanban y cualquier otra herramienta de administración de proyecto en general era con contenido en inglés, la lengua del cliente. Es obvio que en este caso el cliente dicta no solo la tecnología sino el lenguaje de comunicación y es de hecho una de las ventajas que tenemos los programadores mexicanos, particularmente los que vivimos al norte; un entendimiento de la cultura y manejo del idioma.

Incluso a veces he ido más allá de los documentos y las llamadas. En repetidas ocasiones, cuando nos visitaba el cliente en la oficina de México, les pedía a mis compañeros de equipo (siendo yo el project manager o technical lead según el caso) que por favor solo hablaran en inglés mientras estábamos con el cliente ya fuera en sala de juntas o discutiendo temas del proyecto. Más que una razón técnica tiene que ver con el respeto, el respeto de mostrar interés en que nuestro cliente entienda de lo que estamos hablando y si para ellos es fácil comprender en su propio idioma y para nosotros es fácil hablarlo pues que mejor. Hay quienes encontraba hasta cierto punto incómodos con esta situación pero repito, es una cuestión de respeto hacia el cliente.

Equipo Mexicano… cliente Mexicano

Este caso es muy particular ya que en realidad no tenemos necesidad alguna de dominar el inglés, o eso pareciera. También he tenido oportunidad de trabajar en compañías 100% mexicanas, de producto, donde sus clientes son también mexicanos, entonces, ¿Cual sería la ventaja del inglés en este caso?

La verdad es que poca. Podría decir que hasta prefiero que la comunicación sea en español. Es más natural. Sin embargo, existen ciertos escenarios donde el español parece quedarse corto o simplemente parece no «cuadrar» con lo que estamos haciendo. Por ejemplo, en un par de empresas donde trabajé toda la documentación, llamadas, juntas y recursos en general estaban definidos en español, pero, cuando se trataba de código teníamos cosas similares a esta:

public class Cliente
{
 public int ClienteID {
 get;
 set;
 }

public string Nombre {
 get;
 set;
 }

public string Status {
 get;
 set;
 }

public List<Cliente> GetClientesByStatus(string status) 
 {
 
 }
}

Como se puede ver la mezcla entre inglés y español vuelve la legibilidad del código más complicada de lo necesario. Esto es solo un extracto de prueba pero había en toda la aplicación código como este que pareciera que algún cholo del este de Los Ángeles  escribió.

El problema para algunos, o ventaja como lo veo yo, es que casi todos los lenguajes de programación fueron escritos en inglés, es decir, la sintaxis natural de estos lenguajes utiliza keywords en inglés como if, for, while, next, define, etc. Incluso algunos lenguajes como Ruby tienen la característica de ser más similares al léxico humano que al de una computadora. En las propias palabras de los creadores de ruby:

It has an elegant syntax that is natural to read and easy to write.

Y si vemos un pequeño bloque de código de ruby lo entendemos:

10.times do |number|
 puts "Number #{number} is pair!" unless number.odd?
end

El código anterior es explicable casi por si solo, sin necesidad de ser programador uno mas o menos entiende que es lo que va a hacer. La belleza de la lengua de Shakespeare es precisamente la simplicidad para conjugar. Imaginen si Yukihiro Matsumoto, creador de Ruby y de nacionalidad japonesa hubiera decidido diseñar la sintaxis de Ruby en Japonés… Creo que no hubiera tenido el éxito que ahora tiene.

¿Entonces?

No existe una regla escrita para los idiomas en la administración de proyectos de software. Dicho eso, creo que lo más saludable es simplemente utilizar inglés en todas las áreas técnicas del proyecto, por las siguientes razones:

• Lenguaje común para términología
• La mayoría de las personas que saben dos idiomas dominan el propio y su segundo lenguaje es el inglés
• Términos a veces difíciles de traducir (embebido, deployado, limpiador)
• Permite a los miembros del equipo mantenerse frescos en su segundo idioma, practicándolo día a día
• Potencial integración a futuro de miembros extranjeros, consultores externos o incluso salidas a un mercado diferente al de habla hispana
• Congruencia y claridad en el código y el nombramiento de elementos, variables, métodos, etc.

Un aspecto a considerar es que estamos hablando de la comunicación, documentación y almacenamiento de información TÉCNICA del proyecto. Se entiende que si somos, por ejemplo, una empresa mexicana sirviendo clientes mexicanos, la documentación de usuario como manuales, sitios de soporte, branding y demás debería estar en español. Mejor aun, podemos ir un paso mas allá e internacionalizar nuestras aplicaciones, de manera que el idioma base de la aplicación es el inglés, como idioma técnico universal y posteriormente «localizar» nuestro software en español.

Otra de las ventajas de estandarizar el inglés en nuestros proyectos de software es el uso de herramientas que quizá no estén traducidas al español o donde las traducciones sean pobres, por ejemplo, si utilizamos Trello, JIRA, Pivotal Tracker, etc. Muchas de estas herramientas esenciales para el mantenimiento de proyectos de software no cuentan con una versión en español lo cual, de nuevo, hace ver el contenido en una «mezcolanza» difícil de digerir.

Creo que usar inglés para manejar nuestros proyectos de software no solo es positivo desde la perspectiva técnica sino que además promueve el uso de la lengua entre nuestros compañeros de trabajo de manera que se mantengan frescos y con práctica en el mismo, especialmente útil para los que no viajan seguido a Estados Unidos o  no tienen interacción continua con alguien de habla inglesa. Al final del día eso es lo que los programadores particularmente hacemos a diario; practicar lenguajes, pero de programación. Es la única manera de mantenernos vigentes.