martes, agosto 31, 2010

regla del 90-90

http://es.wikipedia.org/wiki/Regla_del_noventa-noventaRegla del noventa-noventa


En Programación e Ingeniería de software la regla del noventa-noventa hace referencia a un aforismo cómico:
"El primer 90% del código ocupa el 90% del tiempo de desarrollo. El 10% restante del código ocupa el otro 90% de tiempo de desarrollo."
(The first 90% of the code accounts for the first 90% of the development time. The remaining 10% of the code accounts for the other 90% of the development time.)
La regla es atribuida a Tom Cargill de Bell Laboratories (Laboratorios Bell) y fue hecha popular por Jon Bentley's en septiembre de 1985, en una columna llamada "Programming Pearls" de la revista "Communications of the ACM".
Esta instancia del Principio de Pareto hace clara alusión a la creencia generalizada en el entorno del desarrollo de software de que cualquier planificación nace condenada a no cumplirse. De ahí que los porcentajes sumen más de 100.
[editar]Variaciones

Precisamente por este motivo, como los porcentajes no suman 100, el aforismo de Cargill muchas veces es confundido como un error tipográfico. La versión "corregida" de la regla muchas veces se enuncia como:
"El primer 90% del código ocupa el 10% del tiempo de desarrollo. El 10% restante del código ocupa el otro 90% de tiempo de desarrollo."
El sueño de todo programador es identificar este 10% de código y optimizarlo para futuras versiones de software.

pareto priciple

http://en.wikipedia.org/wiki/Pareto_principle


Descripción

Pareto enunció el principio basándose en el denominado conocimiento empírico. Observó que la gente en su sociedad se dividía naturalmente entre los «pocos de mucho» y los «muchos de poco»; se establecían así dos grupos de proporciones 80-20 tales que el grupo minoritario, formado por un 20% de población, ostentaba el 80% de algo y el grupo mayoritario, formado por un 80% de población, el 20% de ese mismo algo.
Estas cifras son arbitrarias; no son exactas y pueden variar. Su aplicación reside en la descripción de un fenómeno y, como tal, es aproximada y adaptable a cada caso particular.
El principio de Pareto se ha aplicado con éxito a los ámbitos de la política y la Economía. Se describió cómo una población en la que aproximadamente el 20% ostentaba el 80% del poder político y la abundancia económica, mientras que el otro 80% de población, lo que Pareto denominó «las masas», se repartía el 20% restante de la riqueza y tenía poca influencia política. Así sucede, en líneas generales, con el reparto de los bienes naturales y la riqueza mundial.
[editar]Aplicaciones

Dijkstra: Por qué Juancito no puede entender

http://www.smaldone.com.ar/documentos/ewd/juancito.html


Por qué Juancito no puede entender

Edsger W. Dijkstra. (EWD991)
http://www.cs.utexas.edu/users/EWD/ewd09xx/EWD991.PDF

Hace unos años escuché una disertación sobre la estructura de las pruebas. Sin vacilar, el disertante se volvió muy gráfico y las pruebas se convirtieron en grafos dirigidos con flechas de los antecedentes a los consecuentes. [Mathematics Inc. hubiera comercializado el producto por aquellos días como Entendimiento Asistido por Computadoras Mediante Animación de Argumentos.] Luego de quince minutos el orador dirigió nuestra atención hacia el hecho de que algunas pruebas eran planas, en tanto que otras no lo eran. Luego, mostró cómo transformaciones simples de las pruebas en otras lógicamente equivalentes podían cambiar su "planaridad"; pero en vez de concluir que, por lo tanto, la planaridad de las pruebas no era probablemente un concepto relevante, se embarcó en un estudio de los argumentos intrínsecamente no-planos, etc.

Fue la disertación más absurda que he oído en años. (Por eso aún la recuerdo.) El pobre tipo era una grave víctima de su educación: confundía el grafo dirigido, como un subconjunto de los pares ordenados, con la representación gráfica de flechas entre puntos. [Si hubiera sido instruido sobre las matrices de incidencia, podría haber disertado sobre los eigenvalores de las pruebas.]

Esto es lo que nos sucede una y otra vez. Cuando se nos introduce un nuevo concepto se nos dan varios ejemplos de un contexto esperanzadoramente familiar, o se nos dan uno o dos modelos en los cuales el nuevo formalismo, sus objetos y sus operaciones pueden ser "entendidos". Y realmente se nos alienta a realizar esas interpretaciones para convencernos a nosotros mismos de que el nuevo formalismo "tiene sentido". Fallan, sin embargo, en advertirnos de que tales interpretaciones tienden a ser engañosas porque los modelos son sobreespecíficos; en que tales hábitos de entendimiento son totalmente desconcertantes cuando las visualizaciones que los acompañan desorientan a la imaginación y que la carga mental de moverse hacia y desde la fórmula y su interpretación, debe mejor evitarse. De hecho, uno solo puede esperar que, al aumentar la familiaridad con el formalismo, el modelo tranquilamente se esfume de nuestra conciencia.

Esto ya había comenzado cuando se nos enseñaron los números naturales. No aprendimos que 2 + 3 = 5, primero aprendimos -¡gráficamente!- que dos manzanas y tres manzanas son cinco manzanas, y luego para peras, para plumas, para gatos, árboles y elefantes. El modelo de la manzana es penosamente inadecuado, dado que, para dar lugar al producto, la manzana tiene que ser elevada al cuadrado, y por consiguiente -y afortunadamente- se desvanece; pero no antes de haber creado un obstáculo para los enteros negativos. Se puede argumentar que seguimos pagando el precio, esto es, si consideramos la invisibilidad del cero en el modelo de la manzana como la responsable de todas las complicaciones matemáticas causadas por considerar el 1 como el menor número natural. (En comparación con los griegos hemos sido afortunados: con sus segmentos de línea pudieron multiplicar muy poco, desafortunadamente lo suficiente como para no tirar su modelo. Y eventualmente la matemática griega murió por su pobreza conceptual y complejidad gráfica: una lección para todos nosotros.)

Dudo seriamente que el desvío a través del modelo de la manzana sea esencial para enseñar los enteros a niños pequeños, pero aún en tal caso, no veo la razón por la cual un proceso de aprendizaje que pueda ser apropiado para niños pequeños deba serlo también para la mente adulta. Y esta parece ser la asunción sobre la cual operan la mayoría de los escritores y muchos de los lectores adultos. Mi -triste- conclusión es que los patrones más difundidos de entendimiento no han sido seleccionados concienzudamente por su efectividad y pueden ser mejor descriptos como hábitos adictivos, muchos de los cuales merecen una advertencia de cirugía general.

Mi observación más común es ver gente que se siente más confortable con el específico innecesario. Cuando son confrontados a un conjunto parcialmente ordenado, piensan mentalmente "por ejemplo, los enteros". Mientras yo fui entrenado para evitar los ejemplos al leer un texto -dado que pueden ser superfluos y, en cualquier caso, distraen-, veo gente que se siente más incómoda fuando se enfrentan a un texto sin ejemplos. Gente que tiene dificultad en entender una construcción que contiene un parámetro natural k me ha asegurado que dicha parametrización presenta un obstáculo adicional que podrían remover sustituyendo inicialmente k por un valor pequeño, digamos 3. No tengo motivos para dudar de su palabra; el extraño fenómeno probablemente estaba conectado al hecho de que k no ocurría en un contexto muy aritmético, sino como la longitud de cadenas o la cantidad de arcos que confluyen en un vértice (contextos en los cuales están habituados a manejarse en términos de gráficos). De la misma forma una permutación "arbitraria" creó problemas similares: hubieran preferido una específica, posiblemente seguida de un comentario al final que indicara que la elección de la permutación no importaba realmente. Es muy extraño, hasta desconcertante, ver a gente perturbada cuando se dejan abiertas preguntas cuyas respuestas son irrelevantes.

Una observación final me sugiere que, de hecho, es culpa del sistema educativo. Recuerdo muy bien la introducción de la idea de que es tarea del profesor el motivar a sus estudiantes. (La recuerdo muy bien porque pensé que la idea era muy absurda.) Ahora encuentro jóvenes científicos educados bajo el régimen motivador, que tienen una desventaja notable: su habilidad para absorber información no motivada está limitada a unas 10 líneas. El objeto y su propósito son cosas diferentes, pero ellos no aprendieron a distinguirlo y ahora son incapaces de separar estos asuntos. Es un ejemplo atemorizador de cómo la educación puede infundir necesidades psicológicas que se vuelven una importante desventaja.

Austin, 5 de noviembre de 1986

prof.dr.Edsger W.Dijkstra
Departamento de Ciencias de la Computación
Universidad de Texas
Austin, TX 78712-1188
Estados Unidos de América

Transcripción y traducción: Javier Smaldone.

Última revisión: 23 de agosto de 2006.

Última versión y actualizaciones: http://www.smaldone.com.ar/documentos/ewd.shtml

Nota del traductor: La versión HTML contiene el texto original en forma de comentarios, para simplificar su corrección.

Dijkstra: Escrito enojado

Escrito enojado

Edsger W. Dijkstra (EWD696)

"Pero los gráficos no son la cuestión central de la geometría, y no está permitido razonar a partir de ellos. Es cierto que mucha gente, incluyendo a los matemáticos, se apoyan en ellos como una muleta y se encuentran incapacitados de hablar cuando se les quita dicha muleta."

Morris Kline en el capítulo "Un Discurso sobre el Método" de "Matemáticas en la Cultura Occidental", Oxford University Press, Inc., 1953

La observación de Morris Kline es correcta. Omite la explicación de lo que ha observado, aunque dicha explicación es simple: la mayoría de la gente, incluyendo a los matemáticos, son pensadores aficionados en el sentido en que no se les ha enseñado cómo pensar eficazmente. No se les ha dicho que tiren la muleta y, por lo tanto, nunca han aprendido a correr.

El hábito de usar ayudas gráficas, como cualquier hábito, es muy dificil de erradicar. Sin embargo, si aceptamos alguna responsabilidad por la eficacia de nuestros hábitos de razonamiento, deberíamos tratar de abandonarlo tan rápido como sea posible; dado que es un mal hábito, desconcertante y engañoso hasta el punto de ser paralizante. Una de las contras de los gráficos es que son casi siempre sobre-específicos. Uno no puede graficar "un triángulo arbitrario": ni bien uno lo ha hecho, éste tiene un ángulo obtuso o no, mientras que para "el triángulo arbitrario" la propiedad de tener un ángulo obtuso está explicitamente indefinida. En el caso de los grafos es aún peor, porque el mismo grafo específico tiene tantas representaciones gráficas, que el sólo establecer que dos gráficos distintos representan el mismo grafo requiere de un tosco proceso de verificación. En el caso de los árboles y listas una circunstancia simpáticamente desconcertante es que la mayoría de las convenciones gráficas no incluyen una representación visible para el árbol o la lista vacía. Son engañosos porque la misma cosa tiene varias representaciones visualmente muy diferentes; su uso es desconcertante porque es insólito cuando un autor establece que dos gráficos distintos tienen que ser considerados semánticamente equivalentes, y son paralizantes porque sólo pueden representar miembros individuales de un conjunto. Y cuando trabajamos con un conjunto, uno de los peores errores que podemos cometer al razonar es tratar de lidiar con el conjunto como un todo, trabajando con los miembros individuales de un subconjunto del cual sólo podemos rogar que sea representativo: uno solamente puede trabajar con un conjunto -y por lo tanto con todos sus miembros- mediante su definición. Una vez que haya comprendido esto, no lo sorprenderá escuchar que uno de los mayores componentes del aprendizaje del razonamiento efectivo es el "desaprendizaje" del uso de gráficos. (Y el "desaprendizaje" es muy dificultoso, dado que su pasado seguirá siendo su pasado: lo único que puede hacer es superponer un nuevo pasado sobre el anterior, y rogar que el más reciente sea dominante.)

