Estos Programadores que No Cazan Una…

A la izquierda, el -hasta ahora- último libro
de David Platt. A su lado, la tercera edición
del libro presentación de .NET para arquitectos

 Acabo  de terminar de leer "Why Software Sucks… and What You Can Do About It" ("Por Qué el Software Apesta… y Qué se Puede Hacer al Respecto") de David Platt (Addison Wesley, 2007). Este Platt vive en Ipswich, Massachussets (Estados Unidos), por ende es sólo una coincidencia que se llame igual que el jugador del Manchester United y la selección inglesa

Platt, para los que no hayan tenido el gusto antes, es una suerte de Enrique Pinti de la Ingeniería de Software, en el sentido que logra comunicar verdades de nuestro quehacer diario en una forma muy pero muy graciosa (para los que viven en Chile, Enrique Pinti es el Coco Legrand argentino). Y al igual que después de ver a Pinti, al otro día de haber visto y oído a Platt sentís como cierta depresión: ya te decantó lo que te dijo el día anterior, ya lo procesaste y lo que te queda es una realidad amarga. Pero igual, a tomarse la vida con humor

Como muestra va este botón: ya en la introducción a "Introducing Microsoft .NET" (la edición en español se llama "Así es Microsoft .NET", Microsoft Press, 2003), el autor enuncia su "segundo lema de Platt", de la siguiente manera

"La cantidad de merda que anda flotando por ahí tiende a mantenerse constante. Si lograste sacarte una buena porción de merda de encima, es porque seguramente se estará enterrando en ella alguien más"

Te paso el contexto en que el autor enuncia este postulado: Platt estaba comentando la idea detrás del concepto de código administrado (managed code) por entorno de ejecucion de lenguajes común (Common Language Runtime o CLR) de la plataforma .NET, con facilidades tales como recolección de basura (garbage collection) de memoria liberada, chequeo dinámico de tipos (type checking) al asignar referencias a objetos (punteros, bah), etc. Platt estaba tratando de advertirnos que por mucho nosotros, como desarrolladores, no tuviesemos que meter líneas de código especialmente para eso, no quería decir que entonces esa lógica ni siquiera se iba a ejecutar. Sí que lo iba a hacer y en este caso es el CLR el ejecutor de esa lógica. La observación no es menor: que el recolector de basura desasigne toda la memoria liberada nos garantiza que no quedará memoria perdida (algo que en Lenguaje C o C++ era tan difícil de detectar que en la práctica se solía abandonar la búsqueda y, cada tanto, reiniciar la aplicación de manera que sea el sistema operativo el que se encargue de hacer borrón y cuenta nueva). Platt dice entonces que a pesar de esa garantía, si nos la pasamos creando objetos y luego quitándoles alcance (scope), si bien esa memoria se recuperará, el recolector de basura competirá con nuestra aplicación por el uso de la CPU. En otras palabras, el rendimiento general de la aplicación puede degradarse por el overhead agregado por el CLR

Casualmente mi post de la semana pasada hablaba de buenas y malas prácticas con mapeadores entre objetos y tablas relacionales (Object/Relational Mappers, u O/R-Ms). El segundo lema de Platt podría ser un post-mortem de ese post: por mucho que tu O/R-M esté haciendo ese mapeo que vos te querés evitar, ese mapeo ocupa tiempo (de ejecución) y espacio (en memoria, tanto de datos como de código). Ahorrarse de escribir código puede no estar excento de problemas de rendimiento

Si te estás preguntando qué podría llegar a decir el "primer lema de Platt", te lo paso al toque, y decime si en la práctica no es así:

"El tiempo total de duración de un proyecto es equivalente a tres veces la estimación inicial de duración del mismo, incluso si se había aplicado este lema al estimar"

