¿Te ves como un verdadero profesional?

Tanto se los he dicho que ya están empezando a darse cuenta de que realmente no entienden las necesidades del negocio. Al parecer ellos se meten en la programación desde chiquitos y el mundo se les achica tanto que no comprenden que hay compromisos asumidos y que el cliente está esperando el producto. Pero bueno, yo sigo explicándoles y varios lo entienden bien pero hay un par que verdaderamente no parecen estar muy convencidos.

Lo peor de todo este asunto es que cada vez trabajan más lento y cada vez peor. Yo no sé que les pasa. Justamente la semana pasada los reuní para hablar de este y otros temas pero no pude lograr mucho. Yo quería entender que era lo que les estaba pasando y en lugar de eso volvieron a salir los mismos temas de siempre; sobre todo el que “el código es un asco”.

Yo les dije: señores, al código lo escribieron Uds. no sé que puedo hacer yo al respecto. Es más, me dicen que aquello por lo que les he estado pagando todos estos meses, es un asco?  Fue entonces cuando uno de los programadores me dice que en gran medida los problemas se deben la falta de tiempo para hacer las cosas bien y que esa falta de tiempo era debido a la cada vez mayor presión que yo ejercía sobre los plazos para entregar o mostrarle resultados al cliente.

Si si, parece increíble pero eso fue exactamente lo que me dijo. Y parecía existir cierto consenso por parte del resto en cuanto a ese parecer. Nuevamente les dije: señores, yo no sé cuanto tiempo requiere hacer tal o cual cosa y es justamente por eso que les pido una estimación para presentarle a los clientes. Lo que sucede es que una vez que se lo presento a un cliente, deja de ser una estimación para convertirse en un compromiso.

“Claro!” dijo Carlos, “lo que pasa es que muchas veces para cumplir con un compromiso uno tiene que resignar algo y ese algo se llama calidad”. Miren muchachos! –les dije – ¿qué pensarían Uds. si contrataran a un albañil para que les construyera una pared y él, para terminarla en plazo, la hiciese sin cimientos, cruzada, inclinada y llena de orificios?. Seria verdaderamente inadmisible ¿cierto?. Pero si es inadmisible en el caso de un albañil, en el caso de los programadores debería de ser mucho más aún. ¿No les parece? – pregunté.

———————————-  Fin.

Macho-Driven Development

Un verdadero macho programador puede escribir scripts en Ruby o en algún otro lenguaje elegante y sofisticado pero siempre preferirá un verdadero lenguaje de programación, aún para hacer una simple suma, uno en el que pueda usar punteros y operar con bits. Y es que todos sabemos que los punteros y los bits son absolutamente de machos.

Tampoco les agrada mucho la idea de TDD (y muchísimo menos de alguno de sus primos mas coquetos, como BDD), porque un buen programador programa, eso es lo que hace. Las pruebas las deben hacer los testers y los testers, como todo el mundo sabe, son en su mayoría mujeres.

Ni que hablar de esas extrañas prácticas como la de programar de a dos! Que es eso de sentarse juntos y compartir un teclado como dos tontos?! Encima, el limpia vidrios del edificio de seguro los miraría con cara inquisidora. Ni que hablar! Eso tiene que ser menos productivo definitivamente.

El verdadero macho programador tiene una cualidad distintiva: es el que hace que el código ande. Otros, por el contrario, siempre están discutiendo aspectos estéticos como los nombres de los identificadores, el tamaño de los métodos, patrones y toda clase de minucias que solo retrasan el proyecto y no agregan ningún valor para el cliente.

Este programador es pragmático al 100%, si el problema puede solucionarse mediante una bandera y un par de instrucciones goto, él se anima a hacerlo. Esto es lo que los clientes quieren y lo que los gerentes quieren, pero los programadores menos machos prefieren perderse en sus ñoñeces y a lo único que atinan es a culpar a los machos de todo bug que anda  dando vueltas.

Pero si la cualidad por la que se destacan frente los clientes es por hacer las cosas, y rápido; por lo que sobresalen realmente en su interior es por su absolutamente excepcional creatividad. Esta es la que parece que toda la organización intenta extirparle. Esto lo hacen tratando de restringir su libertad creadora mediante sumisión a estúpidos estándares de programación, revisiones de código, pruebas unitarias, programación de a pares y en casos extremos, hasta con auditorías para ver si el nombrecito del archivito era correcto y estaba en la carpetita que debía estar.

Creo que ya está bueno de estos machos creativos. No se puede permitir que cada uno programe como se le dé la gana. Esta es una profesión y por lo tanto debe ejecutarse en forma rigurosamente profesional, realizando el trabajo según los “protocolos” conocidos.

Los preconceptos y las miradas ideológicas sobre tales o cuales tecnologías no puede tener cabida en nuestro ámbito. El antiguo pensamiento de “mi lenguaje es mucho mejor que ese otro”, además de antiguo es infantiloide pero aún persiste. Da avergüenza ajena cuando se lo escucha.

En cuanto a ese lado artístico, he conocido muchísimos desarrolladores que se consideran a si mismos como artistas, en algunos casos se perciben como grandes artistas, y la verdad es que están bastante fuera de lugar. Todos en nuestro interior tenemos algo de artistas, eso es definitivamente muy bueno. Lo que no es bueno es que lo volquemos al código.

