lunes, mayo 30, 2005

Si los programadores fueran albañiles...

Casi de casualidad, me encontré con este artículo sin autor declarado, en la bibliografía del curso de Ingeniería de Software I del Politécnico de Albacete.

Uno de Enero

Hoy me han llevado al solar por primera vez. La situación es perfecta: tiene el Metro a dos pasos y una cafetería enfrente donde sirven menú del día. El viejo bloque de pisos, al que va a sustituir nuestra nueva construcción, lleva un año al borde de la ruina. Mi propia empresa ha colocado varios puntales que, por el momento, han ido evitando que el caduco edificio reviente por sus múltiples grietas. La construcción de este megalito de ladrillo dió comienzo hace cinco años, y aunque los pisos superiores nunca llegaron a recibir el agua, la electricidad y el enfoscado de las paredes, en diez meses los cimientos ya se habían desplazado peligrosamente y las vigas presentaban peligrosas fisuras. La cansada torre de viviendas ya ha cumplido su propósito y ahora nosotros la conduciremos a una muerte dulce. Por supuesto, el viejo edificio no será demolido hasta despues de construir y probar el nuevo, lo que nos deja poco espacio de maniobra; pero no vamos a dejar a todas esas familias en la calle durante la construcción. De cualquier modo, los vecinos de la vieja y decadente estructura nos miran con recelo. Saben que el nuevo edificio tendrá viviendas mas cómodas, pero algunos de los residentes no podrán costearlas. Ni se qué va a ser de esta gente, ni es asunto mío. Llegan los primeros camiones de ladrillos.

Dos de enero

Me han presentado a Alberto, la persona a quien "voy a reportar". No me han dicho si es el capataz, el jefe de obra, el aparejador, o el arquitecto; sólo me han dicho que todo lo que tenga que "reportar", se lo "reporte" a él. Así que, por donde él diga, yo zaca-zaca, como una locomotora. Esa es la definición que me han dado de nuestra metodología. He buscado "reportar" en el diccionario, y no aparece.

Seis de febrero

En algo más de un mes, hemos cavado medio metro de cimientos. Ayer Alberto nos dijo que empezáramos a poner ladrillos, porque el tiempo designado para la cimentación se había agotado hace dos semanas. No acepto nuestras excusas de que las prometidas excavadoras aun no habían llegado y que nos habíamos visto obligados a cavar con las paletas de enyesar. Un compañero se trajo una pala de cavar que guardaba de una obra anterior y casi le echan por razones deontológicas. Según Alberto, lo que pasa es que frecuentamos demasiado la cafetería. El asunto se ha zanjado con un «hale, a levantar paredes y luego que cada palo aguante su vela». El trabajo sin planos es dificultoso. Los cimientos tienen una forma algo pintoresca. He pedido una plomada para que las paredes queden verticales y he recibido improperios poniendo en duda mi masculinidad. Ya sé que Alberto no es el arquitecto, porque el arquitecto es un tal Ignacio. Pasó a supervisar la obra el otro día, aunque aun no había nada que ver. Me han llegado rumores, aunque no son muy dignos de crédito, de que existen fotocopias de planos.

Doce de mayo

Anoche estuvimos hasta las siete de la mañana cubriendo con tablas y enmoquetando el espacio que algún día ocupara el despacho de la sexta planta, aunque el edificio no es aun mas que una maraña de vigas de todos los tamaños y algunas paredes que habrá que tirar más tarde porque están en el sitio equivocado. Hemos traído baterías para los fluorescentes y unos muebles de caoba preciosos. Por suerte, todo estuvo a punto para la demo. Izamos al cliente con la grúa hasta su futuro despacho y pudo contemplar la vista que se disfrutaría desde el emplazamiento. El viento hizo que la pared oeste, que dos de mis compañeros sujetaban con la espalda, se derrumbara con gran estruendo sobre la mesa de caoba en el peor momento. Gracias a Dios, el cliente fue comprensivo: esto pasa siempre en las demos, y él está curado de espanto, dijo mientras le sacudíamos el polvo del traje. Dice que el lunes que viene vendrá a probar las instalaciones sanitarias. Supliremos con cubos la inexistencia de tuberías.

