jueves, 21 de marzo de 2013

El Mítico Hombre-Mes (The Mythical Man-Month) capítulo 1 en español


Hola a todos mis friends. El otro día leí un artículo acerca de Los 10 libros míticos que todo desarrollador de Software debe leer y dentro de esa lista estaba el pulentoso libro The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (2nd Edition) (algo así como El Mítico Hombre-Mes: Ensayos de Ingeniería de Software), como número 5 de la lista. También aparece dicho libro como número 2 en está página en inglés.


Este libro es algo antiguo aunque no tanto, es de 1995 pero habla de aspectos que son transversales a la época y que se encuentran día a día, como los atrasos chantas de proyectos, meter más gente al proyecto hace que colapse y para nada salga "antes de la fecha", el por qué los desarrolladores son tan optimistas, etc. Cosas muy muy interesantes.

Si quieren bajarlo completo, en Google ponen "The Mythical Man-Month pdf" y aparecerán varios sitios que lo ofrecen gratis. Por ejemplo de aquí http://uploaded.net/file/rlsg7tlh.

La cosa es que me puse a leer y estaba muy bueno. Encontré traducción al español del Capítulo 1 en http://juancarunbasic.wikispaces.com, y fue realizado por un colega Ingeniero, Juan Carlos Gutiérrez M. (correojuanca@gmail.com). Lo contacté y logramos un acuerdo donde la revisaría y publicaría la traducción integra acá y mejoraría si encontraba puntos que corregir.

Bueno, aquí vamos.

NOTA: advierto que el autor es algo cristiano, por lo que en un par de veces saca ejemplos relacionado con Dios, si eres medio ateo, omite dichos los ejemplos y sigue leyendo :P

The Mythical Man-Month : Essays on Software Engineering.

Esta es una traducción como ejercicio académico (también es un aporte a todos aquellos desarrolladores ultra-optimistas y líderes de desarrollo o JP que estiman con el viejo truco de tirar una moneda al aire) Traducción original: 22 de Febrero del 2009, por Ing. Juan Carlos Gutiérrez M. (correojuanca@gmail.com)
Revisado el 21/03/2013 por Ing. Hernaldo González Candia (hernaldog@gmail.com)

Está de más decir que todos los créditos son para el gurú (no me refiero al Bomba) y autor del libro Frederick Phillips Brooks.



Sobre el autor


Frederick P. Brooks, Jr., es un Kenan Professor de las Ciencias de la Computación en la Universidad de Carolina del Norte, en Chapel Hill. Es mejor conocido como el "padre de IBM System/360". Se desempeñó como Gerente de proyectos en su desarrollo y más tarde como Director del proyecto de software Operación System/360 durante su fase de diseño.
Por este trabajo, Bob Evans, y Erich Bloch fueron galardonados con la Medalla Nacional de Tecnología (National Medal of Technology) en 1985. Anteriormente, él era arquitecto de computadores IBM Stretch y Harvest.
En Chapel Hill, el Dr. Brooks fundó el Departamento de Ciencias de la Computación y lo presidió desde 1964 hasta 1984. Ha sido miembro de la National Science Board y Defense Science Board. Actualmente enseña e investiga en el área de arquitectura de computadores, gráficos moleculares y entornos virtuales.


Capítulo 1. El Pozo de Alquitrán

Een schip op het strand is een baken in zee.
(Un barco en la playa es como un faro en el mar)
DUTCH PROVERB

No hay una escena de la prehistoria tan vívida como la de las luchas mortales de grandes bestias en los pozos de alquitrán. Con la mente se pueden ver los dinosaurios, mamuts y tigres dientes de sable que luchan entre sí contra el alquitrán. Cuanto más feroz es la lucha, más se hunden en alquitrán y no hay bestia tan fuerte o tan experta por eso ya en la ultima instancia, se hunden.


La programación de grandes sistemas en la década pasada, ha sido como la historia del pozo de alquitrán ya que grandes y poderosas bestias cayeron violentamente dentro de él. La mayoría han emergido con sistemas funcionando, pocos han cumplido metas, horarios y presupuestos. Equipos tras equipos, ya sean grandes o medianos, masivos o de poca gente se ha hundido en el alquitrán. Nada parece causar alguna dificultad, cualquier molestia en particular puede ser superada. Pero la acumulación de factores simultáneos que interactúan entre sí hace lento y más lento movimiento. Todos parecen haber sido sorprendidos por lo contagioso del problema y es difícil discernir la naturaleza de este. Pero debemos intentar entenderlo si queremos a resolverlo.

Por lo tanto, permitámonos comenzar por identificar el arte de la programación de sistemas y luego las alegrías y penurias inherentes a este.


El Producto de Programación de Sistema