Y todo esto fue desencadenado por el "Diseño de Programas Abstractos en un Entorno Interactivo", la tesis doctoral de Lars Kahn, de Estocolmo, quién gentilmente me envió una copia; la cual revisé la otra noche. Entre otros comentarios que no citaré, (el ahora Doctor) Lars Kahn escablece que "[es] mi propia experiencia y la de otros, que es más natural en el proceso de diseño el uso de una notación gráfica en vez de texto. Por varios motivos, no he tenido la oportunidad de implementar una herramienta interactiva con notación gráfica, pero creo que un sistema visual gráfico fácilmente operable para el diseño de programas sería la mejor asistencia mental". Aquí "más natural" debe leerse como "más natural para el ignorante": su "sistema visual gráfico fácilmente operable" significaría el perjuicio más grave al diseño de programas que puedo imaginar. La disertación -de esto me di cuenta más tarde, habiendo salteado las letras pequeñas- fue para el grado de Doctor en ciencias sociales, lo cual trata ciertamente sobre el ignorante. A veces temo que además sean para el ignorante, y por el ignorante.

20 de diciembre de 1978

Plataanstraat 5
5671 AL Nuenen
Holanda
prof.dr.Edsger W.Dijkstra
Investigador Asociado de Burroughs

Transcripción y traducción: Javier Smaldone.

Última revisión: 21 de agosto de 2006.

Última versión y actualizaciones: http://www.smaldone.com.ar/documentos/ewd.shtml

Nota del traductor: La versión HTML contiene el texto original en forma de comentarios, para simplificar su corrección.

Dijkstra: Sobre la crueldad de verdaderamente enseñar ciencias de la computación

http://www.smaldone.com.ar/documentos/ewd/sobre_la_crueldad.html



Sobre la crueldad de verdaderamente enseñar ciencias de la computación

Edsger W. Dijkstra.

La segunda parte de esta charla denota algunas de las consecuencias científicas y educacionales provenientes de la idea de que las computadoras representan una novedad radical. Para darle contenidos claros a esta asunción, tenemos que ser mucho más precisos acerca de lo que queremos decir en este contexto con el uso del adjetivo "radical". Lo haremos en la primera parte de esta charla, en la cual vamos a proveer evidencia que respalde nuestra suposición.

La manera usual en la cual hoy planificamos para el mañana es en el vocabulario de ayer. Lo hacemos porque tratamos de avanzar con los conceptos que nos son familiares, los cuales han adquirido un significado en nuestra experiencia pasada. Por supuesto, las palabras y los conceptos no encajan precisamente porque nuestro futuro difiere de nuestro pasado, pero las estiramos un poco. Los lingüistas están bastante familiarizados con el fenómeno en el cual los significados de las palabras evolucionan a través del tiempo, pero también saben que este es un proceso lento y gradual.

Es el método más común cuando se trata de lidiar con la novedad: utilizando metáforas y analogías tratamos de vincular lo nuevo con lo viejo, lo novedoso con lo familiar. Bajo un cambio suficientemente lento y gradual, esto funciona razonablemente bien; en el caso de una discontinuidad aguda, sin embargo, el método colapsa: aunque podemos glorificarlo con el nombre "sentido común", nuestra experiencia pasada ya no es más relevante, las analogías se tornan muy superficiales, y las metáforas se hacen engañosas en vez de reveladoras. Esta es la situación que caracteriza a la novedad "radical".

Lidiar con una novedad radical requiere un método ortogonal. Uno debe considerar su propio pasado, las experiencias recogidas, y los hábitos formados en él como un desafortunado accidente de la historia, y debe acercarse a la novedad radical con la mente en blanco, rechazando conscientemente el intento de vincularla con lo que ya es familiar, debido a que lo familiar es desesperanzadamente inadecuado. Uno debe, con una especie de personalidad dividida, tomar una novedad radical como algo desasociado por propio derecho. Comprender una novedad radical implica crear y aprender un lenguaje extraño, el cual no puede ser traducido a nuestra lengua materna. (Cualquiera que haya aprendido mecánica cuántica sabe a lo que me refiero.) No hace falta decirlo, ajustarse a las novedades radicales no es una actividad muy popular, ya que requiere mucho trabajo. Por la misma razón, las novedad radicales no son por sí mismas bienvenidas.

A esta altura, bien se pueden preguntar por qué he prestado tanta atención y he gastado tanta elocuencia en una noción tan simple y obvia como una novedad radical. Mi razón es muy simple: las novedades radicales son tan perturbantes que tienden a ser suprimidas o ignoradas, al punto que la mera posibilidad de su existencia es generalmente negada antes que admitida.

Voy a ser breve en cuanto a la evidencia histórica. Carl Friedrich Gauss, el Príncipe de los Matemáticos pero algo cobarde, sin duda estaba al tanto del destino de Galileo –y probablemente podría haber predicho las acusaciones a Einstein– cuando decidió suprimir su descubrimiento de la geometría no Euclidiana, dejando que Bolyai y Lobatchewsky recibieran las críticas. Es probablemente más revelador ir un poco más atrás, a la Edad Media. Una de sus características era que "razonar mediante analogías" era descontrolado; otra característica era el total estancamiento intelectual, y ahora vemos porque ambas características van juntas. Una razón para mencionar esto es resaltar que, desarrollando un oído entrenado para las analogías no garantizadas, uno puede detectar una gran cantidad de pensamiento medieval hoy en día.

La otra cosa que no puedo resaltar lo suficiente es que la fracción de la población para la cuál el cambio gradual parece ser cualquier cosa menos el único paradigma de la historia es muy grande, probablemente mucho más grande de lo que esperarían. Ciertamente cuando comencé a observarlo, su número resultó ser mucho mayor de lo que esperaba.

Por ejemplo, la gran mayoría de la comunidad matemática nunca ha confrontado la suposición tácita de que hacer matemáticas va a continuar siendo básicamente el mismo tipo de actividad mental que siempre ha sido: los nuevos temas vendrán, florecerán, e irán como lo han hecho en el pasado, pero siendo lo que es el cerebro humano, nuestras formas de enseñar, aprender, y el entendimiento las matemáticas, la resolución de problemas y el descubrimiento matemático van a continuar siendo básicamente lo mismo. Herbert Robbins expone claramente por qué él descarta un salto cuántico en la habilidad matemática:

"Nadie va a correr 100 metros en cinco segundos, sin importar cuánto se invierta en entrenamiento y máquinas. Lo mismo puede decirse acerca del uso del cerebro. La mente humana no es diferente ahora de lo que era hace cinco mil años. Y cuando se trata de matemáticas, debe darse cuenta de que se trata de la mente humana a un extremo límite de su capacidad".

Mi comentario en el margen fue "¡entonces reduzca el uso del cerebro y calcule!". Usando la propia analogía de Robbins, uno puede resaltar que, para ir rápido desde A hasta B, podrían existir ahora alternativas a la de correr que son órdenes de magnitud más efectivas. Robbins rechaza de llano honrar cualquier alternativa al valioso uso del cerebro llamado "hacer matemáticas", exorcizando así el peligro de la novedad radical mediante el simple método de ajustar sus definiciones a sus necesidades: simplemente por definición, las matemáticas continuarán siendo lo que solían ser. Demasiado para los matemáticos.

Déjenme darles un ejemplo más de la desconfianza generalizada sobre la existencia de las novedades radicales y, por consiguiente, de la necesidad de aprender cómo lidiar con ellas. Es el accionar educacional que prevalece, para el cuál el cambio, casi imperceptible, parece ser el paradigma exclusivo. ¡Cuántos textos educacionales no son recomendados porque apelan a la intuición del estudiante! Constantemente tratan de presentar todo aquello que podría ser una emocionante novedad como algo tan familiar como sea posible. Conscientemente tratan de vincular el material nuevo con lo que se supone es el mundo familiar del estudiante. Ya empieza con la enseñanza de la aritmética. En vez de enseñar 2 + 3 = 5, el horrendo operador aritmético "más" es cuidadosamente disfrazado llamándolo "y", y a los pequeños niños se les dan muchos ejemplos familiares primero, con objetos claramente visibles como manzanas y peras, que lo son, en contraste al uso de objetos numerables como porcentajes y electrones, que no lo son. La misma tonta tradición es reflejada a nivel universitario en diferentes cursos introductorios de cálculo para los futuros físicos, arquitectos, economistas, cada uno adornado con ejemplos de sus respectivos campos. El dogma educacional parece ser que todo está bien siempre y cuando el estudiante no se dé cuenta de que está aprendiendo algo verdaderamente nuevo; generalmente, el presentimiento del estudiante es de hecho correcto. Considero como un serio obstáculo la falencia de una práctica educativa en preparar a la próxima generación para el fenómeno de novedades radicales. [Cuando el Rey Fernando visitó la conservadora universidad de Cervera, el Rector orgullosamente aseguró al monarca con las palabras: "Lejos esté de nosotros, Señor, la peligrosa novedad de pensar". Los problemas de España en el siglo que siguió justifican mi caracterización del problema como "serio"]. Demasiado para la adopción por parte de la educación del paradigma de cambio gradual.

El concepto de novedades radicales es de importancia contemporánea ya que, mientras estamos mal preparados para lidiar con ellas, la ciencia y la tecnología no se han mostrado expertas en influirlas sobre nosotros. Ejemplos científicos antiguos son la teoría de la relatividad y la mecánica cuántica; ejemplos tecnológicos modernos son la bomba atómica y la píldora. Durante décadas, los primeros dos ejemplos dieron lugar a un torrente de corrientes religiosas, científicas o de otra manera cuasi-científicas. Día a día podemos observar el profundo error de enfoque con el cuál los últimos dos ejemplos han sido abordados, ya sea por nuestros políticos y líderes religiosos o por el público en general. Demasiado para el daño hecho a nuestra paz mental por las novedades radicales.

Traje esto a colación debido a mi convencimiento de que las computadoras automáticas representan una novedad radical y de que sólo identificándolas como tal podemos identificar todo lo irrelevante, los conceptos errados y la mitología que las rodea. Una inspección más a fondo revelará que esto es todavía peor, a saber, que las computadoras automáticas engloban no sólo una novedad radical sino dos de ellas.

La primera novedad radical es una consecuencia directa del poder bruto de las computadoras actuales. Todos sabemos como lidiar con algo tan grande y complejo; divide y vencerás, por ejemplo vemos el todo como una composición de partes y tratamos con las partes por separado. Y si una parte es muy grande, repetimos el procedimiento. La ciudad está compuesto por barrios, que están a su vez estructurados por calles, que contienen edificios, que están hechos de paredes y pisos, que están construidas de ladrillos, etc. eventualmente llegando a las partículas elementales. Y tenemos a todos nuestros especialistas sobre el tema, desde el ingeniero civil, pasando por el arquitecto hasta el físico de estado sólido y consiguientes. Ya que, en cierto sentido, el todo es "mas grande" que sus partes, la profundidad de una descomposición jerárquica es algún tipo de logaritmo del cociente entre los "tamaños" del todo y las partes más pequeñas. Desde un bit a cien mega bytes, desde un microsegundo a media hora de cómputos nos confronta con un cociente completamente abrumador de 10^9! El programador está en la posición inigualada en la cual la suya es la única disciplina y profesión donde un cociente tan gigante, lo cual completamente sobrepasa nuestra imaginación, debe ser consolidado por una sola tecnología. Debe poder pensar en términos de jerarquías conceptuales que son mucho más profundas que todas aquellas que debió enfrentar una sola mente alguna vez. Comparado con ese número de niveles semánticos, la teoría matemática promedio es casi plana. Evocando la necesidad de profundas jerarquías conceptuales, la computadora automática nos confronta con un radical desafío intelectual que no tiene precedente histórico.

Nuevamente, debo enfatizar esta novedad radical ya que el verdadero creyente en el cambio gradual y las mejoras incrementales no puede verla. Para él, una computadora automática es algo como una familiar caja registradora, sólo que algo más grande, rápida y más flexible. Pero la analogía es ridículamente superficial: es órdenes de magnitud peor que comparar, como un medio de transporte, el avión supersónico con un bebé que gatea, ya que el cociente de velocidad es sólo de mil.