"Por Qué el Software Apesta…" es ante todo una crítica a la autosuficiencia de los desarrolladores de software, haciendo aplicaciones que ellos créen que van a ser maravillas que el mundo les agradecerá por siempre, cuando en el fondo desde sus mismas interfaces de usuario están descuidados los más mínimos detalles de ergonomía y usabilidad. El autor cita ejemplos a la vista de todos: buscadores web, aplicaciones web para envío y seguimiento de encomiendas, una cadena de cafeterías, etc

Conversando con Paula, mi mujer, acerca de este libro –Pau es ingeniera de software también, y su especialidad está en normas y procesos, seguimiento y control de calidad (*)-, ella discrepó acerca del destinatario de esta crítica: en todo caso el desarrollador de software es un programador. No un experto en usabilidad. Sin invalidar que el software apesta, como señala Platt, Paula sugiere que en todo caso la dirección de desarrollo de estas aplicaciones debería considerar el rol de diseñador de interfaz de usuario -rol que debiera ser puesto en práctica por un experto en usabilidad-, de manera tal que los desarrolladores se encarguen de implementar sus lineamientos. No suena malo el exhorto de la receptora de mis desayunos diarios (**)

La realidad es que cuantos más expertos le agregamos a un proyecto (seguridad, acceso a datos -el DBA, bah-, ahora usabilidad) es probable, o sea no posible sino probable que pase efectivamente, que la complejidad del proyecto sea mayor y por ende el plazo de entrega. Pero en función de la calidad de los resultados es algo que no debe dejar de considerarse (lo digo y me viene a la memoria un proyecto en el que trabajé allá por el 2001, que ya tenía plazo de entrega prefijado -y de hecho si nos demorábamos, por una cláusula contractual, el cliente tenía derecho a pagar menos por el producto terminado en función de la demora-, cuestión que allí teníamos un experto en usabilidad, para ello posgraduado en el MIT, que sugería que el usuario ingresara localidades de la Argentina mediante clicks en un mapa de dicha república. Claro, yo era el programador así que me comía las uñas de escuchar esas ideas, seguramente geniales, si codificarlas dependía de mí y en plazos aceptables. Afortunadamente el cliente rechazó esa idea ya que varias localidades caerían de la escala del mapa, además que aún haciendo drill down de áreas de todas maneras requeriría de precisión de parte del usuario, además que alargaría la distancia de los clicks respecto de ingresar la localidad de una lista descolgable -de todas formas, inmensa-)

Quizás otra solución sería introducir en los planes de estudio de las carreras, nociones de usabilidad. Aunque no creo que esto no se esté haciendo ya y, de todas maneras, no sería suficiente ya que la Usabilidad como disciplina -si bien conlleva mucho de sentido común- no es algo que se pueda adquirir en una materia de la facu. Poner más materias de usabilidad no sería solución: los planes de estudio ya son lo suficientemente complejos y las especialidades también muy variadas como para poner tanta presión sólo en una de ellas

Si de otras disciplinas se trata, el libro se completa con los endebles mecanismos de seguridad que los desarrolladores ponen en el código creyendo que los hackers se van a dejar intimidar por un par de contramedidas. De nuevo, mi postura al respecto es coincidente con la de Platt en cuanto a que tenemos un déficit allí. Sin embargo descreo que sea realista y/o pragmático esperar que el desarrollador sea el experto capaz de tacklear esa amenaza. Más bien me muestro partidario de someter a la aplicación en vías de desarrollo, a revisiones (walkthroughs) de seguridad, aplicando por ejemplo las checklists que el comité de Patterns and Practices puso a nuestra disposición años atrás; eventualmente con la herramienta para modelado de amenazas que mencioné en el Boletín Oficial de Arquitectura #1