Veintitrés de febrero

Han transcurrido casi catorce meses. Llevamos ya siete de retraso y el edificio no acaba de superar el estado de "casi terminado". Soy de los pocos albañiles que no ha cambiado de obra en este tiempo. Alberto esta consumido por la zozobra y se pasa el día en la cafetería trasegando Soberanos. El arquitecto no ha vuelto a pasar por aquí. Los rumores dicen que existieron unos planos, pero no eran de un bloque de pisos, sino de un polideportivo. Por lo visto, en las reuniones del comité de construcción se dijo que la filosofía era la misma y que sólo harían falta modificaciones mínimas. Ahora comprendo por qué nos hicieron instalar aros de baloncesto en el hueco del ascensor. Siempre dije que acabaríamos teniendo que quitarlos o aquello no era un hueco de ascensor, que era cuestión de lógica. Alberto siempre me contestaba que no le viniera con tecnicismos. Estoy perdiendo la vocación de albañil. He decidido apuntarme por las tardes a un curso de informática, a ver si puedo cambiar de vida. Este oficio mío no es serio

* Publicado en la sección "Cartas del iluso" de la revista Solo Programadores, número 19, Marzo 1996.

Copyright © 1994-1998, ATI, Asociación de Técnicos de Informática.

viernes, mayo 27, 2005

¿Abarca y Devora III? - Un comentario posiblemente muy a propósito...

Publicado el 16 de abril de este año en WillyDev.Net, el artículo indicado en el enlace del título tuvo la virtud de molestarme, dejándome con el disgusto de no poder discutir sus afirmaciones, no sólo con el prologuista o el traductor, sino al menos con sus soportes en WillyDev, quienes lo consideraron excelente. No leí, y es improbable que lo haga, el libro que motiva el prólogo de Joel Spolsky (En busca de la estupidez, de Rick Chapman), que puede o no -seguramente sí- ahondar en la línea del prologuista, pero es lo que éste dice lo que en principio me desagrada.
En primer lugar, el tono del escrito, que pareciera preparado por un fan adolescente de Microsoft (mal iría a leer un libro de análisis de tendencias presentado por un fan adolescente). Su visión del "ñoño-opositor-linuxero" me temo que muy bien le pudiera caber a él mismo. Una persona que piensa que los problemas de competencia comercial que se dirimieron en el período que ejemplifica, pudieran reducirse a una guerra de fans, desconoce probablemente el impacto que esas guerras comerciales dejaron. O se trata de un documento destinado a captar el entusiasmo de los nerds del bando propio...
En segundo lugar, una de sus dos afirmaciones centrales: "Microsoft es la única empresa de la lista (de grandes compañias de software) que no ha cometido un error garrafal e insensato". Quizá sea de interés estudiar los errores de sus competidores caídos, pero pensar que ese punto explica el predominio de Microsoft, es ignorar u ocultar otro elemento fundamental de su predominio: la utilización a destajo de su posición dominante, que está expresada en una cadena interminable de juicios por monopolio (Windows Media Player, Netscape, por sólo mencionar dos bien conocidos, no son reflejos de errores estratégicos del competidor, sino de abuso de posición monopólica, y es revulsivo escuchar al prologuista explicar la caída de Netscape por el plan de reescritura del código, ignorando la demanda sustentada a través de varios años, acerca de la inclusión forzosa de IE dentro de Windows). Más aún, seremos expectadores privilegiados de la historia, ya que ahora va por Google, y veremos allí cómo se aplica la doctrina de "no cometer errores garrafales": MSN Search también estará incluída en todo lo que fuera Windows, y, si usted es usuario de Messenger, podrá notar que es forzado a actualizarse a la nueva versión 7.0 incondicionalmente, y cuasi forzado a aceptar el MSN Search incluído en la actualización; al menos a mí, me resulta ultrajante que no pueda abrir mi versión 6.x si no acepto la 7.0 (algo parecido con XP). Las discusiones en la Unión Europea y China acerca de las reglas de conducta del gigante, creo que eximen de comentarios.
Spolsky supone un segundo argumento justificativo del predominio de MS, y es que está a su frente un programador. Creo que le hace muy poco mérito a Gates...