TDD – Un ejemplo de la vida real

Tengo que hacer un sistema de autorización para un sistema algo complejo y me pareció que sería bueno mostrar como se programa/diseña mediante TDD (Test-Driven Development) por lo que gravé las sesiones. Espero que les sirva.

(TDD – Ejemplo) Security Access Control 1/X from lucas ontivero on Vimeo.

(TDD – Ejemplo) Security Access Control 2/X from lucas ontivero on Vimeo.

(TDD – Ejemplo) Security Access Control 3/X from lucas ontivero on Vimeo.

Continuará….

[MISC] Desarrolladores y testers despreciables

Muchas veces he presenciado actitudes que rayan con lo inverosímil, actitudes intolerables, actitudes éticamente reprochables.

Gente que simula estar trabajando, gente que no termina con una tarea para que no le asignen una nueva, gente que sobreestima el esfuerzo de sus tareas de una manera descarada, gente que reclama capacitación sobre cualquier trivialidad, gente que sobredimensionada sus asignaciones y las reporta de una manera sumamente compleja, llena de impedimentos, de dificultades técnicas inexistentes y un enorme arsenal de excusas que le permiten ocultar su ineptitud y falta de voluntad a la vez que los hace parecer sumamente profesionales y sacrificados.

¿Cómo es posible’?

Las causas pueden buscarse en la propia gente y en la cultura de la organización, pero fundamentalmente en el control. En mi primer trabajo tuve un jefe muy técnico, era quién sabía que se debía hacer, como debía hacerse, quienes podían hacerlo y cuánto esfuerzo podrían requerir las tareas. Todo el equipo trabajaba junto en una misma oficina por lo que él sabía exactamente qué estaba haciendo cada uno, como lo estaban haciendo, si existía algún problema técnico y si el proyecto se retrasaría o no. Recuerdo que por aquellos días sentía una leve, pero constante, presión sobre mí ya que con frecuencia me preguntaba: «¿y pibe cómo vamos?», «¿cuánto falta?», » ¡ocho horas para esa boludez! ¿o sea que en todo el día de hoy sólo vas a hacer eso?».

Aparte de todo eso me sabía decir: “¡Por Dios, probá el codigo antes de subirlo a producción!», y la más dura de todas: «me imagino que habrás hecho un backup… ”. Sí, yo era muy junior y un talibán de los scripts pero lo realmente importante, independientemente del resultado de los proyecto, era que él era el responsable de que el trabajo se llevara a cabo. Además, no sólo presionaba sino que también tiraba del equipo y en mi caso, me enseñaba. Este fue mi modelo de tracking hasta que tuve un jefe puramente administrativo. Entonces descubrí un mundo nuevo, un mundo de descontrol, un mundo donde el gerente estaba indefenso ante las mentiras de los desarrolladores y de los testers.

Scott Adams vio esto antes que yo y creó a Wally y su Wally Report con las mentiras de las que hablo y he sido testigo.

Lucas Ontivero

Productividad

Que es la productividad?

Uno de los mayores problemas a la hora de hablar de productividad es definirla en términos útiles y que sean fácilmente entendidos y compartidos por todos. Todavía es posible encontrar gente que la expresa y la entiende como líneas de código sobre unidades de tiempo invertidas aún cuando carezca de toda lógica. Esto ocurre porque para calcularla se utiliza la fórmula clásica de productividad:

productividad = unidades / recursos

En la cual interviene el concepto de unidades producidas, pero ¿qué es una unidad de software? Muchos consideran que el tamaño del software puede medirse mediante líneas de código (LOC) y tienen sus buenas razones, difícilmente una aplicación de 10.000 LOCs pueda ser mayor a una de 500.000 LOCs. Pero esta unidad únicamente sirve a efectos comparativos a niveles macro como el que acabamos de ilustrar y no nos dicen demasiado cuando bajamos a escalas mucho menores. Por ejemplo, si para programar una cierta funcionalidad, un equipo requiere 1.000 LOCs y 100 horas/hombre y otro equipo requiere 7.000 LOCs y 100 horas hombre, ¿podríamos afirmar que el segundo equipo fue siete veces más productivo que el primero? ¡Por supuesto que no! Ambos equipos construyeron una misma solución en un mismo tiempo, pero tampoco podríamos afirmar que son igualmente productivos ya que las 7.000 LOCs son muchas veces más difíciles de mantener que la 1.000 del otro equipo.

La ecuación tradicional de productividad nos habla acerca del costo de desarrollar una pieza de código para implementar una cierta funcionalidad pero nada dice acerca de los costos futuros de mantenimiento de las mismas, y en software, el mayor costo está relacionado al mantenimiento de las aplicaciones. Entonces, necesitamos agregar la calidad a la ecuación para tener un panorama más realista y económicamente acertado. De no hacerlo, y si consideramos el tamaño del software en función del número de líneas de código que se necesitaron para escribirlo, caeremos en la trampa de creer que el segundo equipo fue realmente 7 veces más productivo que el primero.

Lucas Ontivero