Como sea, no le resto seriedad a Platt en cuanto a los puntos grises del software, desde el punto de vista de quienes lo usan (usamos). Platt no se conforma sólo con culpar a los desarrolladores (los geeks u homo-lógicos, como se los llama hoy a los otrora conocidos como nerds de las ciencias de la computación). Particularmente en el capítulo 5 la crítica es más bien para el usuario, y su positivismo de que en realidad a nadie le interesa recolectar información de uno mismo (realizando, de esa manera, transacciones bancarias por Internet sin tomar recaudos de que su contraseña pueda viajar no encriptada, o que por su dirección IP, la que le asigna el proveedor de banda ancha, se puede reconstruir la historia de todas las cosas que anduvo buscando por Internet, sitios de niñas ligeras de indumentaria que visitó -incluyendo particularmente en cuáles de ellas se detuvo para conocer mayores detalles-, así como la eliminación de esas barreras que el sistema operativo pone por defecto a todo elemento sospechoso que pueda llegar al navegar por la web -entre ellos, aplicaciones que entran de polizón-). A mí me consta, yo tengo amigos que -sólo voy a citar uno de los innumerables casos que conozco- entregan su usuario y contraseña de Hotmail a esos programas que hay en la web que le ofrecen a uno, a cambio, ubicar quiénes nos borraron del Messenger (hoy Windows Live Messenger). Si sos de la partida, escuchame una cosa gil de estopa: al revelar tus credenciales a estos "buena onda", ellos entran al servidor de Messenger con lo que vos le habilitaste, se hacen de tu lista de contactos (en donde salimos nosotros, turro! Gracias por vendernos) de manera que desde tu cuenta nos mandan mails con SPAM y otros "servicios" no solicitados, a los que nosotros como incautos podemos pisar el palito dado que el mail nos llega enviado… desde tu cuenta, nabonga

Más aún, sabés que estos tipos después venden (sí, cobran plata por ello) tus credenciales a terceros que a su vez hacen lo mismo? Y como pueden entrar a tu correo, eventualmente pueden tomarse la molestia (total que pueden perder) de revisar si vos no te mandás a vos mismo alguna credencial -por ejemplo de tu banco en línea, no sea cosa que te la olvides; o eventualmente ver si no estás recibiendo mails de confirmación de algún servicio que sí hayas comprado, de manera de conocer tus hábitos de consumo y así ofrecerte otros-. Claro, con todo puede pasar que no te moleste si eso es así. Pero por lo menos, si me tenés en tu lista de contactos, no des acceso a mí tan fácil

En definitiva, el libro de Platt habla de todos estos vicios que como desarrolladores y como usuarios cometemos. Él es mucho más gracioso que yo para contarlo, y no por eso menos realista. Platt, además, es un confiado de que el software que apesta se puede mejorar, y te ofrece casi al terminar una serie de iniciativas para que seas vos mismo el que impulse, de la gente que te provea software sea quien sea ésta, que lo mejoren. Platt dedica especial atención al caso Microsoft, compañía ésta que despierta algo de admiración por la posición dominante que logró alcanzar y mucho de rechazo por la misma razón. Platt señala cómo Microsoft hoy está cambiando, al sentirse amenazada por los titanes que van surgiendo y se han ganado sus propios sitiales de privilegio, sino que además amagan despojarla de sus antiguas conquistas (el Internet Explorer como navegador más usado; el Office, etc). Platt no ahorra críticas al gigante del software, sin embargo separa lo que es el antagonismo justificado y constructivo de un mejor rol que Microsoft puede jugar -tanto allí donde aún lidera como en aquellos segmentos donde claramente va a la saga-, de lo que es mera crítica olvidable (e improductiva)

De esto último, Platt también menciona casos de antagonistas ocasionales de la compañía de Redmond, con estrategias que en apariencia iban a ser irresistiblemente adoptadas y a la vez iban a permitir que no siga pasando que la mayor parte de los computadores corra el sistema operativo de uno sólo de los oferentes. El autor hace un balance de las consecuencias de esas estrategias… y en algunos casos de los que pisaron el palito y se subieron