La segunda novedad radical es que la computadora automática es nuestro primer dispositivo digital de gran escala. Tuvimos un par de notables componentes discretos: Acabo de mencionar la caja registradora y podemos agregar la máquina de escribir con sus teclas individuales: con un sólo golpe podemos escribir puedes escribir una Q o una W pero, aunque las teclas están una al lado de la otra, no una mezcla de las dos. Pero tales mecanismos son la excepción, y la amplia mayoría de nuestros mecanismos son vistos como dispositivos analógicos cuyo comportamiento sobre un amplio rango es una función continua de todos los parámetros involucrados: si presionamos la punta del lápiz un poco más fuerte, obtenemos una línea levemente más gruesa, si el violinista ubica su dedo levemente fuera de su posición correcta, reproduce una nota levemente desafinada. A esto debería agregar que, al punto que nos vemos como mecanismos, nos vemos primordialmente como dispositivos analógicos: si nos esforzamos un poco más esperamos rendir un poco más. A menudo el comportamiento no es solamente una función continua sino también monótona: para ver si un martillo es adecuado sobre un cierto rango de clavos, lo probamos con el más pequeño y el más grande de los clavos del rango, y si el resultado de ambos experimentos es positivo, estamos perfectamente predispuestos a creer que el martillo será apropiado para todos los clavos intermedios.

Es posible, inclusive tentador, ver a un programa como un mecanismo abstracto, como alguna clase de dispositivo. Pero hacerlo, sin embargo, es altamente peligroso: la analogía es muy superficial debido a que un programa es, como mecanismo, totalmente diferente de todos los familiares dispositivos analógicos con los cuáles crecimos. Como toda la información digitalizada, tiene la inevitable e incómoda propiedad de que la menor de las posibles perturbaciones –por ejemplo cambios a un sólo bit– puede tener las más drásticas consecuencias. [Por completitud agrego que la situación no cambia en su esencia por la introducción de la redundancia o la corrección de errores]. En el mundo discreto de la computación, no hay métrica significativa en la cual "pequeños" cambios y "pequeños" efectos vayan de la mano, y nunca los habrá.

Esta segunda novedad radical comparte el destino usual a todas las novedades radicales: es negada, porque su verdad sería demasiado incómoda. No tengo idea lo que esta negación y descreencia específica le cuesta a los Estados Unidos, pero un millón de dólares al día parece una modesta estimación.

Habiendo descripto –en los términos más amplios posibles, lo admito– la naturaleza de las novedades computacionales, debo ahora proveer la evidencia de que tales novedades son, de hecho, radicales. Lo haré explicando una serie de fenómenos que de otra manera serían extraños por la frustrante –pero, como ahora sabemos, condenada– ocultación o negación de su aterradora extrañeza.

Cierta cantidad de estos fenómenos han sido agrupados bajo el nombre de "Ingeniería de Software". Así como la economía es conocida como "La Ciencia Miserable", la ingeniería de software debería ser conocida como "La Disciplina Condenada", condenada porque ni siquiera puede acercarse a su meta, dado que la misma es en sí misma contradictoria. La ingeniería de software, por supuesto, se presenta a sí misma como otra causa valiosa, pero es un colirio: si lee cuidadosamente su literatura y analiza lo que realmente hacen quienes se avocan a ella, descubrirá que la ingeniería de software ha adoptado como su estatuto "Cómo programar si usted no puede".

La popularidad de su nombre es suficiente para hacerla sospechosa. En lo que denominamos "sociedades primitivas", la superstición de que conocer el verdadero nombre de alguien otorga un poder mágico sobre él no es inusual. Difícilmente somos menos primitivos: ¿por qué persistimos en contestar el teléfono con el poco útil "hola" en vez de nuestro nombre? Tampoco estamos por encima de la primitiva superstición de que podemos tener cierto control sobre algún demonio malicioso desconocido llamándolo por un nombre seguro, familiar e inocente, tal como "ingeniería". Pero esto es totalmente simbólico, así como demostró uno de los fabricantes de computadoras de los EE.UU. hace unos años cuando contrató, una noche, cientos de nuevos "ingenieros de software" mediante el simple mecanismo de elevar a todos sus programadores a ese exaltante rango. Demasiado para ese término.

La práctica está impregnada de la confortable ilusión de que los programas son simplemente dispositivos como cualquier otro, la única diferencia que se admite es que su fabricación pueden requerir un nuevo tipo de expertos, a saber: programadores. Desde allí hay sólo un pequeño paso hasta medir la "productividad del programador" en términos de la "cantidad de líneas producidas por mes". Esta es una unidad de medida muy costosa, porque anima a escribir código insípido, pero hoy estoy menos interesado en qué tan tonta es una unidad, aún desde un punto de vista puramente empresarial. Mi punto hoy es que, si deseamos contar líneas de código, no deberíamos verlas como "líneas producidas", sino como "líneas gastadas": el sentido común actual es tan tonto como contabilizar esa cuenta del lado erróneo del balance.

Además de la noción de productividad, también el control de calidad sigue estando distorsionado por la confortable ilusión de que funciona con otros aparatos como lo hace con los programas. Han pasado ya dos décadas desde que se señaló que el testing de programas puede convincentemente demostrar la presencia de errores, pero nunca puede demostrar su ausencia. Después de citar devotamente este comentario bien publicitado, el ingeniero de software vuelve al orden del día y continúa refinando sus estrategias de testing, tal como el alquimista de antaño, quien continuaba refinando sus purificaciones crisocósmicas.

Un profundo malentendido es luego revelado por el término "mantenimiento de software", como resultado del cual muchas personas siguen creyendo que los programas –e inclusive los mismísimos lenguajes de programación– están sujetos a desgaste y ruptura. Su auto también necesita mantenimiento, ¿no es así? Es famosa la historia de la empresa petrolera que creía que sus programas PASCAL no durarían tanto como sus programas FORTRAN "porque PASCAL no estaba mantenido".

En el mismo sentido debo llamar la atención sobre la sorprendente facilidad con que se ha aceptado la sugerencia de que los males de la producción de software de deben, en gran medida, a la falta de "herramientas de programación" apropiadas. (Pronto aparecería la frase "banco de trabajo del programador".) Nuevamente, la chatura de la analogía subyacente se debe a la Edad Media. Las confrontaciones con las insípidas "herramientas" del tipo de "animación de algoritmos" no ha suavizado mi juicio; por el contrario, ha confirmado mi sospecha inicial de que estamos tratando principalmente con otra dimensión del negocio del aceite de serpientes.

Finalmente, para corregir la posible impresión de que la inhabilidad de enfrentar la novedad radical está confinada al mundo industrial, déjenme ofrecerles una explicación de la –al menos americana– popularidad de la Inteligencia Artificial. Uno esperaría que la gente se sintiera aterrorizada por los "cerebros gigantes de máquinas que piensan". De hecho, la atemorizante computadora se vuelve menos atemorizante si es utilizada solamente para simular una no-computadora que nos es familiar. Estoy seguro de que esta explicación seguirá siendo controvertida por bastante tiempo, dado que la Inteligencia Artificial como imitadora de la mente humana prefiere verse a sí misma como a la vanguardia, mientras mi explicación la relega a la retaguardia. (El esfuerzo de utilizar máquinas para imitar la mente humana siempre me ha parecido bastante tonto: las usaría para imitar algo mejor.)

Hasta aquí la evidencia de que las novedades computacionales son, de hecho, radicales.

Y ahora viene la segunda –y más difícil– parte de mi charla: las consecuencias educativas y científicas de lo anterior. Las consecuencias educativas son, por supuesto, las más engorrosas, por lo tanto pospongamos su discusión y quedémonos mientras tanto con las ciencias de la computación en sí mismas. ¿Qué es la computación? ¿Y de qué se trata la ciencia de la computación?

Bien, una vez que todo está dicho y hecho, la única cosa que las computadoras pueden hacer por nosotros es manipular símbolos y producir resultados de tales manipulaciones. De nuestras observaciones previas, deberíamos recordar que este es un mundo discreto y, más aún, tanto los números como los símbolos involucrados así como la cantidad de manipulaciones realizadas son varios órdenes de magnitud mayores que los que podemos concebir: desconciertan totalmente nuestra imaginación y por lo tanto no debemos tratar de imaginárnoslos.

Pero antes de que una computadora esté lista para realizar alguna clase de manipulación con sentido –o cálculo, si se prefiere– debemos escribir un programa. ¿Qué es un programa? Varias respuestas son posibles. Podemos ver a un programa como lo que transforma una computadora de propósito general en un manipulador de símbolos de propósito específico, y lo hace sin necesidad de cambiar un solo cable (Esto fue una enorme mejora respecto de las máquinas con paneles de cables dependientes del problema.) Prefiero describirlo de la otra manera: un programa es un manipulador de símbolos abstracto, que puede convertirse en uno concreto suministrándole una computadora. Después de todo, el propósito de los programas ya no es más instruir a nuestras máquinas; en estos días, el propósito de las máquinas es ejecutar nuestros programas.

Por lo tanto, tenemos que diseñar manipuladores de símbolos abstractos. Todos sabemos cómo se ven: se ven como programas o –para usar una terminología más general– usualmente fórmulas de algún sistema formal un tanto elaboradas. Realmente ayuda ver a un programa como una fórmula. Primero, pone la tarea del programador en la perspectiva correcta: tiene que derivar esa fórmula. Segundo, explica por qué el mundo de las matemáticas ha ignorado el desafío de la programación: los programas eran fórmulas mucho más largas que las usuales, al punto que ni siquiera las reconocieron como tales. Ahora, de vuelta al trabajo del programador: tiene que derivar esa fórmula, tiene que derivar ese programa. Sabemos de una única forma confiable de hacerlo, mediante la manipulación de símbolos. Y ahora el círculo está cerrado: construimos nuestros manipuladores de símbolos mecánicos mediante la manipulación de símbolos humana.

Por lo tanto, la ciencia de la computación está –y siempre estará– relacionada con la interacción entre la manipulación de símbolos mecanizada y humana, usualmente llamadas "computación" y "programación", respectivamente. Un beneficio inmediato de esta visión es que revela a la "programación automática" como una contradicción en términos. Un beneficio posterior es que nos da una clara indicación acerca de dónde ubicar la ciencia de la computación en el mapa de las disciplinas intelectuales: en la dirección de la matemática formal y la lógica aplicada, pero finalmente mucho más allá de donde se encuentra actualmente, dado que la ciencia de la computación se interesa en el uso efectivo de los métodos formales en una escala mucho, mucho mayor de la que hemos sido testigos hasta ahora. Dado que ningún emprendimiento es respetable por estos días sin una STL (Sigla de Tres Letras) propongo que adoptemos para la ciencia de la computación IMF (Iniciativa de los Métodos Formales), y, para estar del lado seguro, mejor sigamos los brillantes ejemplos de nuestros líderes y hagamos de ella una Marca Registrada.

En el largo plazo espero que la ciencia de la computación trascienda a sus disciplinas padres, matemática y lógica, efectivamente realizando una parte significativa del Sueño de Leibniz de proveer un cálculo simbólico como una alternativa al razonamiento humano. (Por favor, note la diferencia entre "imitar" y "proveer una alternativa a": a las alternativas se les permite ser mejores.)

De más está decirlo, esta visión acerca de qué trata la ciencia de la computación no es universalmente aplaudida. Por el contrario, ha encontrado oposición –y a veces hasta violenta– desde todo tipo de direcciones. Menciono como ejemplos:

(0) la comunidad matemática, que quisiera continuar creyendo que el Sueño de Leibniz es una ilusión irreal

(1) la comunidad empresarial, quienes, habiéndoseles vendido la idea de que las computadoras harían la vida más simple, no están mentalmente preparados para aceptar que sólo resolvieron los problemas más simples al precio de crear uno mucho más difícil

(2) la subcultura del programador compulsivo, cuya ética prescribe que una idea tonta y un mes de codificación frenética deberían bastar para hacerlo millonario de por vida

(3) los ingenieros en computación, quienes quisieran continuar actuando como si fuera solamente cuestión de mayor flujo de bits o más flops por segundo

(4) la milicia, quienes están hoy totalmente absorbidos por el negocio de usar computadoras para transformar partidas de miles de millones de dólares en la ilusión de seguridad automática

(5) todo tipo de ciencias para las cuales la computación ahora actúa de alguna especie de refugio interdisciplinario

(6) el negocio educativo que siente que, si tiene que enseñar matemática formal a los estudiantes de Ciencias de la Computación, también debería cerrar sus escuelas.

Y con este sexto ejemplo he alcanzado, imperceptiblemente pero también inevitablemente, la parte más engorrosa de esta charla: consecuencias educativas.