Abarca y Devora II - Descripción del invento

Data Structure Mappings: Un esquema Relacional a un esquema Orientado a Objetos; cómo es cubierto por la patente apuntada en la nota anterior.
Lo que sigue es la lista de Claims de la patente:
What is claimed is:

1. A system that facilitates mapping arbitrary data models, comprising a mapping component that receives respective metadata from at least two arbitrary data models, and maps expressions between the data models.

2. The system of claim 1, the data models are query languages.

3. The system of claim 1, the data models are data access languages.

4. The system of claim 1, the data models are data manipulation languages.

5. The system of claim 1, the data models are data definition languages.

6. The system of claim 1, the data models include at least an object model and at least one relational model where the object model is mapped to at least one of the relational models.

7. The system of claim 1, the data models include object models where one of the object models is mapped to at least one of the other object models.

8. The system of claim 1, the data models include an XML model and at least one relational model where the XML model is mapped to at least one of the relational models.

9. The system of claim 1, the data models are XML models where one of the XML models is mapped to at least one of the other XML models.

10. The system of claim 1, the data models include an XML model and at least one object model where the XML model is mapped to at least one of the object models.

11. The system of claim 1, the data models are relational models where one relational model is mapped to at least one of the other relational models.

12. The system of claim 1, the data models include an XML model and an object model where the object model is mapped to at least one of the XML models.

13. The system of claim 1, the data models are of the same structure.

14. The system of claim 1, the mapping component receives topology data that is derived from the metadata.

15. The system of claim 1, the data models are read-only.

16. The system of claim 1, the data models are mapped without modifying the metadata or structure of the data models themselves.

17. The system of claim 1, the expressions comprise at least one of a structure, field, and relationship.

18. The system of claim 17, the expressions mapped between the data models are at least one of the same, different, and a combination of the same and different.

19. The system of claim 1, the mapping component creates structural transformations on the data of a data model by at least one of creating or collapsing hierarchies, moving attributes from one element to another, and introducing new relationships.

20. The system of claim 1, the mapping component relates and connects the same mappable concepts between the data models.

21. The system of claim 1, the mapping between the data models is directional.

22. The system of claim 1, the data models include a source domain and a target domain, such that a structure and field of the target domain can be mapped at least once.

23. The system of claim 1, the data models include a source domain and a target domain, such that a structure and field of the source domain can be mapped multiple times.

24. The system of claim 1, the data models include a source domain and a target domain such that the mapping component allows a user to operate on the data models through a query language of the target domain.

25. The system of claim 1, the data models include a source domain and a target domain such that the source domain is the persistent location of the data.

26. The system of claim 1, the data models include a source domain and a target domain such that mapping translates a query written in a query language of the target domain into a query language of the source domain.

27. The system of claim 1, the mapping component facilitates automatically synchronizing updates made in a target data model to a source data model.

28. The system of claim 1, the mapping component includes a mapping file that maps like concepts of the respective metadata.

29. A computer executing the system of claim 1.

30. A system that facilitates mapping arbitrary data models, comprising: source metadata that represents source concepts of a source data source; target metadata that represents target concepts of at least one target data source; and a mapping component that receives the source metadata and the target metadata and maps the concepts from the source data source to the target metadata associated with one or more of the target data sources.

31. The system of claim 30, the mapped concepts are at least one of the same, different, and a combination of the same and different.

32. The system of claim 30, the data sources are of the same structure.

33. The system of claim 30, the source concepts and the target concepts are the same in both of the data sources.

34. The system of claim 30, the mapping component relates and maps the same concepts between the data sources.

35. The system of claim 30, the source and target concepts include a relationship element that is a link and association between two structures in the same data source.

36. The system of claim 35, the relationship element defines how a first structure relates to a second structure in the same data source.

