Programación artesanal

Programar es un arte. La persona que se dedica a esto debe ser alguien con mucha creatividad y pasión por lo que hace.

Debe plasmar en código lo que el cliente le solicita y ser tolerante a la frustración en caso de que su pieza maestra no salga según lo esperado (o sufra cambios durante el proceso de creación). Al final, si todo sale como lo planeado, ese producto final podría ser digno de mostrarse en un museo.

Programar, en palabras de Roque Rueda, es un proceso artesanal.

Roque Rueda es un ingeniero en tecnologías computacionales, con maestría en Desarrollo de Software con orientación profesionalizante. En su amplía experiencia laboral como desarrollador ha ido perfeccionando sus técnicas de codificación, implementando también las buenas prácticas de programación y metodologías de trabajo conocidas. Sin embargo, él aún considera que le hace falta mucho por aprender y conocer. No es una persona que se queda estancada en un solo stack (conjunto de tecnologías). Siempre está en constante actualización.

Como parte de la serie de entrevistas sobre ingeniería de software, Sólo es Ciencia comparte con ustedes la siguiente entrevista, donde Roque nos platica un poco acerca de su experiencia profesional y nos habla también sobre los retos y problemas que los developers (desarrolladores) enfrentan constantemente en su trabajo.

Como en todas mis entrevistas, conservo fielmente las palabras expresadas por los entrevistados, solamente dándoles forma a sus ideas, sin perder el contexto original.

Disfrútenla.


Armando (ArCiGo, A): Roque, recuerdo que hace tiempo me platicaste que aquí en México muchas empresas consultoras de software no implementan las buenas prácticas de programación, técnicas de desarrollo, metodologías ágiles, administración de proyectos y análisis y toma de requerimientos de software. Prácticamente no saben como desarrollar un buen producto.

_DSC8604
Fotografía: Juan Carlos Saracho

Roque (R): Yo pienso que el problema son los developers, oséase nosotros, la gente que desarrolla software, porque no somos disciplinados -para empezar-. Eso se ve reflejado en la calidad del software que entregas. Yo atribuyo este problema a varios factores.

He estado en proyectos en los cuales la aplicación inicia desde cero, y también en aquellos en los cuales hay que darle mantenimiento a la aplicación. Entonces, cuando vas a darle mantenimiento a una aplicación, es cuando vas a detectar problemas ocultos en cuanto a cómo va a escalar la aplicación y las reglas de negocio que pueden cambiar. Mucho de esto tiene que ver con el conocimiento que tienes como desarrollador. La mayoría de las personas con las que he trabajado son demasiado brillantes, pero no pueden visualizar todos los escenarios que va a cubrir una aplicación desde el inicio.

Sobre los otros puntos que mencionaste (técnicas de desarrollo, metodologías ágiles, administración de proyectos y análisis y toma de requerimientos de software) tienen que ver mucho con una metodología de diseño llamada Waterfall (Cascada).

Hace tiempo se juntaron algunas personas para definir un estándar o metodología de trabajo acerca de cómo desarrollar una buena aplicación, y en base a los resultados de sus trabajos e investigaciones salió el modelo de Waterfall. Sin embargo, eso en la vida real no sirve. Si tú buscas el paper (publicación) donde se presenta éste modelo, líneas más adelante, después de la imagen del modelo, leerás que los proyectos que usan esa propuesta están condenados.

Muchas personas, por no querer darle scrolling down (bajar) al paper, piensan que el desarrollo de software lleva las fases que comentaste al inicio, y realmente no es así.

Puedes tener requerimientos incompletos durante el desarrollo de la aplicación y personas que no sean expertas en la(s) tecnología(s) que se aplicará(n) en el producto.

Sobre las buenas prácticas, primero debemos definir que es una buena práctica.

Muchas «buenas prácticas» que tenemos los developers son vicios que tenemos de desarrollos previos.

_DSC8603
Fotografía: Juan Carlos Saracho

Hay demasiados factores que hacen que un producto no sea el esperado: Tiempo, recursos del proyecto, poca disciplina por parte de los developers, desconocimiento de la(s) tecnología(s) a usar, etcétera. Todo esto hace que el desarrollo de software sea muy caro y complicado.

Los que construyen el software deberían tener todo el conocimiento requerido, para poder implementar una solución lo más apegado a lo que el cliente quiere -o al menos asegurarse de eso-, pero en la realidad no sucede.

A: Sobre la metodología de trabajo de Waterfall, yo lo veo como algo utópico, algo imposible de seguir al pie de la letra por los diferentes factores que pueden alterar el desarrollo del producto.

Recuerdo que un amigo tester (probador) me decía que tiene un amigo que está enamorado de las metodologías ágiles, especialmente de Scrum, y éste le decía a él que había que seguirlas al pie de la letra. Cuando mi amigo me platicó de eso, me saqué de onda porque sé que no existe un Scrum perfecto, y cada empresa tiene sus variaciones. Mi amigo también piensa igual que yo. Y ahorita que te escucho hablar sobre los errores en los que llegamos a caer por querer confiar en una metodología o estándar de desarrollo, confirmo lo que quizá medio mundo sabe sobre metodologías de desarrollo de software…

_DSC8619
Fotografía: Juan Carlos Saracho

R: Vámonos por partes…

Tenemos diferentes formas de desarrollar software: tradicionales, que son las iterativas e incrementales, y las ágiles.