El problema con la política educativa es que es difícilmente influenciada por consideraciones científicas derivadas de los tópicos dictados, y casi completamente determinada por circunstancias ajenas a la ciencia tales como las expectativas conjugadas de los estudiantes, sus padres y sus futuros empleadores, y el enfoque prevaleciente del rol de la universidad: el acento está en formar sus graduados para los trabajos de nivel inicial de hoy o en proveer a su alumnado con el bagaje intelectual y las actitudes que perduraran por otros 50 años? ¿Le damos rencorosamente a las ciencias abstractas solo un rincón lejano en el campus, o las reconocemos como el motor indispensable de la industria de alta tecnología? Aún si hacemos esto último, ¿reconocemos una industria de alta tecnología como tal si su tecnología pertenece principalmente a las matemáticas formales? ¿Proveen las universidades a la sociedad el liderazgo intelectual que necesita o sólo el entrenamiento que demanda?

La retórica académica tradicional está perfectamente dispuesta a dar a estas cuestiones las respuestas tranquilizadoras, pero no creo en ellas. A modo de ilustrar mis dudas, en un artículo reciente en "¿Quién gobierna Canadá?", David H. Flaherty groseramente establece que "Además, la élite de los negocios descarta a los académicos e intelectuales como ampliamente irrelevantes e impotentes."

Así, si miro en mi borrosa bola de cristal hacia el futuro de la educación en ciencias de la computación, veo sobrecogedoramente la deprimente imagen del "Negocio acostumbrado". A las universidades les seguirá faltando el coraje de enseñar ciencia dura, continuará orientando mal a los estudiantes, y cada nuevo escalón de infantilización del currículum será exaltado como progreso educativo.

Hace un buen rato que tengo mi borrosa bola de cristal. Sus predicciones son invariablemente melancólicas y usualmente correctas, pero estoy bastante acostumbrado a eso y no me impiden darles unas pocas sugerencias, aún si es meramente un ejercicio vano cuyo único efecto es hacerlos sentir culpables.

Podemos, por ejemplo, comenzar limpiando nuestro lenguaje no denominando a un bug un bug, sino denominándolo un error. Es mucho mas honesto porque pone manifiestamente la culpa donde corresponde, es decir, en el programador que cometió el error. La metáfora animada del bug que se introdujo maliciosamente mientras el programador no estaba mirando es intelectualmente deshonesta ya que disfraza el hecho de que el error es propia creación del programador. Lo agradable de este simple cambio de vocabulario es que tiene un profundo efecto: mientras, antes, un programa con sólo un error solía ser "casi correcto", después de ello un programa con un error es simplemente "erróneo" (porque tiene un error).

Mi próxima sugerencia lingüística es más rigurosa. Se trata de confrontar el síndrome de "si-este-tipo-quiere-hablarle-a-ese-tipo": nunca se refieran a partes de programas o piezas de equipo en una terminología antropomórfica, ni permitan hacerlo a sus estudiantes. Esta mejora lingüística es mucho más difícil de implementar de lo que podrían pensar, y su departamento puede considerar la introducción de multas para las violaciones, digamos veinticinco centavos para estudiantes de grado, cincuenta centavos para estudiantes de postgrado y cinco dólares para miembros de la facultad: para final del primer semestre del nuevo régimen, habrán recolectado suficiente dinero para dos becas.

La razón para esta última sugerencia es que la metáfora antropomórfica –por cuya introducción podemos culpar a John von Neumann– es una enorme desventaja para cada comunidad informática que la ha adoptado. He encontrado programas que quieren cosas, saben cosas, esperan cosas, creen cosas, etc., y cada vez eso generaba confusiones evitables. La analogía que subyace a esta personificación es tan superficial que no es solamente engañosa sino también paralizante.

Es engañosa en el sentido que sugiere que podemos lidiar con el desconocido discreto en términos del familiar continuo, es decir, nosotros mismos, quod non. Es paralizante en el sentido que, debido a que las personas existen y actúan en el tiempo, su adopción efectivamente impide un despegue de la semántica operacional y fuerza así a la gente a pensar sobre los programas en términos de comportamientos computacionales, basados en un modelo computacional subyacente. Esto es malo, porque el razonamiento operacional es un tremendo desperdicio de esfuerzo mental.

Déjenme explicarles la naturaleza de ese tremendo desperdicio, y permítanme tratar de convencerlos de que el término "tremendo desperdicio de esfuerzo mental" no es una exageración. Por un breve lapso, me tornaré altamente técnico, pero no se acobarden: es el tipo de matemáticas que uno puede hacer con las manos en los bolsillos. El punto a comunicar es que si tenemos que demostrar algo respecto de todos los elementos de un conjunto grande, es desesperanzadamente ineficiente tratar con todos los elementos del conjunto individualmente: el argumento eficiente no se refiere a elementos individuales en lo absoluto y se lleva a cabo en términos de la definición del conjunto.

Consideren la figura plana Q, definida como el cuadrado de 8 por 8 del cual, en dos esquinas opuestas, han sido quitados dos cuadrados de 1 por 1. El área de Q es 62, que equivale al área combinada de 31 dominós de 1 por 2. El teorema es que la figura Q no puede ser cubierta por 31 de tales dominós.

Otra manera de exponer el teorema es que si comienza con papel cuadriculado y se cubre este ubicando cada siguiente dominó en dos nuevos recuadros adyacentes, ninguna distribución de 31 dominós dará como resultado la figura Q.

Así, una posible manera de probar el teorema es generando todas las posibles distribuciones de dominós y verificando para cada distribución que no da como resultado la figura Q.

El argumento simple, sin embargo, es como sigue. Pinte los recuadros del papel cuadriculado como un tablero de ajedrez. Cada dominó, cubriendo dos recuadros adyacentes, cubre 1 recuadro blanco y 1 negro, y , por consiguiente, cada distribución cubre tantos recuadros blancos como recuadros negros. En la figura Q, sin embargo, el número de recuadros blancos y el número de recuadros negros difiere en 2 –esquinas opuestas sobre la misma diagonal– y por consiguiente ninguna disposición de dominós da como resultado la figura Q.

No sólo es el simple argumento previo muchos órdenes de magnitud más corto que la investigación exhaustiva de las posibles distribuciones de 31 dominós, es también esencialmente más poderosa, dado que cubre la generalización de Q reemplazando el cuadrado original de 8 por 8 por cualquier rectángulo con lados de longitud par. Siendo infinito el número de tales rectángulos, el método previo de exploración exhaustiva es esencialmente inadecuada para probar nuestro teorema generalizado.

Y esto concluye mi ejemplo. Ha sido presentado porque ilustra de un tirón el poder de las matemáticas terrenales; no hace falta decirlo, la negación de explotar este poder de las matemáticas terrenales escala al suicidio intelectual y tecnológico. La moraleja de la historia es: tratar con todos los elementos de un conjunto ignorándolos y trabajando con la definición del conjunto.

Volvamos a la programación. La aseveración de que un programa dado cumple una cierta especificación escala a una aseveración sobre todos los cálculos computacionales que podrían ocurrir bajo el control de ese programa dado. Y dado que este conjunto de cálculos está definido por el programa dado, nuestra reciente moraleja dice: trate con todas los cálculos posibles bajo control de un programa dado ignorándolas y trabajando con el programa. Debemos aprender a trabajar con el texto de los programas mientras (temporalmente) se ignora que admiten la interpretación de código ejecutable.

Otra manera de decir la misma cosa es la siguiente. Un lenguaje de programación, con su sintaxis formal y las reglas de demostración que define su semántica, es un sistema formal para el cual la ejecución del programa provee solamente un modelo. Es bien conocido que los sistemas formales deberían ser tratados por derecho propio, y no en términos de un modelo específico. Y, de nuevo, el corolario es que deberíamos razonar sobre los programas sin siquiera mencionar su posible "comportamiento".

Y esto concluye mi excursión técnica en el motivo por el cual el razonamiento operacional sobre la programación es "un tremendo desperdicio de esfuerzo mental" y por qué, en consecuencia, en la ciencia de la computación debería prohibirse la metáfora antropomórfica.

No todo el mundo comprende esto suficientemente bien. Recientemente fui expuesto a una demostración de lo que pretendía ser software educativo para un curso introductorio de programación. Con sus "visualizaciones" en la pantalla era un caso tan obvio de infantilización del currículum que su autor debería ser acusado de su "menosprecio del cuerpo estudiantil", pero esto era sólo un daño menor comparado con para qué se usaban las visualizaciones: ¡se usaban para mostrar todo tipo de características de cálculos computacionales evolucionando bajo el control del programa del estudiante! El sistema remarcaba precisamente aquello que el estudiante tiene que aprender a ignorar, reforzaba precisamente lo que el estudiante tiene que desaprender. Dado que quitarse los malos hábitos, más que adquirir nuevos, es la parte más dura del aprendizaje, debemos esperar de ese sistema un daño mental permanente para la mayoría de los estudiantes expuestos.

No hace falta decirlo, ese sistema ocultaba completamente el hecho de que, por sí sólo, un programa no es más que la mitad de una conjetura. La otra mitad de la conjetura es la especificación funcional que se supone que satisface el programa. La tarea del programador es presentar las conjeturas completas como teoremas demostrados.

Antes de irnos, me gustaría invitarlos a considerar la siguiente forma de hacer justicia a las novedades radicales de la computación en un curso introductorio a la programación.

Por un lado, enseñamos algo que se parece al cálculo de predicados, pero lo hacemos de manera muy distinta a los filósofos. A fin de entrenar al programador novato en la manipulación de fórmulas sin interpretar, lo enseñamos más como álgebra booleana, familiarizando al estudiante con todas las propiedades algebraicas de los conectivos lógicos. Para romper aún más los vínculos con la intuición, renombramos los valores {verdadero, falso} del dominio booleano como {negro, blanco}

Por otro lado, enseñamos un lenguaje de programación imperativo simple y claro, con un skip y una asignación múltiple como sentencias básicas, con una estructura de bloque para variables locales, el punto y coma como operador para composición de sentencias, una bonita construcción alternativa, una bonita repetición y, si se quiere, una llamada a procedimiento. A esto agregamos un mínimo de tipos de datos, digamos booleanos, enteros, caracteres y cadenas. Lo esencial es que, para lo que sea que introduzcamos, la semántica correspondiente está definida por las reglas de demostración que la acompañan.

Desde el comienzo, y a través de todo el curso, enfatizamos que la tarea del programador no es sólo escribir un programa, sino que su tarea principal es dar una prueba formal de que el programa que propone cumple la especificación funcional (igualmente formal). Mientras se diseñan demostraciones y programas conjuntamente, el estudiante adquiere una amplia oportunidad de perfeccionar su destreza manipulativa con el cálculo de predicados. Finalmente, para hacer llegar el mensaje de que este curso introductorio a la programación es principalmente un curso en matemáticas formales, nos encargamos de que el lenguaje de programación en cuestión no haya sido implementado en el campus de manera que los estudiantes estén protegidos de la tentación de probar sus programas. Y esto concluye el esbozo de mi propuesta para un curso introductorio a la programación para estudiantes de primer año.

Esta es una propuesta seria, y sumamente sensible. Su única desventaja es que es demasiado radical para muchos, quienes, siendo incapaces de aceptarla, se ven forzados a inventar alguna justificación rápida para desestimarla, no importa cuan inválida sea. Les daré unas pocas de esas justificaciones.

No necesitan tomar mi propuesta seriamente porque es tan ridícula que estoy obviamente desconectado del mundo real. Pero ese barrilete no va a volar, ya que conozco el mundo real demasiado bien: los problemas del mundo real son principalmente aquellos con los que ustedes se quedan después de negarse a aplicar sus efectivas soluciones. Así que, probemos de nuevo.

No necesitan tomar seriamente mi propuesta porque es sumamente surrealista intentar enseñar tal material a alumnos de primer año. ¿No sería esa una salida fácil? Acaban de postular que esto sería por lejos muy difícil. Pero ese barrilete tampoco va a volar, dado que el postulado se ha demostrado falso: desde principios de los '80, se ha dado tal curso introductorio a la programación a cientos de estudiantes de primer curso de grado cada año. [Porque, en mi experiencia, decir esto no es suficiente, la sentencia previa debería repetirse al menos otras dos veces]. Así que, intentemos de nuevo.