37. The system of claim 30, the source data source and the target data source are disposed on a network remote from the mapping component.

38. The system of claim 30, the mapping component is local to at least one of the source data source and the target data source.

39. A method of mapping data between data models, comprising: receiving respective metadata from at least two arbitrary data models; and mapping expressions between at least two of the data models based upon the metadata.

40. The method of claim 39, the expressions mapped between the two data models are the same expressions.

41. The method of claim 39, further comprising defining a source data schema and a target data schema and information missing in the schemas.

42. The method of claim 39, further comprising transforming data during a mapping of a source data model to a target data model using a function.

43. The method of claim 39, further comprising synchronizing changes made in a target data model with a source data model.

44. A method for mapping arbitrary data models, comprising: receiving source metadata that represents source concepts of a source data source and target metadata that represents target concepts of a target data source; and mapping the concepts between the source and target data sources based upon the source metadata and the target metadata.

45. The method of claim 44, the data sources are of the same structure.

46. The method of claim 44, further comprising, creating a variable in a source domain; restricting the variable with conditions; and mapping the variable to the target concept.

47. The method of claim 46, the variable is created at least one of implicitly and explicitly.

48. The method of claim 46, the variable represents an empty result set.

49. The method of claim 44, the mapping is stackable between the source and target data via one or more intermediate mapping stages.

50. The method of claim 44, further comprising selecting an optimal path for mapping between the source and the target.

51. The method of claim 50, the optimal path is selected with a central control entity based on at least one of available bandwidth and interruptions in the path.

52. The method of claim 44, further comprising accessing a mapping algorithm in response to selecting an optimal path between a plurality of the data sources and plurality of the data targets.

53. The method of claim 52, the mapping algorithm is associated with a structure of the source data and the target data.

54. A system that facilitates mapping data between arbitrary data models, comprising: means for receiving source metadata that represents source concepts of a source data source and target metadata that represents target concepts of a target data source; and means for mapping the concepts between the source and target data sources based upon the source metadata and the target metadata.

55. The system of claim 54, the means for mapping includes a mapping means that relates and maps the same concepts between the data sources.

jueves, mayo 26, 2005

Mel Brooks: "Abarca y Devora"

Una noticia de los últimos días: un grupo de desarrolladores patentó el mapeo entre estructuras de datos. Extractado por The Server Side:
The patent is A data mapping architecture for mapping between two or more data sources without modifying the metadata or structure of the data sources themselves. Data mapping also supports updates. The architecture also supports at least the case where data sources that are being mapped, are given, their schemas predefined, and cannot be changed.
En la lista de propietarios de la patente aparece un número importante de personas vinculadas a Microsoft. La voz común es considerar que es Microsoft mismo quien avanza sobre una idea que fue ampliamente aplicada a través de muchos años por muchas empresas, que puede incluír distintos perfiles de problemas, pero que es señalada especialmente como amenaza a los diseños existentes en OR mapping (mapeo de relacional a objeto y viceversa).
Primer contacto con la noticia, una advertencia temprana de Jack Herrington en CGN-Talk, desde donde se puede leer el contenido completo de la patente aprobada, y los nombres de sus propietarios. Luego, la nota en The Server Side apuntada en el título de éste artículo, aribuyendo a Microsoft la acción, y, fundamentalmente, las consecuencias. Como en la discusión de The Server Side se dice, una patente no es definitiva, sino controversial; pero implica un avance definido hacia un objetivo restrictivo: poner una idea que en varios aspectos es de dominio público y académico, en manos de un grupo de beneficiarios de futuros reclamos de propiedad intelectual.
Aunque es temprano para atribuirle un padre, los "indicios vehementes" señalan uno, y uno acostumbrado a moverse con estos valores.
La siguiente es la introducción descriptiva del invento:
[0004] The present invention disclosed and claimed herein, in one aspect thereof, comprises a mapping format designed to support a scenario where two (or more) data sources need to map to each other, without modifying the metadata or structure of the data sources themselves. Mapping is provided, for example, between an Object space and a relational database, Object space and XML data model, an XML data model and a Relational data model, or mapping could be provided between any other possible data model to XML, relational data model, or any other data model. The mapping format supports updates, and also supports the case where both data sources being mapped are given, their schemas are predefined, and cannot be changed (i.e., read-only). An approach that was previously used to map, for example, XML data to a relational database required making changes to the XML schema definition (XSD) file in order to add annotations. The mapping format of the present invention works as if the XSD file is owned by an external entity and cannot be changed. It also allows reuse of the same XSD file, without editing, for multiple mappings to different data sources (databases, etc.).

