Archivos de etiquetas: Programación

La parábola de los dos desarrolladores de software

No la conocía pero resulta que, según Incognisis (un blog en español que cae dentro de la categoría de favoritos), fue escrita en marzo de 1985. Es un poco larga quizás pero su lectura debiera ser obligatoria en cualquier escuela de ingenieros de software.

Érase una vez que, sin saber nada la una de la otra, la “Automated Accounting Applications Association” y la “Consolidated Computerized Capital Corporation” decidieron que necesitaban el mismo programa informático para proporcionar cierto servicio.

Automated contrató a un analista programador, Alan, para solucionar su problema.
Mientras tanto, Consolidated decidió pedir a un programador de bajo nivel recién contratado, Charles, que abordase la tarea para ver si era tan bueno como él decía ser.

Alan, que tenía experiencia en proyectos complejos de programación, decidió utilizar la metodología de diseño estructurado PQR. Con esa idea en mente, le pidió a su jefe de departamento que le asignara otros tres programadores para formar un equipo de programación. A continuación el equipo se puso a trabajar y a producir tanto informes preliminares como análisis del problema.

En Consolidated Charles dedicó algún tiempo a pensar en el problema. Sus compañeros de trabajo se dieron cuenta de que a menudo Charles se sentaba con sus pies sobre la mesa mientras se tomaba un café. Ocasionalmente se le vio frente a su terminal, pero su compañero de oficina podía deducir por la pulsación rítmica de las teclas que en realidad estaba jugando a Space Invaders.

Por entonces el equipo de Automated estaba comenzando a picar código. Los programadores pasaban la mitad de su tiempo escribiendo y compilando código, y el resto de su tiempo en reuniones, debatiendo sobre las interfaces que debía haber entre los distintos módulos.

El compañero de Charles notó que por fin había abandonado Space Invaders. En lugar de eso ahora invertía su tiempo en beber café con sus pies encima de la mesa y en hacer garabatos en pedacitos de papel. Sus garabatos no parecían tener relación con las Tres-en-raya, pero tampoco es que tuvieran mucho más sentido.

Pasaron dos meses. El equipo de Automated por fin publicó una hoja de ruta. En otros dos meses tendrían una versión de pruebas del programa. Tras eso vendría un periodo de dos meses de evaluación y mejora que debería llevar a una versión completa.

El jefe de Charles ya estaba cansado de verle holgazanear. Decide enfrentarse a él. Sin embargo, nada más entrar en la oficina de Charles se sorprende al verle muy ocupado introduciendo código en su terminal. El jefe decide posponer la confrontación, así que charla brevemente con él y se marcha.  Sin embargo, comienza a vigilar más de cerca a Charles para que en cuanto se presente la ocasión pueda enfrentarse a él. Como no tiene muchas ganas de tener una conversación desagradable, está encantado de que Charles parezca estar ocupado la mayor parte del tiempo. Incluso se le ha visto retrasar la hora del almuerzo y también quedarse a trabajar más allá de su hora de salida dos o tres días a la semana.

Al cabo de tres meses, Charles anuncia que ha completado el proyecto. Entrega un programa de 500 líneas. El programa parece estar escrito de forma clara, y al ser evaluado hace todo lo que se requería en las especificaciones. De hecho, incluso tiene algunas características adicionales muy convenientes que podrían mejorar de forma significativa la usabilidad del mismo. El programa se pone a prueba y, salvo por un despiste que corrigen rápidamente, funciona bien.

El equipo de Automated ya ha completado dos de los cuatro módulos principales del programa a estas alturas. Esos módulos están siendo sometidos a pruebas mientras que el resto de módulos se finalizan.

Tras tres semanas, Alan anuncia que la versión preliminar está disponible una semana antes de lo que marcaba la planificación. Proporciona una lista de defectos que espera corregir. El programa se pone a prueba. Los usuarios detectan varios errores y defectos aparte de los registrados por Alan. Como Alan explica, eso no es ninguna sorpresa. Después de todo, esta es una versión preliminar en la que los errores son esperables.

Después de dos meses más, el equipo termina de programar la versión de producción del programa. Consiste en cerca de 2.500 líneas de código. Al evaluarlo parece satisfacer la mayoría de las especificaciones originales. Se han omitido una o dos características, y el programa es muy exigente en el formato de sus datos de entrada. Sin embargo la empresa decide implantar el programa. Siempre podrán formar al personal de entrada de datos para introducir esos datos en el formato estrictamente necesario. El programa se pasa a varios programadores de mantenimiento para que incorporen en algún momento las características que faltan.

Epílogo

Al principio el supervisor de Charles se muestra impresionado. Sin embargo, a medida que analiza el código fuente se da cuenta de que el proyecto era en realidad mucho más simple de lo que había imaginado inicialmente. Ahora parece evidente que esto no era ningún reto, ni siquiera para un programador novato.

Charles ha producido cerca de 5 líneas de código al día. Quizás ligeramente por encima de la media. Sin embargo, considerando la simplicidad del programa, no se trata de nada excepcional. Además, su supervisó tomó en cuenta que había pasado dos meses holgazaneando.

En su siguiente revisión de sueldo a Charles le dan un aumento que era cerca de la mitad de la inflación durante ese periodo. No se le dio ningún ascenso. Cerca de un año después Charles dejó de estar motivado y abandonó Consolidated.