Admitiendo renuentemente que podría quizás enseñarse a estudiantes suficientemente dóciles, todavía rechazan mi propuesta porque tal curso se desviaría tanto de lo que los estudiantes de 18 años están habituados y esperan, que inflingírselos sería un acto de irresponsabilidad educativa: sólo frustraría a los estudiantes. No hace falta decirlo, ese barrilete tampoco va a volar. Es cierto que el estudiante que nunca ha manipulado fórmulas sin interpretar se da rápidamente cuenta que se confronta con algo totalmente distinto a cualquier cosa que haya visto antes. Pero afortunadamente, las reglas de manipulación son en este caso tan pocas y simples que muy poco después hace el excitante descubrimiento de que está comenzando a dominar el uso de una herramienta que, en toda su simplicidad, le da un poder que sobrepasa sus sueños más audaces.

Enseñar a jóvenes desprevenidos el uso efectivo de los métodos formales es uno de los placeres de la vida porque es extremadamente gratificante. En pocos meses, encuentran su camino en un mundo nuevo con justificado grado de confianza, que es radicalmente novedoso para ellos; en pocos meses, su concepto de cultura intelectual ha adquirido una dimensión radicalmente novedosa. Para mi gusto y estilo, esto es de lo que se trata la educación. Las universidades no deberían temer a enseñar novedades radicales; por el contrario, es su llamado dar la bienvenida a la oportunidad de hacerlo. Su disposición a hacerlo es nuestra principal salvaguarda contra las dictaduras, sean del proletariado, del establishment académico, o de la élite corporativa.

Austin, 2 de Diciembre de 1988

prof. dr. Edsger W. Dijkstra

Departamento de Ciencias de la Computación

Universidad de Texas

Austin, TX 78712-1188

USA

Traducción: Javier Smaldone y Billy Biset.

Transcripción original: Javier Smaldone.

Última revisión: 5 de agosto de 2006 (11:45 am).

Última versión y actualizaciones: http://www.smaldone.com.ar/documentos/ewd.shtml

Nota de los traductores: La versión HTML contiene el texto original en forma de comentarios, para simplificar su corrección.

lunes, agosto 30, 2010

Ética ingenieros

http://es.wikipedia.org/wiki/Ingeniería



Ética profesional
  1. Los ingenieros deben reconocer que la vida, la seguridad, la salud y el bienestar de la población dependen de su juicio.
  2. No se deben aprobar planos o especificaciones que no tengan un diseño seguro.
  3. Se deben realizar revisiones periódicas de seguridad y confiabilidad.
  4. Prestar servicios productivos a la comunidad.
  5. Comprometerse a mejorar el ambiente.
  6. Los ingenieros deben prestar servicios en sus áreas de competencia.
  7. Deben emitir informes públicos. Se debe expresar la información en forma clara y honesta.
  8. Deben crear su reputación profesional sobre el mérito de sus servicios.
  9. No usar equipamiento fiscal o privado para uso personal.
  10. Acrecentar honor, integridad y dignidad de la profesión.
  11. Debe continuar con el desarrollo profesional (Continuar la educación).
  12. Apoyar a sociedades profesionales.
  13. Utilizar el Ingenio para resolver problemas.
  14. Ser consciente de su responsabilidad en su trabajo.
  15. Debe conocer las teorías científicas para explicar los hechos y actuar sobre ellos.


crisis del software, nada nuevo

De la wikipedia...
http://es.wikipedia.org/wiki/Crisis_del_software

Crisis del software
La crisis del software se fundamentó en el tiempo de creación de software, ya que en la creación del mismo no se obtenían los resultados deseados, además de un gran costo y poca flexibilidad.
Es un término informático acuñado en 1968, en la primera conferencia organizada por la OTAN sobre desarrollo de software, de la cual nació formalmente la rama de la ingeniería de software. El término se adjudica a F. L. Bauer, aunque previamente había sido utilizado por Edsger Dijkstra en su obra The Humble Programmer.
Básicamente, la crisis del software se refiere a la dificultad en escribir programas libres de defectos, fácilmente comprensibles, y que sean verificables. Las causas son, entre otras, la complejidad que supone la tarea de programar, y los cambios a los que se tiene que ver sometido un programa para ser continuamente adaptado a las necesidades de los usuarios.
Además, no existen todavía herramientas que permitan estimar de una manera exacta, antes de comenzar el proyecto, cuál es el esfuerzo que se necesitará para desarrollar un programa. Este hecho provoca que la mayoría de las veces no sea posible estimar cuánto tiempo llevará un proyecto, ni cuánto personal será necesario. Cuando se fijan plazos normalmente no se cumplen por este hecho. Del mismo modo, en muchas ocasiones el personal asignado a un proyecto se incrementa con la esperanza de disminuir el plazo de ejecución.
Por último, las aplicaciones de hoy en día son programas muy complejos, inabordables por una sola persona. En sus comienzos se valoró como causa también la inmadurez de la ingeniería de software, aunque todavía hoy en día no es posible realizar estimaciones precisas del coste y tiempo que necesitará un proyecto de software.
Englobó a una serie de sucesos que se venían observando en los proyectos de desarrollo de software:
Los proyectos no terminaban en plazo.
Los proyectos no se ajustaban al presupuesto inicial.
Baja calidad del software generado.
Software que no cumplía las especificaciones.
Código inmantenible que dificultaba la gestión y evolución del proyecto.
Aunque se han propuesto diversas metodologías para intentar subsanar los problemas mencionados, lo cierto es que todavía hoy no existe ningún método que haya permitido estimar de manera fiable el coste y duración de un proyecto antes de su comienzos.

------


Se trató de utilizar técnicas de ingeniería para la creación del software por analogía.


La ingeniería buscaba ser capaz de resolver problemas complejos donde tienen que intervenir mucha gente


Pero la ingeniería, más de 30 años después, no ha dado una solución a la creación de software


pero eso no es lo peor, lo peor es que mucha gente sigue sin entenderlo ni querer verlo

crysol opina sobre ingeniería del software

http://crysol.org/es/node/1389



Después de unas cuantas décadas desde la «crisis del software», las cosas no han mejorado demasiado en las ciencias de la computación. El desarrollo de programas de computadora dista mucho de parecerse al proceso de fabricación típico de cualquier otra ingeniería; razón ésta por la que muchos consideran, no sin falta de razón, que el prefijo «ingeniería» le viene grande a la informática.

El ingsoft es el intento de resolver este problema, aunque más que «ingeniería del software» quizá debería llamarse algo así como «des-artesanización de la informática». Personalmente coincido con Dijkstra en que la verdadera ingeniería del software vendrá necesariamente de la formalización y las matemáticas, y para eso queda todavía «mucha tela que cortar y muchos metros de pan que comer» que diría E. Dominguez.

Mientras esperamos, unos cuantos gurus se reunieron (en 2001) para intentar aclarar sus ideas al respecto y redactaron lo que se conoce como el Manifiesto Ágil. El manifiesto expresa unos valores y principios bastante chocantes para muchos en relación al «ingsoft» tradicional. No los voy a comentar aquí, lee el artículo de la wikipedia que he enlazado o directamente la página del manifiesto, que está mejor explicado de lo que podría hacerlo yo.

Lo que si me gustaría enumerar son las premisas que yo entiendo (me puedo equivocar) que llevaron a esas conclusiones. Creo que el manifiesto es el resultado de admitir sin tapujos la dolorosa realidad, cosas que creo que todos los que hacemos software pensamos en el fondo:

Predecir el futuro no está al alcance de cualquiera. Prever (en el sentido literal de la palabra) todas las variables que pueden influir en el diseño e implementación de una aplicación mínimamente compleja es básicamente imposible, o tan difícil que merece más la pena invertir ese esfuerzo (o una buena parte) en prepararse para los cambios, los que sean y ocurran cuando ocurran. En decir, en lugar de preparar un plan de contingencias por si hay cambios inesperados, asumir que los habrá, como parte de la filosofía de trabajo.
Las estimaciones de plazos siempre fallan. Esto no deja de ser más de lo mismo. No es que las estimaciones sean malas, el problema es que no hacemos estimaciones, hacemos patéticos intentos de adivinación. Estimar (en el sentido estadístico) es ofrecer un valor aproximado a partir de un conjunto de datos previos. Es decir, para saber cuánto se va a tardar en hacer una tarea se consulta la información sobre tareas similares en el pasado (para lo cual es imprescindible medir y registrar cada nueva tarea) y se determinan cuestiones como formación del personal que la hizo, novedad de la tarea, tamaño del equipo, calidad del resultado, etc. Después se compara con la tarea actual y se extrapola en la medida de lo posible…. Ahora compara lo dicho con lo que hace el comercial de tu empresa. Si no estás llorando es que el comercial de tu empresa eres tú.
Los requisitos siempre cambian. Una ERS escrita y firmada con sangre es papel mojado (y no me refiero a la sangre). El propio desarrollo del proyecto es un medio para que el cliente entienda lo que quiere realmente Es cuasi-imposible tenerlos todos claros antes de empezar y que no haya que añadir, cambiar, quitar algunos/muchos de ellos durante y después del desarrollo. Te puedes repetir un millón de veces que es posible escribir una ERS intocable pero sabes que te estás engañando, nunca ha pasado y nunca pasará.
Los planes detallados acaban por abandonarse. Es difícil justificar el esfuerzo que supone un plan detallado al comienzo de un proyecto. Es útil hacer planificación de grano grueso, pero es mejor dejar la planificación detallada para cuando comienza el desarrollo de cada componente o iteración concreta.
Las fases de análisis, diseño, desarrollo y pruebas se solapan constante e inevitablemente. Es contraproducente aislar estas fases porque las interrelaciones entre ellas son constantes. Un programa no es un puente o una carretera, no se fabrica del mismo modo y el cliente lo sabe.
Es imposible diseñar una aplicación completa antes de programar nada. El diseño es un proceso de «descubrimiento». Solo en contadas ocasiones y con mucha experiencia en el campo se puede hacer un diseño completo «a ciegas».
El diseño está influenciado por el lenguaje y las herramientas. O dicho de otro modo, la elección del lenguaje, herramientas y entorno de desarrollo (incluso del personal) son determinantes en las decisiones de diseño.
La documentación prematura es un lastre. Código legible, pruebas claras y comentarios «extraibles» son la mejor documentación que puede tener un programa. La literatura es costosa de mantener y es fácil provocar ambigüedades entre requisitos, documentación y código. Los podemos fustigar por no haber hecho primero la documentación, pero eso no cambiará nada.
Y por supuesto:

MENOS ES MÁS
LA CREATIVIDAD ES LA ESCLAVITUD
LA EXPERIENCIA ES LA FUERZA

película sobre patentes de software

http://patentabsurdity.com/

viernes, agosto 27, 2010

simulación cuántica por ordenador, ¿o es otra cosa?

Me acuerdo que en una práctica de programación 3, pedían hacer un juego de billar en java (en un applet, sí aquello super "cool" que ya nadie recuerda)

Tenía que ser un programa concurrente

La especificación de la práctica decía que cada bola tenía que correr en su propio "proceso" (o hebra o como quieras llamarlo)



Yo decidí no hacerlo así, porque para una práctica está bien, pero para simular un billar... tendríamos efectos cuánticos



Imaginemos una bola corriendo independiente de las demás. Da un pasito (por ejemplo del tamaño de un punto en la pantalla) y verifica si ha tocado a otra bola, el borde o el agujero para interactuar con su entorno)

Para verificar si toca otra bola, pregunta al resto de bolas sus posiciones y hace los cálculos

Pero el resto de bolas se mueve independientemente y por tanto, se mueven mientras esta hace los cálculos.

Eso podría generar que al iniciar los cálculos, las bolas están "tocándose" pero mientras hace los cálculos, la otra bola sigue su camino y se solapan


Más o menos, el problema sería que la bola no sabe exactamente dónde están las demás por un problema de sincronización (o quizá es mejor decir de desincronización) derivado de cada cada una se mueve de forma completamente independiente


¿de qué dependería este efecto?

Del tamaño relativo de la bola respecto a la distancia de cada paso. Hay... en un ordenador es imposible trabajar con continuos. Pero... ¿se puede en el mundo real?