[0005] Each data model exposes at least one of three concepts (or expressions) to mapping: structure, field, and relationship. All of these concepts can be mapped between the data models. It is possible that one data model may have only one or two of the expressions to be mapped into another data model that has three expressions. The mapping structure is the base component of the mapping schema and serves as a container for related mapping fields. A field is a data model concept that holds typed data. Relationship is the link and association between two structures in the same data model, and describes how structures in the same domain relate to each other. The relationship is established through common fields of the two structures and/or a containment/reference where a structure contains another structure. These are just examples of relationships, since other relationships can be established (e.g., siblings, functions, . . . ). The present invention allows establishing arbitrary relationships. A member of a data model can be exposed as a different mapping concept depending on the mapping context.

[0006] Semantically, mapping is equivalent to a view (and a view is actually a query) with additional metadata, including reversibility hints and additional information about the two mapped domains. When one data source is mapped to another, what is really being requested is that it is desired that the Target schema is to be a view of the Source schema. Mapping is a view represented in one data domain on top of another data domain, and defines the view transformation itself. Mapping can create complex views with structural transformations on the data, which transformations create or collapse hierarchies, move attributes from one element to another, and introduce new relationships.

[0007] Mapping relates and connects the same mappable concepts between two or more mapped models. Mapping is also directional. Thus, one domain is classified as a Source and the other is classified as a Target. The directionality of mapping is important for mapping implementation and semantics, in that, a model that is mapped as a Source has different characteristics then a model that is mapped as a Target. The Target holds the view of the source model, where the mapping is materialized using the query language of the target domain. The Source is the persistent location of the data, and mapping translates the query written in the target domain query language to the source domain query language. One difference between Source and Target is that a structure or field from the Source or Target model has some restrictions regarding the number of mappings that can apply for structures and fields. In the target domain, a structure and a field can only be mapped once, whereas in the Source domain, a structure and a field can be mapped multiple times. For example, a Customers table can be mapped to a BuyingCustomer element and a ReferringCustomer element in the Target domain. However, a local element or local class can be mapped only once. Another difference that stems for the directional attribute of mapping is that mapping allows users to operate on the mapped models through the query language of the target domain (e.g., using XQuery for mapping a Relational model to an XML model, and OPath, for mapping a Relational model to an Object model).

[0008] Another important attribute of the mapping architecture is that of being updateable. In the past, developers had to write code to propagate and synchronize changes between the domains. However, in accordance with the present invention, the mapping engine now performs these tasks. That is, when the user creates, deletes, or modifies a structure in the target domain, these changes are automatically synchronized (persisted) to the source domain by the target API and mapping engine.

[0009] In another aspect thereof, the mapping architecture is stackable where multiple stages of mappings may occur from a source to a target.
Quisiera destacar el último párrafo de la introducción:
[0010] To the accomplishment of the foregoing and related ends, certain illustrative aspects of the invention are described herein in connection with the following description and the annexed drawings. These aspects are indicative, however, of but a few of the various ways in which the principles of the invention may be employed and the present invention is intended to include all such aspects and their equivalents. Other advantages and novel features of the invention may become apparent from the following detailed description of the invention when considered in conjunction with the drawings.
...

martes, mayo 17, 2005

El compromiso europeo con MDA

Dos muestras del notable interés comprometido en Europa con la consolidación de un estándar MDD: Modelware y UMT-QTV
Modelware en su presentación en dos palabras:

There is a growing gap between the demands of the end-users and the solutions the currently used methods of software development achieve. A paradigm to close this gap consists of the use of models for the construction of software. Model Driven Development (MDD) puts this concept on the critical path of the software development. The ultimate goal of the project MODELWARE is the large-scale deployment of Model Driven Development.

MODELWARE has three major objectives:

  • Objective A: To develop a solution to enable a 15-20% productivity increase of software systems development. This solution will be based on MDD.
  • Objective B: To lead the industrialisation of the solution.
  • Objective C: To ensure the successful adoption of that solution by industry.

Based on the exploitation of higher levels of abstractions in the specification and design of software systems, MODELWARE provides a rigorous and coherent framework bringing major improvements in engineering processes. The framework automates the production of most software artefacts (tests, documentation, code, etc) and allows better capitalisation of know-how.

MODELWARE establishes the missing link between advanced formal approaches proposed by the academic communities and more traditional industry driven engineering solutions.

MODELWARE defines and develops the complete infrastructure required for large scale deployment of Model Driven Development strategies and validates it in several business areas. MODELWARE combines innovations in modelling technologies, tool development (both generic and domain specific), standardization, experimentations, change management, and users-suppliers relationships.

Entre otros colaboradores destacables, tales como France Telecom, el Fraunhofer Gesellschaft de Alemania, e IBM UK, quisiera destacar a la Universidad Politécnica de Madrid, y a Jean Bézivin, por el Institut National de Recherche en Informatique et en Automatique de Francia.


UMT-QTV en su parca presentación:

UMT-QVT is a tool for model transformation and code generation of UML/XMI models. UMT-QVT provides an environment in which new generators can be plugged in. The tool environment is implemented in Java. Generators are implemented in either XSLT or Java.

UMT-QVT is the 'Sourceforge' name for the UMT tool, which is short for UML Model Transformation Tool. It is not, as you may or may not assume, an implementation of the forthcoming OMG QVT (Query, View, Transformation) standard. However, it might migrate towards that eventually.....

Jon Oldevik, de Noruega, ofrece más información en su sitio ModelBased.

miércoles, mayo 04, 2005

Extreme Programming revisitado

Timothy Fisher publica en su blog soportado por Sys-Con, un artículo comentando pros y contras de XP. Probablemente, como dice el artículo, dando una visión imparcial del alcance y valía de su práctica. Recuerdo haberme interesado en XP hace alrededor de cuatro años, inicialmente con entusiasmo por algunos de sus principios, y luego con mayor moderación en cuanto conocía más el conjunto de reglas que recomendara, y en tanto conocía mejor las opiniones y actitudes de sus mentores. Con el tiempo, tomé el camino de adoptarlo como un conjunto de prácticas, algunas de las cuales me parecen excelentes, y otras que dejo para sus integristas, que parece que los tiene. Adhiero casi por completo al balance de Timothy, y quizá le pusiera el acento a algún otro elemento, especialmente a su visión de los proyectos como "historias sin fin", y a su desapego al modelado del proyecto (dos puntos vinculados sin duda).
Los "pros"de Timothy:

Testeo
Unit testing has certainly been around for many, many years, but it's certainly not unreasonable to say that we owe a great deal of today's increased emphasis on unit testing to XP. Unit testing was promoted as one of XP's core practices. Along with the recognition of unit testing as a powerful aid to developers came the methodology of test-driven development. This is a development style in which unit tests are always written prior to the code which they are testing.
Plan de trabajo