Cuando se crearon las agile methodologies (metodologías ágiles), las personas involucradas en el proceso de creación dijeron «Vamos a preferir la interacción humana sobre los contratos», «Vamos a preferir software funcional sobre la documentación exhaustiva»… definieron varios puntos importantes en el famoso Agile Manifesto (Manifiesto Ágil), pero si tú lees el manifiesto te encontrarás con que en ningún lado dice que no hagas documentación, lo cual es un mal entendido que tienen muchas personas al querer intentar implementar esta metodología. Tienes que hacer documentación, y como desarrollador ágil tienes que ser aún más disciplinado y dar un status (estado) de tu situación actual en cierto tipo de juntas que deben llevarse a cabo.

Mencionabas que no hay un Scrum perfecto… Ok, Scrum no es perfecto, ni tampoco una receta para la felicidad. Tú vas a tener una serie de ceremonias (juntas), actividades, documentos, boards (tableros), backlogs (reservas), etcétera, pero todo esto es en base a métodos empíricos (en base a la experiencia). Tú tienes que tomar o quitar aquellas cosas que funcionen para ti. Y puede que en esto último entres en conflicto decidiendo cuáles cosas tomar y cuáles no, o quién te indica si lo que tomaste o quitaste fueron las cosas más adecuadas. Nadie te lo va a decir, tú tienes que hacerlo. Puedes hacerlo validándolo con un proyecto en donde se sigan las prácticas adecuadas, o en uno en el que no, y en el siguiente sprint (fase) ajustar lo que tienes actualmente.

Sin embargo, no por el simple hecho de implementar esta metodología significa que tendrás éxito en el desarrollo de tus productos…

A: Entiendo, entiendo. Cambiando un poco el tema, ¿qué tan importante consideras que las personas aprendan, o sepan programar?

R: Pues como dijo Steve Jobs «Todos deberían aprender a programar».

_DSC8611
Fotografía: Juan Carlos Saracho

En general, sea niño o niña, si sabe programar sabrá desarrollar ideas, y esto es muy bueno. El saber no hace daño.

Ahora, es complicado saber programar… Es difícil saber cómo declarar variables, constantes, funciones, clases, objetos, etcétera. Estaría padre que todos supieran.

Si se te llega a presentar un caso donde alguien no quiere aprender a programar, es aceptable y es normal, no tienen por qué aprenderlo. Sería muy bueno que lo supieran porque entonces ellos entenderían que el desarrollo de una aplicación implica partes muy complicadas y que también consume tiempo en lograr uno o varios objetivos.

También hay casos en los que puede haber personas que no tienen por qué tener relación con el código. Una persona que te pida una aplicación de lo que sea en Android pues no necesariamente tiene que saber programar. Te pasará los requerimientos de lo que él o ella necesita y tú desarrollas la aplicación. Para eso te está contratando.

En esto último es donde entran los soft skills (habilidades blandas), donde se tienen que trabajar las partes de comunicación verbal y oral, formas de expresarse y escuchar, interacciones personales, modales, etcétera, y así entender lo que el cliente realmente quiere. Muchas veces en un proceso de comunicación va a ver un emisor y receptor. El emisor puede emitir un muy buen mensaje, pero el receptor puede que no capte nada de lo que se está diciendo. O, puede haber un emisor que dé un mal mensaje, pero puede que el receptor entienda adecuadamente lo que el emisor quiso decir.

Yo diría que programar es una actividad social. Esto hay que entenderlo, y por ende los soft skills son demasiado importantes, más que cualquier habilidad técnica. Si tienes buenas habilidades sociales, y manejas bien la parte de la inteligencia emocional, creo que eres mejor jugador en un equipo de desarrollo de software.

Para concluir, me atrevo a decir que esto del desarrollo de software es un proceso artesanal, porque el proceso es ejecutado por personas, y si tú no tienes una buena comunicación tu proyecto puede llegar fracasar. Por eso digo que es artesanal.

Puedes tener muchos IDEs (Integrated Development Environment, Entorno de Desarrollo Integrado) y cosas automatizadas, pero nada de esto te va a ayudar si tus developers no tienen la suficiente interacción con el cliente o con los demás miembros del equipo de desarrollo. Por eso repito que desarrollar software es un proceso artesanal.

A: Ya para finalizar, ¿crees que el desarrollo de software va a dejar de ser artesanal?

R: Sí, va a dejar de ser artesanal.

La computación es una ciencia* reciente. ¿Qué va a pasar en algún punto? La gente empezará a hallar, como en cualquier otra ciencia, los métodos y las buenas formas de llevar a cabo un proyecto, y poder estimarlo adecuadamente.

Creo que uno de los grandes retos en los cuáles debemos enfocarnos es en el de la estimación de un producto/proyecto o soporte de una aplicación. Cualquier tipo de estimación relacionado a software es complicado. Si tú puedes hacer algo relacionado en esa área, yo considero que ya estás creciendo como developer, como ingeniero de software.

Yo no me atrevo a decir que soy un ingeniero de software, a pesar de que el título que tengo en donde me contrataron diga lo contrario. Yo me considero simplemente un escritor de código.

A: Perfecto. Muchas gracias, Roque, por tu tiempo, y espero que sigas creciendo profesionalmente.

R: No hay de qué. ¡Saludos!

_DSC8601
Fotografía: Juan Carlos Saracho

Notas.-

* La computación no puede considerarse como ciencia (aún). Para más información, léase el artículo Is Computer Science Science?, publicado en la revista Communications of the ACM en abril de 2005.

____________________________________________________________
Sigue a Sólo es Ciencia en: Facebook, Twitter y LinkedIn
¡No olvides seguirme en Twitter!: @ArCiGo

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 )

Google+ photo

You are commenting using your Google+ 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 )

Connecting to %s