¿Qué marca la velocidad de una bola? o bien el tamaño de paso (tamaño de pasos por unidad de tiempo) o la cantidad de tiempo que permanece en la misma posición antes de dar un paso, o ambas


Una bola sabría en un momento dado su velocidad y posición con total precisión.
Por supuesto, serían parámetros propios y le podemos preguntar


Pero eso es porque funciona en una mesa rígida. Si a esa mesa le metemos relatividad especial... la cosa se complica pero sigue sin ser imposible (incluso si quitamos los bordes y ponemos los agujeros en movimiento)


Pero intentemos saber la velocidad y posición de una bola sin preguntarle al programa que dirige todo (¿en el mundo real hay algo así?)


¿Cómo podríamos saber su velocidad y posición?


Ahora tenemos una mesa de billar con la luz apagada, no vemos nada de lo que tiene


Metemos en la mesa de billar un actor nuevo.

Unas diminutas bolitas, muy, muy pequeñas y ligeras, de forma que al chocar con las bolas de billar, estas últimas no se vean alteradas (o casi)


Supongamos que todas las bolas de billar están paradas...

Lanzamos estas microbolitas en la mesa, lanzamos un haz dirigido de esas bolitas y con unos detectores, analizamos cuándo y dónde vuelven (las que vuelvan)

Con esto podríamos hacer un mapa parcial y detectar las bolas de billar.

Estamos ignorando los efectos relativistas, complicarían mucho las cosas.


Pero si las bolas de billar se mueven, ya tenemos la fiesta montada



Las bolitas lanzadas, se mueven cada una independientemente, son procesos independientes y cada bola de billar igual


Nuevamente, cuando una bolita trate de calcular su nueva dirección por una interacción con una bola mucho más grande de billar, la bola de billar podría seguir a su aire fagocitando parcial o totalmente la bolita.

Eso haría que en el cálculo de la nueva dirección de la bolita... ¿que le pasaría?

Supongamos que el rebote se calcula respecto al centro de la bola grande. El rebote por tanto, debido a este solapamiento, sería impredecible


Si tratamos de hacer un mapa con este sistema y en esas condiciones, tendríamos un mapa con bolas más gordas de lo que son y con los bordes difuminados (vamos, un mapa borroso)


¿Cómo reducir este efecto?

En un programa de ordenador es fácil, eliminando la concurrencia. Por ejemplo... después de cada paso, todo el mundo quieto hasta que se calculen todas las interacciones entre todas las partículas



En el mundo real...


teniendo bolas de billar enormes, el efecto de difuminado sería imperceptible


El efecto de difuminado parece casar muy bien con el principio de incertidumbre de heisemberg y además, el solapamiento sería el famoso efecto túnel


Es decir, que simular un mundo cuántico en un ordenador parece curiosamente sencillo

Y lo sorprendente es que es muy sencillo utilizando un modelo que no se basa en los principios básicos de la mecánica cuántica, sino en una consecuencia


Una de las consecuencias de la mecánica cuántica es la no predecibilidad (puesto que no existe un estado inicial preciso nunca)


La concurrencia salvaje, es no determinista


¿Debería sorprendernos que partiendo de un modelo no determinista tenemos efectos cuánticos muy claros?


¿Sería posible deducir casi todos los principios de la mecánica cuántica en la dirección opuesta?

Eso sería... el no determinismo no es una consecuencia, sino un principio



Pues no lo sé, porque yo no tengo suficiente coco, pero es una idea chula para pasar un rato

¿Si eso fuera posible, quizá se podrían encontrar nuevas consecuencias?

jueves, agosto 26, 2010

Programación extrema

http://www.chuidiang.com/ood/metodologia/extrema.php


Un poco de historia

En los tiempos en que la informática empezó a hacerse popular, en el que sólo había pantallas de texto, no había entornos de ventanas y las impresoras usaban papel con agujeros a los lados y rayas horizontales, las aplicaciones eran bastante más sencillas que las actuales. Bastaba uno o dos programadores, que totalmente a su aire y en un plazo razonable de tiempo eran capaces de hacer programas útiles. Para imprimir una lista de clientes, bastaba pulsar en el menú el "1" de imprimir, luego el "3" de clientes y echarle un ojo a la impresora para ver si imprimía o no. El programador era una especie de "mago" que hacía su aplicación y sólo él sabía cómo funcionaba. Si acaso, y para cubrir el expediente, después de hacer el programa hacía un "flujograma" de los antiguos, no había UML, orientación a objetos ni cosas por el estilo.

Con el tiempo, las aplicaciones fueron siendo cada vez más exigentes, los ordenadores disponían de más memoria y aparecieron los entornos de ventanas. Ahora para imprimir la lista de clientes, había que arrastrar el icono del "señor gordo con bigote" sobre el icono de la impresora, haciendo que caminara "como un egipcio" mientras lo arrastrabamos con el ratón (otro invento nuevo). La impresora debía imprimir gráficos, con negritas, cursivas y 32 fuentes simultáneamente. Además, hay que hacer que los altavoces estereos toquen música polifónica mientras se arrastra al "gordo del bigote".

Todas estas complicaciones hicieron que los programas se agrandaran y complicaran enormemente, que hicieran falta varios desarrolladores y tiempos de desarrollo más largo. Todo esto llevó consigo la necesidad de más organiazación y más papeleo. Aparecieron las metodologías de desarrollo más pesadas (las que se basan en escribir mucha documentación). Antes de hacer un programa, fue necesario escribir qué es lo que se quería hacer, de forma que asegurábamos que el cliente y los desarrolladores estaban de acuerdo en lo que se iba a hacer. Luego había que escribir qué se iba a hacer, para que los muchos programadores trabajaran más o menos con un objetivo común y organizados, etc, etc.

De alguna forma, toda esta organización y papeleo quitó parte del encanto de la programación. Los programadores, en vez de dedicarse a lo que se supone que les gusta, programar, debían dedicar bastante de su tiempo a hacer y leer documentos, reuniones, etc.

Tratando un poco de recuperar los viejos tiempos, en el que había menos papeleo, las cosas eran más sencillas y los programadores hacían lo que les gustaba, nació una nueva metodología de desarrollo, la programacion extrema.

Algunas bases de la programación extrema

En la programación extrema se da por supuesto que es imposible prever todo antes de empezar a codificar. Es imposible capturar todos los requisitos del sistema, saber qué es todo lo que tiene que hacer ni hacer un diseño correcto al principio. Es bastante normal hacer un diseño, ponerse a codificar, ver que hay faltantes o errores en el diseño, empezar a codificar fuera del diseño y al final el código y el diseño, o no se parecen, o hemos echado un montón de tiempo en cambiar la documentación de diseño para que se parezca al código.

En vez de tratar de luchar contra todo eso, lo asume y busca una forma de trabajar que se adapte fácilmente a esas circunstancias. Básicamente la idea de la programación extrema consiste en trabajar estrechamente con el cliente, haciéndole mini-versiones con mucha frecuencia (cada dos semanas). En cada mini-versión se debe hacer el mínimo de código y lo más simple posible para que funcione correctamente. El diseño se hace sobre la marcha, haciendo un mini-diseño para la primera mini-versión y luego modificándolo en las siguientes mini-versiones. Además, no hay que hacer una documentación para el diseño, no hay mejor documentación que el mismo código. El código, por tanto, también se modifica continuamente de mini-versión en mini-versión, añadiéndole funcionalidad y extrayendo sus partes comunes.

Los pasos a seguir en un proyecto

En un proyecto usando programación extrema se siguen más o menos los siguientes pasos:

El cliente junto al equipo de desarrollo definen qué es lo que se quiere hacer. Para ello utilizan las "historios de usuario". Una historia de usuario en un texto de una o dos frases en las que se dice algo que debe hacer el sistema. Es más extensa que un requisito (que suele ser una frase corta) y menos que un caso de uso (que puede ser de una o dos páginas). Se evalua para cada historia de usuario el tiempo que puede llevar, que debe ser corto, de aproximadamente una semana. Un programador puede estimar con cierta fiabilidad un trabajo que le lleve unos días, pero la estimación es menos fiable si es de un plazo superior a una semana. Si es más largo, hay que partir la historia en otras más pequeñas. Luego se ordenan en el orden en que se van a desarrollar y se establecen las mini-versiones, de forma que cada mini-versión implementa varias de las historias de usuario.

Toda esta planificación va a ser, por supuesto, inexacta. No se puede saber todo lo que va a ser necesario ni evaluar los tiempos correctamente. La planificación deberá revisarse y modificarse continuamente a lo largo del proyecto. Las historias de usuario se modificarán, se quitarán o se añadirán nuevas sobre la marcha. Puesto que el cliente estará presente día a día durante todo el proyecto, verá el efecto y el esfuerzo necesario para las modificaciones pedidas y sabrá evaluar si merecen o no la pena.

Para las primeras historias que se van a implementar, se define una prueba para ver si la versión cumple perfectamente con la historia. Estas pruebas deben ser automáticas, de forma que haya un programa de pruebas que ejecutemos y nos diga si la mini-versión es o no correcta.

Los programadores se ponen por parejas (dos personas en el mismo ordenador) para codificar esas historias. Primero codifican el programa de pruebas y ven que falla ( ¡ El código todavía no está hecho ! ). Luego piensan cómo van a implementar la historia y hacen sus propios programas de prueba (también automáticos). Codifican sus programas de prueba y ven que también fallan. Luego se ponen a codificar hasta que se pasen con éxito todas las pruebas. En su código hacen de la forma más sencilla posible lo mínimo imprescindible para que se pasen las pruebas automáticas.

Las parejas de programadores se intercambian con frecuencia, de forma que todos acaban trabajando con todos. El trabajo por parejas haciendo intercambios tiene las siguientes ventajas:

Cuatro ojos ven más que dos. Al trabajar de dos en dos, el código será de mayor calidad desde el mismo momento de crearlo y tendrá menos fallos.
Los programadores novatos aprenderán de los expertos al emparejarse con ellos.
Si una pareja realiza un trozo de código susceptible de ser reutilizado en el proyecto, hay dos programadores que lo saben y que lo reutilizarán cuando puedan (ya que saben cómo funciona), enseñándolo a sus nuevos compañeros. De esta manera el conocimiento del código ya hecho se propaga de forma natural entre todos los programadores del equipo.
El estilo de programación tiende a unificarse.
Cuando una nueva pareja va a realizar un nuevo código para una historia de usuario, puede que uno de ellos recuerde haber hecho un trozo de código en otro lado que podría reutilizar. Esta pareja irá a ese trozo de código y lo reutilizará, modificándolo si es necesario. Después de modificarlo, deben asegurarse que se siguen pasando las pruebas automáticas que se hicieron en su momento, así como añadir nuevas pruebas para comprobar las modificaciones que han hecho.

Si una pareja al reutilizar código ya hecho ve que es mejorable, lo mejoran, pasando las pruebas automáticas después. Si al reutilizar el código ya hecho descubren un error que las pruebas automáticas no detectan, añaden pruebas capaces de detectar el error y lo corrigen.

El código, por tanto, no es de nadie. Cualquier pareja puede tocar el código ya hecho por otras personas si lo necesita, con la condición de que después de tocarlo las pruebas automáticas sigan pasándose correctamente y que añadan sus propias pruebas automáticas para las correcciones realizadas.

Todos los días se hace una pequeña reunión a primera hora de la mañana con todo el equipo en la que se comentan problemas, código que se está realizando, historias de usuario terminadas, etc.

Cada vez que se consigue codificar y que funcione una historia de usuario, se le da al cliente para que la vea, la pruebe y añada las posibles modificaciones para las siguientes mini-versiones. Cuando se realiza un mini-versión completa (compuesta por varias de las historias de usuario), incluso se entrega al usuario final para que empiece a trabajar con ella y reportar inicidencias o mejoras.

Este ciclo se va repitiendo una y otra vez hasta que el cliente se de por satisfecho y cierre el proyecto. Cómo se ve, no se ha hecho documentación. En algún sitio he leido que incluso la planificación inicial debe hacerse escribiendo cada historia de usuario en un tarjeta, haciendo dos montones, las que ya están hechas y las que no. Se pueden tirar las tarjetas, añadir nuevas o cambiar las que ya hay. El número de tarjetas en cada montón nos da una idea exacta de cuánto hay hecho del proyecto.