En Automated, Alan fue felicitado por terminar el proyecto a tiempo. Su supervisor le echó un vistazo al código. A los pocos minutos de hojearlo observó que los estándares de la empresa relacionados con la programación estructurada se habían respetado. Sin embargo, dejó de revisar el programa rápidamente; parecía bastante incomprensible. Se dio cuenta de que el proyecto era mucho más complejo de lo que a él le había parecido inicialmente, y felicitó de nuevo a Alan por su logro.

El equipo produjo unas tres líneas de código al día por cada programador. Una cifra por encima de la media pero que considerando la complejidad del problema podría ser considerada como excepcional. A Alan se le dio un considerable aumento de sueldo, se le ascendió a Analista de Sistemas y se le dio una recompensa por su labor.

Al leerla no solo me hizo mucho sentido aquello que en tertulias con colegas muchas veces hemos coincidido, y es que los desarrolladores de software habitualmente no nos vendemos bien frente a nuestros pares, ni menos frente a ejecutivos, jefaturas y clientes.

Pero la parábola no se queda ahí. También me hace sentido desde el como los liderazgos logran ver mas allá de lo formal y evidencian aquello que resulta esquivo a primera vista: El talento que se esconde bajo una gruesa capa de ñoñes, inmadurez, exentricidad, incapacidad para relacionarse con otros seres humanos y quizás que otras manías extrañas.

En el ámbito de la tecnología la fauna no solo es diversa, las nuevas generaciones suman nuevas tendencias y comportamientos que los sociólogos catalogan y clasifican con una letra: Generación XYZ, etc.

En fin, los nuevos desarrolladores nos presentan nuevos desafíos!

Publicidad para desarrolladores

axe_get_a_girlfriend

Lo vi en Ubuntu Life.

Microsoft y su particular forma de compartir

Bastante expectación ha provocado entre los desarrolladores .Net el reciente anuncio de Microsoft de “liberar” el código fuente de parte de las bibliotecas del Framework .Net 3.5.

Sin duda, es una tremenda noticia para quienes tenemos la desdicha de escribir código .Net. Claro es, si nos atenemos al titular. Porque como todas las movidas del los chicos de Redmond, tiene su trampilla y esta vez viene de la mano del tipo de licenciamiento con que Microsoft distribuye los fuentes: La Microsoft Reference Licence (MS-RL).

Lo positivo

Podrás ver el código fuente de las siguientes librerías: .NET We’ll begin by offering the source code (with source file comments included) for the .NET Base Class Libraries (System, System.IO, System.Collections, System.Configuration, System.Threading, System.Net, System.Security, System.Runtime, System.Text, etc), ASP.NET (System.Web), Windows Forms (System.Windows.Forms), ADO.NET (System.Data), XML (System.Xml), y WPF (System.Windows).

Podrás descargarlo y verlo desde cualquier editor, y según leo en Thinking dot Net, VS 2008 integrará soporte para debugging, es decir,  cuando estés en modo Debug y hagas F11 sobre una llamada a una de las bibliotecas expuestas, descargará los fuentes y podrás revisar el procesamiento interno. Esto es sumamente positivo porque nos permitirá hacer un debug de nuestras aplicaciones mucho mas exhaustivo, y al fin entenderemos porque diablos hace justo lo contrario de lo que le decimos que haga.

Fantástico!!

Pero vamos, es Microsoft. Algo raro debe tener todo esto.

Lo Negativo

Lo negativo del anuncio es el tipo de licencia con que lo distribuye, puesto que solo permite que “veas” el código fuente de dichas bibliotecas con expresa prohibición de modificarlo y mucho menos redistribuirlo.

“Reference use” means use of the software within your company as a reference, in read only form, for the sole purposes of debugging your products, maintaining your products, or enhancing the interoperability of your products with the software, and specifically excludes the right to distribute the software outside of your company.

Las negritas son mías.

Esto quiere decir que no puedes modificarlo ni mucho menos redistribuirlo, aspectos que son pilares fundamentales del Open Source. O sea, Microsoft no libera el código fuente, solo lo muestra.

Y que hay de malo en que solo muestre?

Además de parecer bailarina de cabaret (de esas que se miran pero no se tocan y tampoco se sacan de paseo), no soy el único que ve un grotesco anzuelo para los desarrolladores del proyecto Mono (aquél proyecto financiado por Novel que implementa el Framework .Net multiplataforma) que al intentar “imitar” (copiar sería poco fino) algún trozo de código que le ha parecido interesante, Microsoft le caiga con senda demanda y gritando a los 7 vientos que el Open Source copia sus desarrollos.

Da para pensar no?

Ver o no ver parece ser el nuevo dilema.

De ASP.Net a PHP

Diariamente escribo mucho código ASP.Net, por eso este tipo de noticias me llama mucho la atención y me cuestiono que diablos hago usando la solución Microsoft.

ClickForLessons.com, sitio web para la búsqueda de profesores particulares, acaba de terminar la migración de sus sistemas escritos en ASP.Net, la flamante plataforma para desarrollo web de Microsoft, a PHP corriendo en Linux. ¿Y cual es la noticia? Que de dicha migración destaca lo siguiente:

Los resultados iniciales muestran que el sitio funciona ahora un 60% más rápido. En general, fuimos capaces de obtener la misma funcionalidad con menos código. La velocidad es fantástica, pero igualmente importante, lo es el costo a medida que el sitio escala.

Así cuenta Steven Cox en su blog, donde además publica una pequeña tabla comparativa.

Vía VivaPHP (Gracias Alexis!)