También hace un reconocimiento -capítulo aparte- de que a Microsoft solemos pegarle en la modalidad "palo porque bogas, palo porque no bogas". Coincido nuevamente con Platt: hace poco Pablo, un viejo amigo mío de la época en que ámbos integrabamos el llamado "Club OS/2" impulsado por IBM Argentina -no me creés? Pucha que sos cabeza dura: entrá acá-, me comenta "estoy metido a full con AJAX, le tengo mucha fé a esa tecnología. Claro, no creo que vos puedas decirme nada al respecto: Microsoft ni apoya ese estándar, para variar"

Le comento que Microsoft una semana antes habían liberado en forma gratuita la versión 1.0 de ASP.NET AJAX a lo que me responde "claro, como ven que puede generar interés, liberan una herramienta gratuita para que todos los giles se metan, total es gratis, y así Microsoft después los vaya tirando de nuevo a su plataforma"

Criticar a Microsoft porque regala algo (sea ASP.NET AJAX, sea las versiones Express de Visual Studio) contrasta con la crítica que se le hace por vender otros productos (tal el caso del Office, el Windows mismo, etc)

Volviendo a mi amigo Pablo, su sorpresa fue desagradable cuando le comenté que en realidad la tecnología AJAX surgió de una antigua facilidad incorporada por Microsoft en su versión 4 de Internet Explorer: el agente XMLHttpRequest. Su primera reacción fue de incredulidad. Pero cuando le mostré sitios que respaldaban que los orígenes de AJAX se remontan a Microsoft, me dijo "lógico: lo hicieron para romper estándar con Netscape y hacerse así del mercado de los navegadores"

En síntesis, como dice Platt, "palo porque bogas, palo porque no bogas"!! (damned if you do, damned if you don’t): al principio Pablo criticaba a Microsoft por su presunto "no querer subirse a algo al que el resto de la industria se subía". Minutos más tarde, convencido de que esto era falso y que Microsoft había sido en todo caso el innovador, su crítica se había transformado en "monopolizador que se abusa de su posición de privilegio para anular toda chance de competencia". Quedamo así, Pablito… suerte con OS/2 (que, dicho sea de paso, las primeras versiones las hizo Microsoft a pedido de IBM)

Platt está presentando su libro en forma viral -te anticipo que va a dar un chalk talk en el próximo TechEd de Orlando-. Recientemente ofreció un keynote de unos cuarenta y cinco minutos basados en el contenido del libro. Afortunadamente eso está disponible para descargarse en el formato del Windows Media Player (o no, Microsoft monopolizando otra vez). Attenti porque el link que te voy a pasar no es para clickear directamente sino para hacer click con el botón derecho y de ahí darle a "Guardar como…" ("Save As…"), ya que el video pesa unos 363 MB. Por ende, hacé click con el botón derecho acá y, como te explicaba, elegí "Guardar como…" ("Save As…")

Eventualmente podés escuchar, acá al toque, una entrevista que dos ingenieros de software (también investigadores y a la vez reporteadores a lo Ron Jacobs) le hicieron al loco Platt. Por favor entrá por acá. Esta entrevista dura 1:20 hora

Finalmente, si venís medio apurado, también podés oir de boca de Platt una intro a su libro de algo así como 8:35 minutos, haciendo click acá

_________________________
(*) Paula hasta hace un año atrás formaba parte de la primera empresa chilena en certificarse en CMMI nivel 5, años atrás (ella fue parte del equipo evaluado por el comité representativo del SEI)

(**) Mujeres… descubrí que despertándola con un café cada mañana conseguía demorar su primeros reproches hacia mí hasta 5 minutos antes de separarnos para ir cada uno a su trabajo. Despertarla sin el café adelantaba los mismos, por así decir, lamentos desde ese mismo instante y por el resto del día. Eventualmente este patrón de diseño te podría llegar a servir si, como yo, sos casado o vivís en pareja

Esta entrada fue publicada en Software Management. Guarda el enlace permanente.

Una respuesta a Estos Programadores que No Cazan Una…

  1. Matias dijo:

    Definitivamente, tengo que comprar el libro de Platt.
     
    Excelente artículo.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s