Prácticas básicas de la programación extrema

Para que todo esto funcione, la programación extrema se basa en trece "prácticas básicas" que deben seguirse al pie de la letra. Dichas prácticas están definidas (en perfecto inglés) en www.xprogramming.com/xpmag/whatisxp.htm. Aquí tienes un pequeño resumen de ellas

Equipo completo: Forman parte del equipo todas las personas que tienen algo que ver con el proyecto, incluido el cliente y el responsable del proyecto.
Planificación: Se hacen las historias de usuario y se planifica en qué orden se van a hacer y las mini-versiones. La planificación se revisa continuamente.
Test del cliente: El cliente, con la ayuda de los desarrolladores, propone sus propias pruebas para validar las mini-versiones.
Versiones pequeñas: Las mini-versiones deben ser lo suficientemente pequeñas como para poder hacer una cada pocas semanas. Deben ser versiones que ofrezcan algo útil al usuario final y no trozos de código que no pueda ver funcionando.
Diseño simple: Hacer siempre lo mínimo imprescindible de la forma más sencilla posible. Mantener siempre sencillo el código.
Pareja de programadores: Los programadores trabajan por parejas (dos delante del mismo ordenador) y se intercambian las parejas con frecuencia (un cambio diario).
Desarrollo guiado por las pruebas automáticas: Se deben realizar programas de prueba automática y deben ejecutarse con mucha frecuencia. Cuantas más pruebas se hagan, mejor.
Mejora del diseño: Mientras se codifica, debe mejorarse el código ya hecho con el que nos crucemos y que sea susceptible de ser mejorado. Extraer funcionalidades comunes, eliminar líneas de código innecesarias, etc.
Integración continua: Deben tenerse siempre un ejecutable del proyecto que funcione y en cuanto se tenga una nueva pequeña funcionalidad, debe recompilarse y probarse. Es un error mantener una versión congelada dos meses mientras se hacen mejoras y luego integrarlas todas de golpe. Cuando falle algo, no se sabe qué es lo que falla de todo lo que hemos metido.
El código es de todos: Cualquiera puede y debe tocar y conocer cualquier parte del código. Para eso se hacen las pruebas automáticas.
Normas de codificación: Debe haber un estilo común de codificación (no importa cual), de forma que parezca que ha sido realizado por una única persona.
Metáforas: Hay que buscar unas frases o nombres que definan cómo funcionan las distintas partes del programa, de forma que sólo con los nombres se pueda uno hacer una idea de qué es lo que hace cada parte del programa. Un ejemplo claro es el "recolector de basura" de java. Ayuda a que todos los programadores (y el cliente) sepan de qué estamos hablando y que no haya mal entendidos.
Ritmo sostenible: Se debe trabajar a un ritmo que se pueda mantener indefinidamente. Esto quiere decir que no debe haber días muertos en que no se sabe qué hacer y que no se deben hacer un exceso de horas otros días. Al tener claro semana a semana lo que debe hacerse, hay que trabajar duro en ello para conseguir el objetivo cercano de terminar una historia de usuario o mini-versión.
Algunos enlaces

f-spot vs shotwell y gestión de fotos

¿utilizas algún softwae de gestión/organización de fotos?


Hay gente que habla muy bien de picassa
está para linux utilizando por debajo wine pero dicen que va bien
no es software libre


La opción de kde es digikam


La opción de gnome era f-spot pero ahora shotwell le pisa fuerte y le está desbancando

Es una batalla interesante

Miguel de Icaza, después de apostar por corba y bonobo (copia de COM de mocochoft) apostó por mono (copia muy buena de .net de mocochoft)

Miguel de Icaza es uno de los fundadores y líderes de gnome
Así que intentó meter mono en gnome, pero algunos protestaron porque no querían mono

Y como son así, inventaron un nuevo lenguaje para no tener que hacer todo en C (como se hacía en gnome)
El objetivo era ser más productivos y mejores sistemas de comunicación entre aplicaciones

Este lenguaje se llama Vala y está triunfando en gnome

Es un lenguaje no terriblemente diferente a java o c# (para mi algo mejor), pero no funciona sobre ninguna máquina virtual

vala se compila en lenguaje c y luego el compilador de c, lo compila en lenguaje máquina para el so que corresponda


El caso es que el gestor de fotos estrella de gnome era f-spot (no había otro) y estaba desarrollado en mono

Pero desde el otro lado de gnome, sacaron shotwell y la competencia está servida, que gane el mejor (y por el momento está ganando el que llegó más tarde que lo tenía más difícil, shotwell)


f-spot vs shotwell o quizá.... mono vs vala

miércoles, agosto 25, 2010

windows linux comprador-vendedor analogía

Los sistemas operativos son como los coches. La compañía Microsoft empezó vendiendo bicicletas (MS-DOS), luego pasó a producir una actualización (el Windows original) que añadía a la bicicleta un motorcito para ir más rápido.

Y finalmente, produce un monovolumen, no demasiado bonito, que pierde mucho aceite pero que la gente compra mucho (Windows 95). La otra compañía, Apple, vende unos deportivos muy bonitos y cómodos, fáciles de usar, pero que vienen herméticamente cerrados de forma que es imposible saber qué hay en su interior.

Y por último tenemos algo que no es ni siquiera una compañía, sino más bien un campamento de refugiados, lleno de voluntarios de gran talento, que produce tanques.
Sí, tanques. Tan buenos, que nunca se rompen, fáciles de maniobrar, que consumen el mismo combustible que un coche, están fabricados con la última tecnología y, lo mejor de todo, son gratuitos. A medida que uno de esos tanques Linux, ¿no lo habían adivinado?, se termina, se deja en la calle y cualquiera puede llevárselo.

El grupo que regala los tanques sólo permanece vivo porque lo llevan voluntarios, que se alinean al borde de la calle con megáfonos, tratando de llamar la atención de los clientes sobre esta increíble situación. Una conversación típica es algo así:

HACKER CON MEGÁFONO: ¡Ahorra dinero! ¡Acepta uno de nuestros tanques gratis! ¡Es invulnerable, y puede atravesar roquedales y ciénagas a ciento cincuenta kilómetros por hora consumiendo dos litros a los cien!

FUTURO COMPRADOR DE MONOVOLUMEN: Ya sé que lo que dices es cierto. . . pero. . . eh. . . ¡yo no sé mantener un tanque!

MEGÁFONO: ¡Tampoco sabes mantener un monovolumen!

COMPRADOR: Pero esta tienda tiene mecánicos contratados. Si le pasa algo a mi monovolumen, puedo tomarme un día libre de trabajo, traerlo aquí y pagarles para que trabajen en él mientras yo me siento en la sala de espera durante horas, escuchando música de ascensor.

MEGÁFONO: ¡Pero si aceptas uno de nuestros tanques gratuitos te mandaremos voluntarios a tu casa para que lo arreglen gratis mientras duermes!

COMPRADOR: ¡Manténte alejado de mi casa, bicho raro!

MEGÁFONO: Pero. . .

COMPRADOR: ¿Pero es que no ves que todo el mundo está comprando monovolúmenes?

desarrollo ágil

http://knol.google.com/k/desarrollo-ágil-de-software#



El desarrollo de programas es una disciplina que todos relacionamos en forma directa con el progreso, las mejoras en la productividad, y mucha gente inteligente trabajando duro y generando importantes beneficios para las empresas y toda la sociedad. Pero al mismo tiempo observamos que muchas veces los proyectos de desarrollo de software sufren retrasos y no se obtienen los resultados esperados pese al talento y esfuerzo puestos en acción por parte de analistas, programadores y usuarios para que “el nuevo sistema” funcione correctamente en tiempo y forma.
¿Por qué tantos proyectos de desarrollo de software no se terminan a tiempo, cuestan más que lo presupuestado originalmente, tienen problemas de calidad serios y generan menor valor que el esperado?

Este interrogante fue uno de los que se formularon Ken Schwaber, Jeff Sutherland y otros profesionales expertos en el desarrollo de software cuando se reunieron en febrero de 2001 para analizar el problema y decidieron redactar un “Manifiesto Ágil”. Se trató de un compromiso público en buscar nuevas y mejores formas de desarrollar software poniendo énfasis en las personas y sus interacciones, la colaboración y la respuesta continua al cambio, explorando nuevas formas de hacer las cosas, y compartiendo experiencias -- dando origen a una nueva comunidad de profesionales que explora sistemáticamente nuevas alternativas frente al modo tradicional de desarrollar software.

Desarrollo “tradicional” de software

La forma tradicional de desarrollar software se basa en procesos predefinidos con documentación muy precisa, y una detallada planificación inicial que debe seguirse estrictamente. Esta forma de trabajar surgió naturalmente hace unos cincuenta años como una adaptación del manejo de proyectos de ingeniería, que era lo más parecido a desarrollar programas que se conocía en ese momento, y funcionó razonablemente bien en un comienzo. También es necesario tener en cuenta que los ordenadores era enormemente caros, la mayor parte de la inversión informática se la llevaban los equipos y por esta razón los programas se hacían a medida para unas máquinas que se adquirian, no lo olvidemos, para realizar unas tareas muy concretas.
Pero los proyectos de desarrollo de software en la actualidad incluyen desafíos muy diferentes a los que se presentan al construir puentes y casas, por lo que no sorprende que los métodos tradicionales de desarrollo de software estén en crisis.
Tradicionalmente los proyectos se dividen en etapas bien diferenciadas: Análisis de Factibilidad, Análisis de Requerimientos, Diseño, Programación, y Testeo.

Generalmente se trata de que haya retroalimentación (feedback en inglés) entre las etapas contiguas, de tal forma de que, por ejemplo, haya un momento en que se mejoren los Requerimientos en base a comentarios, sugerencias y necesidades de los responsables del Diseño. Sin embargo, esta forma de desarrollar software genera muy serios problemas, debido a que al comienzo del proyecto, que es cuando menos se conocen las características del problema que resolver, se toman las decisiones de mayor relevancia e impacto en el resto del proyecto.

Como las chances de tomar decisiones erróneas al comienzo del proyecto son generalmente mayores que cuando ya se ha trabajado un tiempo en el proyecto, muchas veces proyectos no cumplen sus objetivos, no se terminan a tiempo, o resultan mucho más caros que lo presupuestado. En particular, esto ocurre frecuentemente en los casos en que el grupo de desarrollo necesita crear algo totalmente nuevo o de características específicas que nadie ha creado aún . . . lo cual es cierto en la mayoría de los proyectos de software, porque en caso contrario, la organización compraría directamente un producto o sistema ya desarrollado por otra empresa.

Como propuesta de solución a estos problemas han surgido una serie de “métodos ágiles” de desarrollo de software y manejo de proyectos en general, y cuyas principales características mencionaremos a continuación.

Características del Desarrollo Ágil

En los proyectos con Desarrollo Agil se busca que todos los recursos se empleen en la creación del mejor software que satisfaga las necesidades del cliente. Esto significa que todos los que forman parte del equipo de trabajo se concentran únicamente en tareas y procesos que agregan valor al cliente del producto que se está creando, mejorando o implementando. Adicionalmente, los usuarios o clientes reciben periódicamente prototipos o versiones en funcionamiento del producto a medida que se va construyendo, lo cual les permite evaluar el trabajo realizado, advertir sobre problemas que se detecten, y sugerir mejoras o funcionalidad valiosa que no se había considerado originalmente (ya sea por olvido, o porque la nueva funcionalidad se inspira en la experiencia de evaluar el producto mientras se está construyendo)
La distinción entre las tareas relevantes y los que no agregan valor se consigue a través de la creación de contextos con alto nivel de empowerment y feedback.
El empowerment consiste en otorgar autonomía para tomar decisiones al equipo de desarrollo, y genera un clima de sinergia grupal que permite al grupo avanzar a pesar de las complicaciones y dificultades que ocurren habitualmente en los proyectos –de allí que uno de los métodos de trabajo más populares se haya bautizado con el nombre “scrum”, ya que la imagen de los jugadores de rugby empleando su energía en avanzar todos juntos es muy aplicable a los equipos de trabajo que utilizan esta metodología.
El feedback constante y presente en varios niveles permite el desarrollo incremental y el crecimiento adaptativo de la programación, así también como una mejora constante en la forma de trabajo de los equipos, lo que permite detectar problemas y resolverlos antes de que desaten crisis que afecten la calidad o el tiempo y costo del desarrollo. Los principales tipos de feedback ocurren a nivel producto, procesos y código
Periódicamente el cliente evalúa el estado real del software que se está creando, lo que asegura que lo entregado al final del proyecto coincidirá con lo esperado. Esto se consigue a través de un desarrollo incremental: el producto puede probarse desde las primeras semanas y meses del proyecto al menos en cuanto a su funcionalidad más básica, que luego va creciendo y mejorando –es por esto que se dice que desde el comienzo el producto ya tiene dentro su ADN, del mismo modo que ocurre con la gestación de los seres vivos en la Naturaleza.
A nivel procesos se realizan frecuentes reuniones retrospectivas donde los integrantes de los equipos comentan y discuten en profundidad tanto sus aciertos (para poder repetirlos y convertilos en hábitos), así también como el trabajo que no se realizó correctamente o no llevó al equipo a obtener los resultados esperados.
Adicionalmente los programadores suelen trabajar mucho en equipo y también por parejas, revisando juntos el código y resolviendo problemas en lugar de tratar de cubrirlos, lo que repercute en un producto de mejor calidad, mejor documentado, y simple de mantener.