De vez en cuando, uno lee en el periódico crónicas de cómo dos programadores en un garaje remodelado han implementado un gran programa que sobrepasa con creces los esfuerzos de muchos grandes equipos. Y un programador está preparado para creer tales historias, ya que sabe que él puede construir cualquier programa mucho más rápido que las 1000 líneas de código al año que reportan los equipos de grandes empresas.

¿Por qué entonces no han sido reemplazados todos los miembros de los equipos grandes por esos "dúos de garaje"?, uno tiene que mirar "que" se está produciendo.
Fig. 1.1 Evolución del producto de Programación de Sistema

En la parte superior izquierda de la Figura 1.1 aparece un programa. Está terminado, listo para ser ejecutado por el autor en el sistema para el cual fue desarrollado. Eso es lo que se produce comúnmente en garajes y ése es el objeto que el programador individual utiliza en la estimación de la productividad.

Hay dos maneras en las que un programa puede convertirse en un objeto más útil, pero más costoso. Estas dos maneras están indicadas en los límites del diagrama.

Moviéndose abajo a través del límite horizontal, un programa se convierte en un Producto de Programación. Éste es un programa que se puede correr, está testeado, corregido y extendido. Es usable en muchos ambientes con muchos tipos de datos. Para convertirse en un producto de programación de uso general, el programa se debe escribir de una forma genérica. Particularmente tanto el rango como la forma de los inputs deben ser genéricos tanto como el algoritmo básico lo permita. A continuación, el programa debe ser probado exhaustivamente, así este puede ser dependiente. Esto significa que un conjunto sustancial de casos de prueba, con un gran rango de entradas y con casos de borde, debe ser preparado, ejecutado y registrado.
Finalmente, llevar un programa a un producto de programación requiere de una depurada documentación, de modo que cualquier persona pueda utilizarla, corregirla y extenderla. En general, estimo que un producto de programación cuesta por lo menos tres veces más que un simple programa que realice la misma función.

Moviéndose a través del límite vertical, un programa se convierte en un componente en un Sistema de Programación. Esto es una colección de programas que obran recíprocamente, coordinados en funcionamiento y disciplinados en formato, de modo que el ensamblaje constituya una ayuda de ítems unificados que sirvan para grandes tareas. Para convertirse en un componente de un sistema de programación, un programa debe ser escrito de modo que cada entrada y salida defina una sintaxis y semántica con interfaces definidas. El programa debe también ser diseñado de modo que utilice sólo un presupuesto estimado de recursos - espacio de memoria, dispositivos de entrada-salida, tiempo del computador. Finalmente el programa se debe testear con otros componentes del sistema, en todas las combinaciones previstas. Estas pruebas deben ser extensas para que el número de casos abarcados crezca de forma exponencial.

Se pierde tiempo con aquellos errores sutiles (bugs) que presentan interacciones inesperadas de componentes que han sido depuradas. Un componente de un Sistema de Programación cuesta al menos tres veces que un programa "Stand-alone" que realice las mismas funciones. El sistema es más costoso mientras mas componentes incluya.

En la esquina inferior derecha de la Fig. 1.1 se encuentra el Producto de Sistemas de Programación. Estos se diferencian de un programa simple en todo lo antes dicho. Tiene un costo nueve veces mayor, pero es el objeto verdaderamente útil, el producto previsto por la mayoría de los esfuerzos de programación de sistemas.


Las alegrías del arte


¿Por qué es la programación divertida? ¿Qué placeres puede su practicante recibir como recompensa?

Primero está la alegría de hacer cosas. Como aquel niño que se deleita con su torta de barro, el adulto disfruta construyendo cosas, especialmente cosas que el mismo diseña. Yo pienso que esta delicia debe ser como la imagen del placer de Dios haciendo las cosas, un placer visto en la distinción de cada hoja y cada copo de nieve.

Segundo, está el placer de hacer cosas que son útiles a otras personas. En nuestro interior queremos que otros utilicen nuestro trabajo y lo encuentren útil. A este respecto el sistema de programación no es esencialmente diferente del primer porta-lápiz de arcilla hecho por el niño "para la oficina del papá".

Tercero, es la fascinación de armar complejos rompecabezas, tal como interconectar partes móviles de objetos y viéndolas trabajar en sutiles ciclos, haciendo cosas que estaban afuera de los principios definidos en el inicio. El computador programado tiene toda la fascinación de una máquina de "pinball" o del mecanismo de una Rockola llevada al máximo.

El cuarto punto es la alegría de aprender, que deriva de la naturaleza no repetitiva de la tarea. De una u otra forma el problema es siempre nuevo y se aprende algo nuevo de su solución: algunas veces teórico, algunas veces algo práctico, y algunas veces ambos.

Finalmente, está el placer de trabajar en un medio tan manejable. El programador, como el poeta, trabaja ligeramente retirado de la naturaleza pura de las cosas. Él construye sus castillos en el aire, desde el aire, creando sólo con la imaginación. Pocos medios de creación son tan flexibles, fáciles de pulir y revisar, lo que permite la creación de grandes estructuras conceptuales (como veremos más tarde, esta flexibilidad tiene sus propios problemas).