What XP refers to as the "planning game", is another good practice that can be carried over into other methodologies. XP does a very good job in maintaining schedules, plans, and keeping the plan very current. The iteration and build strategies advocated by XP are very good strategies for any project. Amongst these strategies, XP advocates frequent releases, short and well defined development iterations, frequent builds, and emphasis on build automation. Whether you choose to practice XP or not, these are strategies that add value to any methodology.
En este caso, el plan es referido al corto plazo. En este terreno, XP es muy interesante, y quisiera aplicar tanto como pudiera especialmente el objetivo de releases cortos: Ciclo corto de desarrollo tanto como se pueda.
...
Otros aspectos en pro no son mencionados, sino brevemente agrupados en el punto anterior. Quisiera agregar un "pro" apenas indicado al comienzo de su artículo: la propiedad común, o quizá mejor comunitaria, del código. Seguramente no llevado al extremo de la rotación diaria en la escritura de código, pero la rotación en la construcción del código es un elemento fuerte para lograr un mejor dominio del producto en el que se trabaja. Todo lo contario a la práctica usual, donde cada participante de un proyecto suele estar especializado en una actividad. En realidad, Timothy critica como uno de los "cons" de XP este concepto:
XP also does not believe in the need for "experts". Their philosophy is that all programmers should be well balanced on all technologies employed by the application. While this sounds admirable as a goal, the reality of this is that you kill the enthusiasm of an expert, and encourage a mediocre understand of all technologies in all your programmers. It is simply not realistic for all programmers to become experts in all of a project's technologies. Individuals who want to gain expertise in a specific technology, such as security, GUI design, databases, etc. are discouraged.
Creo que aquí coexisten dos aspectos: uno, que también veo, es el poco acento puesto en el análisis global o de largo plazo, dando primordial importancia a la escritura de código. El otro aspecto es la rotación en la elaboración del trabajo: Es cierto que un especialista no debe ser reemplazado, y que su trabajo tiene su cualidad propia, pero, en primer lugar, rotar entre pares es posible y recomendable, para mejorar el conocimiento global del producto en construcción, al menos lo suficiente para que un área no dependa de una sola persona. Adicionalmente, la visión global cohesiona y posibilita incluso la mejora a través de la observación del par.

Los "cons" de Timothy (the not so good):

El cliente en el equipo
Another core practice of XP asks you to keep a customer representative onsite with your development team so that you are able to quickly work out requirements confusion, get answers to questions, and get feedback on your progress. This sounds great, but it’s the practice I usually refer to as the fantasy practice. We'd all love to have James Gosling onsite also in case we run into any Java problems, but it's simply not realistic, just as having an onsite customer is not realistic in most cases. When you are able to achieve this, absolutely go for it. It's a grand idea, but not one that a software development methodology should rely on as a core practice.
Hacer las cosas simples
XP also tends to be full of short catch phrases summarizing its core principles. One of those is "Do the Simplest thing Possible." Here they are advocating that you should always implement the simplest, least complicated solution to the task at hand. They specifically warn against coding for anticipated future extensibility and add-ons that may or may not actually happen. While in general, this may not be bad advice, I think making this a core principle of XP is going too far with this attitude. Often, it does make a great deal of sense to spend the time to implement something that, while not necessarily the simplest solution, is a smarter and better solution. Remember this; the simplest solution is not always the best solution. This tenet seems to be born out of programmers who are adverse to strategic design, analysis, and modeling and simply want to code.(El subrayado es mío)
Aquí adhiero en tanto la simplicidad tenga relación con la oposición a un desarrollo de visión estratégica. Por lo demás, la simplicidad es recomendable.

Programación de a pares:

En este punto adhiero por completo a su criterio, al que remito. Sólo le agrego una especialización "local". Quisiera saber cuántos equipos de trabajo de Latinoamérica podrían disponer equipos de pares para escribir código en una máquina...

El código es toda la documentación:

While not an official XP practice, it is a common belief in the XP community that source code alone can serve as the developer documentation for a project. This may be fine for the developers currently working on the project, but have you ever tried joining a project in progress with a large code base and being told that the only documentation for what they've created so far is the source code? Believe it or not, many XPers would say that is perfectly fine, and this is how they document their projects. Again here, we have a failure to consider the future and what is strategically best for the organization as a whole.

En resumen...

The best way to view XP is as a collection of principles which may be applied to your software development project individually or in sets. You should not be dogmatic in your views about XP and believe that it is an all or nothing methodology. I'd go a step further even and refer to XP as a methodology toolbox, rather than a methodology
De acuerdo, Timothy. La mejor actitud sería tener una cartilla de XP a mano, y releerlas para reconsiderar el trabajo de la próxima semana, pero como auxiliar de tu método predefinido de trabajo...