Ricardo Colusso
http://crealogar.blogspot.com

la fábula del pastor y el jefe de proyectos

http://geeks.ms/blogs/rcorral/archive/2008/11/24/la-f-225-bula-del-pastor-y-el-jefe-de-proyectos.aspx


La fábula del pastor y el jefe de proyectos
Paseaba un día un jefe de proyectos por el campo. Tras años de rayos catódicos era su primer paseo por el páramo castellano en mucho tiempo. Lo necesitaba. La ocasión merecía los pantalones y las botas que estrenaba, recién compradas en la tienda de Timberland del aeropuerto. Iba pensando en lo bucólico del paisaje y la paz que se respiraba y lo lejos que estaba ahora de las reuniones 'tressesenta' , cuando vio, en la lejanía, para un informático 350 metros son la lejanía, un pastor de ovejas con rebaño de discreto tamaño. No más de cincuenta recursos eran los que el pastor gestionaba.
En ese preciso instante el modesto pastor vio al 'pimpollo' y pensó… vaya, otro que estrena botas, mañana con ampollas… mientras arrancaba un lasca de queso con su navaja. En esto el 'pinpollo' ya estaba a su lado. El pastor levanto la cabeza, miro a nuestro jefe de proyecto y le tendió un trozo de queso. Ya se sabe, que en la castilla profunda, la hospitalidad se muestra más de gesto que de palabra.
El jefe de proyecto cogió el queso, sin poder evitar pensar: 'que uñas más negras'. Y se sentó junto al pastor. La botas le estaban matando. Degusto el queso, que le supo como le sabía el queso cuando tenía forma de queso y no forma de triángulo metido en un plástico. Y ya se sabe, un buen queso puede tener efectos tan alucinógenos como el LSD. Sobre todo si no se ha probado en años… y no sale de la máquina de la sala de café después de poner dos euros y pulsar sesenta y siete.
Así que embriagado por los aromas de aquel queso, el jefe de proyecto no pudo evitar decir: 'señor pastor, lo suyo si que es vida'. El pastor le miro, sin decir nada. 'Todo el día dedicado a usted mismo, con sus fieles recursos que nunca se oponen a su voluntad, que saben lo que deben hacer sin que nadie se lo diga, que no están todo el día exigiendo y pensando en irse a su hora a casa. Lo que daría yo por estar en su situación… ' continuó el jefe.
El pastor le miró y con la simpleza que solo da la verdadera sabiduría dijo: 'no sabe usted de lo que habla, amigo'. Y tiro un largo trago de bota. El jefe de proyecto no se iba a amilanar, así que espetó: 'Usted si que no sabe nada de lo duro que es mi trabajo, seguro que yo cuidaría mejor de sus ovejas que usted de mi equipo de desarrolladores'. El pastor le miró fijamente y dijo 'hecho, escriba aquí la dirección de su empresa y avise de que voy'. Le tendió la bota al jefe, en un gesto que decía claramente que si bebía, el trato estaba cerrado. Y claro, el jefe bebió mientras pensaba, 'que cojones, aquí el que tiene el MBA soy yo'.
El pastor se levantó, silbó a su perro y le dijo, 'dentro de unas semana vuelvo, de mientras, obedece a este pinpollo'… El perro le miró con incredulidad y acatamiento. Le dio el petate al 'pipollo' y marcho a conocer a su nuevo rebaño. No se sabe quien estaba más acojonado, si el jefe de proyecto o el pastor.
Pasado el estupor inicial, el jefe penso: 'bueno se trata de gestionar recursos ¿no? Llevo haciendo eso años. Seguro que las ovejas saben hacer mejor su trabajo que los desarrolladores. Tengo claro el objetivo, que den lana, y solo necesito crear un plan y exigir su cumplimento'. Con un buen plan y mano férrea seguro que lograba cumplir sus objetivos. El jefe respiró tranquilo cuando recordó que llevaba su flamante PDA y que tenia Project y Excel versión requetemini. Todo estaba solucionado. Dedicó esa noche a trazar un plan. Fue una dura noche, lloviendo y tronando. Las ovejas durmieron a la intemperie, pero no pasaba nada, el tenía 'el plan'. 50 recursos de tipo oveja, a 50 kilos de lana por recurso, 2500 kilos de lana. Un proyecto rentable sin duda…
Al día siguiente el jefe reunió al rebaño. 'Tengo un plan que nos va a llevar a completar el proyecto de manera exitosa. Ya me he comprometido con el señor alcalde, cacique local y comerciante de lana, a entregarle 2500 kilos de la mejor lana en el plazo de dos meses. El alcalde me ha hecho saber su satisfacción y su plena confianza en que conmigo al frente, MBA y gestor de recursos experto, el proyecto va a ser todo un éxito.' Las ovejas no entendían nada. Ellas sabían que el alcalde solía preocuparse más por la leche que por la lana, pero quizás las cosas habían cambiado, que sabían ellas, meros recursos productores de ¿lana? ¿leche?... En cualquier caso, la ovejas, no habían nunca producido tanta lana en tan poco tiempo pero con un buen gestor al mando quizás se obrase el milagro. El project que el jefe tenía era muy bonito… que barritas azules más iguales, oye.
Pasaron veinte días y el jefe de proyecto reunió de nuevo a las ovejas. 'Queridas ovejas, vamos retrasados respecto mi plan. No dudo de que haréis lo necesario para asegurar que producís la lana al ritmo necesario. Espero que todas arriméis el hombro y que no os vayáis a casa sin cumplir con vuestro trabajo. Ya he hablado con el alcalde y le he dicho que no se preocupe que apretaremos nuestro culo bobino y recuperaremos el tiempo perdido'. Las ovejas no entendían nada, ya se sabe que no es un animal demasiado listo… apretaron su ovino culo y se fueron a pastar. Al fin y al cabo no sabían como hacer crecer la lana más rápido… y parecía que el jefe tampoco.
Otros veinte días después, el jefe de proyecto reunió de nuevo al rebaño. 'Malditas ovejas. Os pedí un esfuerzo y no habéis hecho nada. Yo hice el plan y vosotras estáis haciendo que fracase. Como no os apliquéis más algunas de vosotras vais a ir a la *** calle. Y ya sabéis la crisis que hay… puedo encontrar cincuenta como vosotras en cualquier ETT'. La ovejas, una vez más, no entendieron nada. Ya le habían dicho al jefe de proyecto que el que no las metiese en el corral por las noches y que no las hubiese cambiado de prado en todo el tiempo no era muy beneficioso para su lana. Habían pensado que a lo mejor si se movían por el campo como hacían con el pastor, la producción de lana mejorase. También sugerían que el jefe las ordeñase, sabían que el alcalde siempre quería leche... 'Estas ovejas, siempre quejándose de chorradas, ya sabía yo que no eran muy diferentes a los desarrolladores. Que sigan el plan y dejen de quejarse y pensar, para eso ya estoy yo. ¡No hay manera de hacer que trabajen!' había pensado el jefe de proyecto.
Otros veinte días después el alcalde llegó y preguntó al jefe por su lana… el jefe solo tenía 1000 kilos, la ovejas resultaron no ser tan expertas como ponía en su curriculum, inaceptable… que podría haber hecho él… 'No pasa nada jefe', dijo el alcalde, 'tendremos mucha leche entonces'. El jefe se puso rojo y dijo 'leche, que leche, en el contrato no decía nada de leche'… El alcalde dijo, 'me la sopla lo que diga el contrato, lo de la leche se da por supuesto, vaya fracaso del proyecto, no vas a ver un *** duro…'.
En esas llegó el pastor… seguro que el también la habría cagado. 'Mal de muchos, consuelo de tontos, pero consuelo al fin y al cabo' pensó el jefe… '¿Qué tal pastor? ¿Duro el trabajo?' dijo con tonillo de sorna. El pastor contesto, con su simpleza natural: 'Todo ha ido sobre ruedas. Al fin y al cabo los desarrolladores son como ovejas ¿no? Seguro que a ti también te ha ido bien. Los desarrolladores incluso me han regalado un GPS para que marque donde comen mejor mis ovejas… ¡y donde hay setas!. Creo que me han cogido cariño los jodidos, que majetes'. El jefe no salía de su asombro. Los recursos eran agradecidos y todo. ¡Cuéntame que has hecho, por favor!, dijo al pastor.
'Ha sido fácil. Al fin y al cabo los desarrolladores son mucho más comunicativos que las ovejas y cuesta menos reunirlos. Todas las mañanas, sin perro ni nada, les tenía localizados. Además, pensé, no pueden ser muy diferentes que las ovejas, son individualistas y gregarios a la vez. Seguro que si cuido de ellos como hago con mis ovejas obtendré los resultados esperados y a eso me he dedicado estas semanas.'
El pastor continuo 'me pidieron que les consiguiese un servidor de 64 bits para no se que pruebas de rendimiento y de compatibilidad. Yo no tenía ni idea de qué es eso, pero parecía importante para ellos, así que lo conseguí. ¿No busco los mejores pastos para mi ovejas? No es tan diferente…' El jefe de proyecto flipaba, ¿desde cuándo se logra algo de los recursos atendiendo a sus caprichos?…
Luego prosiguió el pastor contando otra situación: 'Un día, los desarrolladores dijeron que no lograban que el rendimiento fuese el adecuado, y que en su opinión lo mejor era tirar de un experto. Así que eso hice busque un experto que les ayudase y les formase. ¿No llevo a mis ovejas al veterinario cuando tienen problemas?'. Ahora sí que el jefe de proyecto no se lo podía creer, ¡formar a los recursos es caro! Y luego se van a la competencia en cuanto saben.
'Me acuerdo de otra cosa curiosa', dijo el pastor: 'Otro día los desarrolladores me contaron que no lograban avanzar. Eso me preocupó. ¿Se supone que los desarrolladores deben avanzar en la funcionalidad, es su lana y su leche, no?. El problema, contaron, es que los comerciales estaban continuamente demandando pequeñas modificaciones, visitas a clientes, que atendiesen llamadas… Parece que los lobos acechan, pensé yo. Así que puse un poco de orden y deje claro que a mi rebaño no se le molesta'.
El pastor concluyo: 'la verdad es que no he hecho mucho ¿no?. Los desarrolladores son como las ovejas, si dejas que hagan su trabajo y pones las condiciones para que lo hagan, al final puedes recoger los resultados'.
En estas despertó el jefe de proyecto y pensó: 'joder, como pega el vino del pastor, vaya siesta y vaya sueño más raro', mientras veía al pastor perderse por el horizonte con su rebaño.
Yo me pregunto: ¿A que se parece más el trabajo de Scrum Master, cuyo principal cometido es eliminar los impedimentos que encuentra el equipo, al de un Jefe de Proyecto clásico o al de un pastor?.
Ya lo dijeron DeMarco y Lister en su imprescidible Peopleware, el trabajo del gestor de proyectos no es hacer que la gente trabaje, sino construir el entorno en el que trabajar sea posible.