Sin embargo la construcción del programa, a diferencia de las palabras de un poeta, es real en el sentido de que se mueve y trabaja, que produce resultados visibles fuera de la construcción del mismo. Este imprime resultados, dibuja figuras, produce sonidos o mueve brazos. Es como la magia del mito y la leyenda hechos realidad en nuestro tiempo. Uno escribe el hechizo correcto desde el teclado y en la pantalla cobra vida, mostrando cosas que nunca fueron ni podrían ser.

En resumen, la programación es divertida porque gratifica los anhelos construidos en el interior de nosotros y deleita las sensibilidades que nosotros tenemos en común con los demás.


Los penas del arte


No todo es placer, sin embargo, si se conocen las dificultades inherentes se hace más fácil manejarlas cuando aparecen.

Primero, hay que realizarlas perfectamente. La computadora se asemeja a una leyenda mágica en este aspecto. Si un carácter o una pausa del hechizo no está terminado en la forma apropiada, la magia no funciona. Los seres humanos no están acostumbrados a ser perfectos y pocas áreas de la actividad humana se lo exigen. Ajustar lo necesario para alcanzar esta perfección es, según mi opinión, la parte más difícil en el aprendizaje de la programación.

Luego, otras personas ajustan los objetivos, proveen recursos y proporcionan informaciones. Uno raramente controla las circunstancias de su trabajo o incluso de su objetivo. En términos de gestión, la autoridad de solo una persona no es suficiente para toda la responsabilidad que existe. También sucede que en muchos ámbitos, existen trabajos donde las cosas se terminan pero sin una autoridad formal que tenga responsabilidad. En la práctica, realmente (de manera no oficial o formal) la autoridad se hace presente desde el momento del levantamiento.

La dependencia sobre los demás tiene un caso particular que es especialmente doloroso para el programador de sistemas. Él depende de los programas de otras personas. Estos frecuentemente están mal diseñados, pobremente implementados, incompletos (sin código fuente ni casos de prueba) y pobremente documentados. Por lo que deben pasar horas estudiando y reparando cosas que en un mundo ideal deberían estar completas, disponibles y utilizables.

El siguiente dolor es que sabemos que el diseño de grandes conceptos fue divertido y encontrar pequeños errores es sólo una parte del trabajo. Pero con cualquier actividad creativa también atrás vienen monótonas horas de tedio, arduo trabajo y la programación no es excepción.

A continuación se observa que la depuración tiene una convergencia lineal, o a veces es peor ya que toma un crecimiento cuadrático en la parte final. Mientras las pruebas más se prolongan, el último error toma mucho más tiempo de encontrar que el primero.

Muchas veces se grita el último "ay", o se da el último "golpe", cuando se termina el producto sobre el cual se ha trabajado por mucho tiempo, pero este se hace obsoleto al momento de terminarlo (o antes). Esto es porque la competencia ya está en la búsqueda de nuevas y mejores ideas. A veces, el pensamiento del niño interno de la creación o del diseño del programa no se alcanza a poner en producción, pero al menos se alcanzó a planificar.

Esto siempre se ve peor de lo que realmente es. El nuevo y mejor producto generalmente no está disponible cuando uno completa el propio; sólo se ha hablado de el. Este nuevo producto también requiere de meses de desarrollo. El verdadero tigre nunca se asemeja al del papel de uno a menos que se requiera un real uso. Por lo tanto, las virtudes de la realidad tienen una satisfacción consigo misma.

Por supuesto, la base tecnológica sobre la que uno construye está "siempre" avanzando. Tan pronto como uno detiene un diseño, este ya se convierte en obsoleto en término de conceptos. Pero la implementación de productos reales requiere ajustes y cuantificación. La caída del uso de una implementación debe ser medida en función de otras implementaciones, no en contra de conceptos no realizados. El reto y la misión es encontrar soluciones reales para problemas reales, en el tiempo estimado, con los recursos disponibles.

Esta es entonces la programación, un pozo de alquitrán en el que muchos esfuerzos han fracasado y una actividad creativa con alegrías y penas propias. Para muchos, las alegrías son muy superiores a las penas y para ellos el resto de este libro intentará establecer algunas tablas que servirán como puente para cruzar los pozos de alquitrán.

Fin del capítulo 1.

Traducción revisada el 09-04-2013. 

7 comentarios:

  1. Algo interesante se puede sacar de este primer capitulo, pero para un mejor entendimiento esperemos los demás capítulos.

    ResponderEliminar
    Respuestas
    1. Correcto, estoy trabajando en el capítulo 2, espero pronto subirlo. Saludos ;)

      Eliminar
  2. Nop, faltan varios capítulos, no he recibido ni una donación y me he quedado sin fondos para el mantener el blog.

    ResponderEliminar