Garantias y responsabilidades en Epaña , vistopor los clientes

3.6.2. Distincion entre garantías y responsabilidades

Ambas figuras –garantía y responsabilidad– se solapan parcialmente y resultan algo difíciles de distinguir. Mejor dicho, podemos afirmar que las
“responsabilidades” son una de las consecuencias a las que puede dar lugar la infracción de una garantía.
Garantías
Denominamos garantías a los compromisos u obligaciones que el proveedor-licenciante asume a favor del usuario respecto a las condiciones (características,
prestaciones, buen funcionamiento) que debe cumplir el software objeto de la licencia.
De este modo, si el software no cumple o deja de cumplir en algún momento dichas condiciones, el proveedor-licenciante está obligado a emprender las
actuaciones oportunas para que el software se ajuste a las mismas.
En particular, cabe destacar la garantía de buen funcionamiento, en virtud de la cual el proveedor debe asegurar al usuario-licenciatario que el software funcionará
correctamente durante el plazo de vigencia de la licencia –o, al menos, durante un tiempo determinado– de modo que, en caso de que el software presente algún
fallo, prestará la asistencia oportuna al usuario para remediarlo.
A todo software se le atribuyen unas características y prestaciones determinadas en función del tipo de software de que se trate; así como de aquellas características
especiales que el proveedor haya incluido en la licencia (o bien en la documentación accesoria, envoltorios, folleto, publicidad, etc.). Además, se entiende que el
software estará siempre listo para funcionar correctamente, cuando el usuario decida ejecutarlo correctamente. De lo contrario, estaremos ante una incidencia debida
a un fallo de funcionamiento o bien el software presentará un defecto.
Las licencias de uso regulan qué garantías debe prestar el proveedor, el modo de prestarlas y el plazo (durante cuánto tiempo, a partir del inicio de la licencia). Es
decir, en el caso de que ocurriera alguna de las incidencias descritas, el proveedor-licenciante asistirá o no al usuario para poner fin a la incidencia y, en su caso,
como le asistirá.
El modo de poner fin a la incidencia será mediante:
Reparación del fallo o defecto
Sustitución de la copia por otra
Resolución o cancelación de la licencia: El proveedor devuelve el precio al usuario y devolviendo éste la copia del software al proveedor.
En principio, el usuario sólo podrá acudir a la resolución de la licencia como último recurso, cuando no sea posible la reparación del defecto o sustitución de la
copia.
En cualquier caso, las cláusulas de las licencias que estipulen las garantías –así como sus posibles limitaciones o exoneraciones– deberán respetar una serie de
normas legales imperativas que, en cada país, obligan a prestar unas garantías mínimas sobre el software.
Creemos conveniente explicar de manera sencilla las clases y origen legal de las garantías. En derecho continental, como en España, las clases y categorías jurídicas
de las garantías son distintas respecto de las propias del derecho anglosajón. Sin embargo, muchas licencias de software, aun escritas en castellano y para regir en
España, hacen referencia a las garantías típicas del derecho anglosajón. Esto hace que la redacción de dichas cláusulas nos parezca poco clara y confusa, incluso para
los propios juristas.
El contenido y alcance de las garantías es similar en ambos casos, así como las acciones que se estipulan a favor del usuario para hacerlas efectivas: reparación,
sustitución de la copia o devolución del precio con cancelación de la licencia.
Conforme al derecho español, las garantías sobre el software serían las siguientes:
La garantía de saneamiento frente a defectos ocultos, por aplicación analógica de las normas que regulan la compraventa (Código civil y Código de
Comercio): el licenciatario podrá reclamar –en el plazo de los 6 meses siguientes al inicio de la licencia– que se le devuelva el dinero y se cancele la licencia,
o bien que el proveedor le rebaje el precio abonado. Esta garantía será aplicable, por analogía, a muchas de las licencias, en particular las del software
comercializado en masa a consumidores.
Los Tribunales vienen aplicando a las licencias de uso, por analogía, la garantía de saneamiento frente a defectos ocultos. Aun en el caso que una licencia de uso, por
sus circunstancias específicas sea asimilable, no a una compraventa, sino a un arrendamiento de cosa, de obra o prestación de servicio (por ejemplo, por concederse
para un plazo determinado; por obligarse el proveedor a adaptar el software a necesidades particulares del usuario, a realizar tareas de instalación, etc.), se entienden
que rigen garantías similares:
Deber del proveedor de mantener al usuario en el uso normal y pacífico del objeto contractual (garantía propia en el arrendamiento de cosas).
Deber de mantener el resultado final en las condiciones pactadas (garantía propia en el arriendo de obra).
Deber de prestar el servicio con la diligencia propia de un profesional en la materia (garantía propia de la prestación de servicios).
El incumplimiento de estas garantías da lugar a que, en este caso el usuario, pueda pedir igualmente la reparación del defecto, sustitución de la copia o resolución de
la licencia (devolviéndose las partes, respectivamente, la copia del software y el precio abonado).
La garantía de buen funcionamiento del software, por aplicación de la normativa sobre garantías en la Ley General de Defensa de los Consumidores y
Usuarios (art. 11).
En el plazo mínimo de 6 meses, el licenciatario podrá reclamar frente al proveedor, en caso de error, defecto o falta de las condiciones óptimas para cumplir el uso a
que esté destinado el software. El proveedor estará obligado a reparar el error (debiendo de tener un servicio técnico adecuado para ello) y, si la reparación no es
posible o satisfactoria, deberá sustituir la copia del software por otra o devolver el precio pagado al licenciatario.
16/7/2019 3.6.2. Distincion entre garantías y responsabilidades | Gestiweb: Eneboo ERP software libre - Diseño y desarrollo web - Tiendas on-…
https://www.gestiweb.com/?q=content/362-distincion-entre-garantí-y-responsabilidades 2/7
‹ 3.6.1. Consideraciones generales up 3.6.3

Garantias y Responsabilidades 

Extraido de: www.todaviasomospocos.com

2.2.2 “Entregables” o servicios específicamente delimitados en relación al software.

– Contra el pago final de los Servicios, el Cliente obtendrá una licencia perpetua, no
exclusiva e intransferible, para propósito de su negocio interno, para utilizar, copiar, modificar y
preparar trabajos derivados de los Entregables que sean desarrollados en el transcurso de los
Servicios, debiendo cumplir con cualquier restricción de cualquier material de un tercero
contenido en los Entregables. La Empresa retendrá todo otro derecho de propiedad intelectual
sobre los Entregables. Sujeto al cumplimiento de las obligaciones de confidencialidad, cada
parte podrá usar los conceptos, técnicas y know-how utilizados y desarrollados durante la
prestación de los Servicios. En cualquier caso, la Empresa no tendrá restricción alguna en
desarrollar, para sí misma o para otros, materiales que puedan entrar en competencia con los
Entregables, independientemente de su semejanza con los Entregables. Asimismo, la
Empresa podrá usar con entera libertad sus conocimientos, habilidades, experiencia y
cualquier idea, concepto, conocimientos técnicos (know-how) y técnicas que hayan sido
usados en el curso de la prestación de los Servicios. Durante la prestación, la Empresa podrá
utilizar productos, materiales, herramientas y metodologías que sean propiedad de la Empresa
o de terceros licenciantes de la Empresa (conjunta y convencionalmente, el “Capital de
Conocimientos de la Empresa”). El Cliente no tendrá ni obtendrá derechos sobre el Capital de
Conocimientos de la Empresa (o cualquier modificación o mejoras al mismo), distintos a: (i) el
uso del Capital de Conocimientos de la Empresa según sea periódicamente autorizado por
escrito por la Empresa, únicamente para los fines de cumplir con las responsabilidades del
Cliente; (ii) en la medida en que el Capital de Conocimientos de la Empresa sea incorporado a
un Entregable, su uso como parte del Entregable, únicamente para fines internos del negocio
del Cliente; o (iii) de conformidad con los términos de las licencias estándares de la Empresa
respecto de dicho Capital de Conocimientos de la Empresa o, en el caso de tratarse de Capital
de Conocimientos de la Empresa de propiedad de terceros, conforme a los términos
aceptables para el tercero que corresponda. Si cualquier Capital de Conocimientos de la
16/7/2019 Contratos de Software y Consultoría Profesional en la República Argentina | Todavía Somos Pocos
www.todaviasomospocos.com/aportes/contratos-de-software-y-consultoria-profesional-en-la-republica-argentina/ 8/24
Empresa es puesto a disposición del Cliente bajo el apartado (i) que antecede, dicha puesta a
disposición se considerará bajo la modalidad “as-is” (“en la condición en que se encuentra”) y
sin garantía alguna, expresa o implícita, de ningún tipo y cualquier Capital de Conocimientos
de la Empresa puesto a disposición conforme al apartado (iii) precedente estará sujeto,
únicamente, a los términos de la licencia aplicable. Entre el Cliente y la Empresa el Capital de
Conocimientos de la Empresa será considerado como Información Confidencial de la
Empresa.
– La Empresa otorga al Cliente una licencia no exclusiva, intransferible, no asignable y
gratuita para utilizar el Producto de Trabajo mientras que el Cliente mantenga la licencia del
Software con el que opera el Producto de Trabajo. La Empresa no está obligada a
proporcionar soporte o mantenimiento continuo para cualquier Producto de Trabajo. La
Empresa conservará la titularidad del Producto de Trabajo y cualquier técnica, oficio, concepto
o conocimiento técnico (know-how) que se utilicen o desarrollen durante la prestación de los
Servicios. Los sistemas prototipo y los programas de muestra proporcionados por la Empresa
están diseñados para ayudar al Cliente a aprender a usar el Software y para efectos de
demostración; no están diseñados para ser usados con propósitos de producción sin antes no
fuesen efectuadas las pruebas adecuadas.

2.3 Límite de Responsabilidad y Garantías.
16/7/2019 Contratos de Software y Consultoría Profesional en la República Argentina | Todavía Somos Pocos
www.todaviasomospocos.com/aportes/contratos-de-software-y-consultoria-profesional-en-la-republica-argentina/ 9/24
Continuando un poco con el análisis que comenzamos en el punto anterior “in-fine”, este tipo
de contratos se caracterizan por tener tecnicismos y especificaciones tan propias de la materia
que muchas veces es difícil, en la práctica, detectar un incumplimiento contractual a menos
que sea muy grosero; y es justamente por esta falta de absolutos y de unificación de criterios
que entre las partes son habituales los intercambios de opiniones sobre imputación de
responsabilidades. Siguiendo la lógica del razonamiento anterior, es que el licenciante suele
formular declaraciones de garantía y cláusulas limitantes de responsabilidad, que velan por la
ecuación económica tenida en miras al otorgar la licencia, limitando las indemnizaciones por
casi todo concepto al monto/honorario establecido como contraprestación del licenciamiento
de uso.

A continuación redactaré algunas de las cláusulas mayormente utilizadas,  para limitar responsabilidad:

– En este acto la Empresa y sus licenciantes expresamente renuncian a todas las
garantías, condiciones y declaraciones no mencionadas, expresa o implícita, sin límite,
incluyendo cualquier garantía de obtención de un resultado o de aptitud del software para un
propósito particular. La empresa y sus licenciantes no garantizan ni declaran que el software
cumplirá, acatará o estará en conformidad con las leyes, reglamentos, requerimientos o
lineamientos de cualquier entidad gubernamental creadas y/o ha crearse. Tanto la Empresa
como sus licenciantes proporcionan su software “en el estado en que se encuentra” (“as is”).
La Empresa y sus licenciantes no serán responsables por ningún perjuicio incidental o
indirecto, resultante del uso incorrecto o de la inhabilidad para el uso del software por parte del
Cliente y/o persona autorizada por él. La Empresa y sus licenciantes tampoco serán
responsables por los hechos, actos u omisiones de terceros a los que eventualmente el cliente
encomendare la instalación u operación del software. La responsabilidad de la Empresa frente
al Cliente y a cualquier otro tercero con relación al cumplimiento o incumplimiento de sus
obligaciones, y con cualquier otro asunto relacionado con los servicios y con las licencias, sea
de fuente contractual, extracontractual o legal, no excederá, en su conjunto, los honorarios
efectivamente abonados por el Cliente a la Empresa en contraprestación por los servicios o
licencias objeto del reclamo. En ningún caso la Empresa será responsable por gastos,
pérdidas o daños indirectos o mediatos, lucro cesante, daño moral, pérdida de chance, ni
daños punitivos, entre otros. La limitación de responsabilidad de la Empresa establecida
precedentemente representa el acuerdo total de las partes en la materia y, en tal sentido, la
contraprestación de la Empresa contempla dicha limitación de responsabilidad. Las partes
convienen en que en caso de tener créditos por cobrar contra la otra, dirigirán sus acciones
sólo contra los activos de la parte deudora y en ningún caso accionarán en contra de los
accionistas, socios, directores o propietarios de la otra parte. Ni el Cliente, ni la Empresa o sus
Licenciantes serán responsables por daños indirectos, aunque hayan sido o no previstos y/o
informados. Los licenciantes de la Empresa no serán responsables por los daños directos y
renuncian a cualquier responsabilidad relacionada con el uso del software.
– La responsabilidad de la Empresa frente al Cliente y a cualquier tercero con relación al
cumplimiento o incumplimiento de sus obligaciones y con cualquier otro asunto relacionado
con los Servicios y con los Entregables, sea de fuente contractual, extracontractual o legal, no
excederá, en su conjunto, los honorarios efectivamente abonados por el Cliente a la Empresa
en contraprestación por los Servicios o Entregables objeto del reclamo. Sujeto al límite
establecido precedentemente, la Empresa sólo responderá de los perjuicios directos
previsibles que constituyan daño emergente. En ningún caso la Empresa será responsable por
gastos, pérdidas o daños indirectos o mediatos, lucro cesante, daño moral ni daños punitivos.
La Empresa no será responsable de los retrasos, incumplimientos o por cualquier otro hecho o
acto no imputable a la Empresa.

16/7/2019 Contratos de Software y Consultoría Profesional en la República Argentina | Todavía Somos Pocos
www.todaviasomospocos.com/aportes/contratos-de-software-y-consultoria-profesional-en-la-republica-argentina/ 10/24

MANEJO DE SOLICITUDES DE CLIENTES

Para decidir esto se reviso los estándares  ISO , ITIL , IEEE

La semántica es confusa , pero trate de generar un diccionario unificado y efectivo para el trabajo diario de atención al cliente 

Una solicitud De un CLIENTE  puede ser que ….:
★★CLASIFICAR SOLICITUD

      ★★PIDA UNA CORRECCIÓN de lo que experimenta como una FALLA

1.1)      Es un incidente

1.2)     Es un Problema

         ★★PIDA UNA MEJORA

2-1)  Es una adaptación        

              Funcional

              No funcional

2-2) Es un Perfeccionamiento

              Funcional

              No funcional  

        ★★INFORMA DE UNA DISCONFORMIDAD

                    Funcional

                    No funcional

      ★★PIDA UN SERVICIO

Cada Solicitud , deberá:

OREGISTRAR

OCLASIFICAR

OACEPTAR

ORESOLVER  

Una falla es:

La manifestación de un defecto (incidente/problema//disconformidad)

Un incidente es :

 un suceso no deseado , que se manifiesta con mensajes de error , detención del sistema , resultados inadecuados 

Un problema es: 

 un suceso no deseado difícil de identificar , no es la cima de un árbol de fallas  un suceso intermedio en el árbol de fallos, causa de varios sucesos no deseados posteriores
Una adaptacion es:
Un Perfeccionamiento es:

Una disconformidad es:

 Las disconformidades aparecen simplemente porque el comportamiento esperado del sistema no coincide con el comportamiento actual. Esto puede ser el resultado de un defecto del software, pero puede ser fácilmente el resultado de un desconocimiento de las capacidades del sistema, o de la utilización incorrecta del flujo de trabajo, o de una documentación pobre, o de cambios en las directrices de la empresa, o de otras tantas razones.

Son objetivos que no se alcanzan

Son objetivos que no están alcanzados satisfactoriamente

Son objetivos nuevos

Un Servicio es:

una solicitud de intervención 

Un grafico ayuda como 100 palabras

ESPECIFICACIONES UTILES

(porque inservibles tambien hay y solo generan entropia y confusion)

Las especificaciones deben tener un montón de características 

Una de las que me parece mas importante es : QUE SEA COMPROBABLE
Porque como ya hemos visto , la corrección de un soft debe ser verificado contra las especificaciones
Una especificación puede ser una reformulacion de un requisito que se ha elegido como una restricción , o una formulación de una característica funcional o no que se ha seleccionado
entonces.... son decisiones documentadas
El standard de la ieee dice algo al respecto
(un standard es una decisión tomada y que puede incorporarse como un requisito)

IEEE-STD-830-1998 : ESPECIFICACIONES DE LOS REQUISITOS DEL
SOFTWARE
2.3.6 Comprobable
Un SRS es comprobable si, y sólo si, cada requisito declarado es comprobable. Un
requisito es comprobable si, y sólo si, allí existe algún proceso rentable finito con que
una persona o la máquina puede verificar que el producto del software reúne el
requisito. En general cualquier requisito ambiguo no es comprobable.
Los requisitos de No-verificable incluyen las declaraciones como "trabaja bien",
"interface humana buena" y "normalmente pasará" no pueden verificarse los requisitos
de esos porque es imposible de definir las condiciones "bueno," "bien" o
"normalmente". La declaración que "el programa nunca entrará en una vuelta infinita"
es el no-verificable porque la comprobación de esta calidad es teóricamente imposible.
Un ejemplo de una declaración comprobable es:
El rendimiento del programa se producirá dentro de 20 seg de evento 60% del tiempo;
y se producirá dentro de 30 seg de evento 100% del tiempo.
Esta declaración puede verificarse porque usa condiciones concretas y las cantidades
mensurables.
Si un método no puede inventarse para determinar si el software reúne un requisito
particular, entonces ese requisito debe quitarse o debe revisarse.

Un soneto me manda hacer Violante
que en mi vida me he visto en tanto aprieto;
catorce versos dicen que es soneto;
burla burlando van los tres delante.

Yo pensé que no hallara consonante,
y estoy a la mitad de otro cuarteto;
mas si me veo en el primer terceto,
no hay cosa en los cuartetos que me espante.

Por el primer terceto voy entrando,
y parece que entré con pie derecho,
pues fin con este verso le voy dando.

Ya estoy en el segundo, y aun sospecho
que voy los trece versos acabando;
contad si son catorce, y está hecho.

Lope de Vega (1562-1635, en su comedia La niña de plata, 1617)

Ubiquemosnos
Un pedido me manda a hacer el cliente ....
es el aprieto de siempre! no nos asustamos!
Convertir el pedido en algo construible es el pequeño gran  paso.
Pequeño para el hombre pero enorme para el que tienen que hacerlo
Lope de Vega resolvio magistralmente el aprieto de Violante
Aveces los aprietos son elusivos , poco perceptibles
Quizas la inspiracion le sobraba al genial Lope de Vega. Nosotros no necesitamos ser geniales , solo encontrar alguna forma de identificar al ignoto.
Quizas llenar el dominio de cajitas conocidas (conceptos) ayudaran a localizar o hacer perceptible (descripcion formal).
Preguntarnos para que hacer algo? , como era la region antes? y despues de que intervengamos? con una solucion.
Desafortunadamente , solo contamos con nuestra mente o con una sociedad de mentes colaboradoras para imaginar la solucion perfecta e identificar el abismo que separa eso de algo que pueda ser hecho con los recursos que contamos

Un nuevo Tao para el software

cap.1 Si quieres algo que no existe , tendrás que hacerlo

Si quieres algo que no existe , tendrás que hacerlo
y si no hay nada parecido ,tendrás que investigar cual es el problema que hay que solucionar .

Cada uno elije sus batallas , las mías son los problemas de producción y la administración de sistemas de producción. Entonces el dominio esta bastante claro ... ahora que se requiere?
Investiga , descubre , reconoce , rodea lo desconocido de conceptos conocidos , haz perceptibles los diferentes requisitos!

En estas "batallas" debes salir airoso , debes poder formalizar los requisitos
Entonces estarás listo para un diseño

Conoce a fondo un lenguaje de computación para poder construir esa maquina de soft que te quita el sueño

deberás probar que hiciste algo que sirve. PERO ... debe servir para la solución que eljiste !
Luego llegara el alivio de que tu/s maquinas estén en los dedos de los usuarios , lista/s para funcionar
Grrr. ahora hay que conseguir que se use! , el usuario deberá instituirla como parte de su trabajo
y las maquinas que hiciste ... silenciosa,mente empezaran a llenar el mundo de sus esperados servicios.
Así haremos un mundo mejor

PERO ... el mundo cambia y eso hace que nuestras maquinas deban cambiar
Estarás de cabeza en el viejo garage del mantenimiento
Y finalmente , una vez muy muy lejos , tus maquinas sera sacadas de servicio.
El ciclo se habrá cumplido
Y nosotros estaremos felices de haber colaborado a mejorar la vida de los que se animaron a nuestras maquinitas de soft. Seguro aportamos un granito de arena a la evolucion.
OH y entonces .... que nos ayudara a que todo eso suceda de una forma controlada eficaz , efectiva y eficiente... ?
Dicho brutalmente (como o ya lo dijo antes un tango) : Es la INGENIERÍA  gilito embanderado ! (chan , chan!)

Por el final de los 80 me llamo la atencion  este ensayo sobre la programacion de computadoras y su vision desdeel TAO
Hoy diria que: cuando una rama del saber humano todavia no tienen ciencia , recurre a los mitos   y leyendas. Ademas como no hay ciencia para explicar lo que sucede ... proporcionan metaforas para transmitir lo que no se entiende.
En esos años miticos de la programacion , este articulo era COOL , hacia furor... con ironias todavia irreemplazables.

El Tao de la Programación
por Geoffrey James
LIBRO PRIMERO: EL VACÍO SILENCIOSO
Así habló el maestro programador:
“Cuando hayas aprendido a extraer el código del error desde un trap frame,
será la hora de marcharte”
1.1
Algo misterioso se forma, nace en el vacío silencioso. Esperando solo e inmóvil, al mismo tiempo detenido y en movimiento constante. Es la fuente de todos los programas. Yo no sé su nombre, así que lo llamaré el Tao de la Programación.

Si el Tao es grandioso, entonces el sistema operativo es grandioso. Si el sistema operativo es grandioso, entonces el compilador es grandioso. Si el compilador es grandioso, entonces la aplicación es grandiosa. El usuario está complacido y hay armonía en el mundo.

El Tao de la Programación fluye lejos y regresa con el viento de la mañana.
1.2
El Tao engendró al lenguaje máquina. El lenguaje máquina dio vida al ensamblador. El ensamblador se la dio al compilador. Ahora hay diez mil lenguajes.

Cada lenguaje tiene su propósito, aunque sea humilde. Cada lenguaje expresa el Yin y el Yang del software. Cada lenguaje tiene su lugar dentro del Tao.

Pero no programes en COBOL si puedes evitarlo.
1.3
En el principio era el Tao. El Tao engendró el Espacio y Tiempo. Por tanto Espacio y Tiempo son el Yin y el Yang de la programación.

Los programadores que no comprenden el Tao siempre siempre se quedan sin tiempo y espacio para sus programas. Los programadores que comprenden el Tao siempre tienen tiempo y espacio suficiente para lograr sus objetivos.

¿Cómo podría ser de otra manera?
1.4
Al programador sabio le hablan del Tao y lo sigue. Al programador medio le hablan del Tao y lo busca. El programador necio se ríe cuando le hablan del Tao.

Si no fuera por la risa, no existiría el Tao.
Los sonidos más altos son los más difíciles de oír.
Avanzar es un camino para la retirada.
El gran talento se muestra tarde en la vida.
Incluso un programa perfecto todavía tiene errores.
LIBRO SEGUNDO: LOS MAESTROS ANCIANOS
Así habló el maestro programador:
“Después de tres días sin programar, la vida pierde sentido”
2.1
Los programadores de la antigüedad eran misteriosos y profundos. No podemos comprender sus pensamientos, así que todo lo que hacemos es describir su apariencia.

Consciente, cual zorro cruzando el agua. Alerta, como un general en el campo de batalla. Amable, como una anfitriona saludando a sus invitados. Simple, como bloques de madera sin tallar. Opaco, como negras piscinas en cuevas oscuras.

¿Quién puede contar los secretos de sus corazones y mentes?

La respuesta sólo existe en el Tao.
2.2
El Gran Maestro Turing una vez soñó que era una máquina. Cuando se despertó, exclamó:

”¡No sé si soy Turing soñando que soy una máquina, o una máquina soñando que soy Turing!'”
2.3
Un programador de una gran compañía fue a una conferencia de software y luego regresó para informar a su jefe, diciendo: “¿Qué clase de programadores trabajan en otras empresas? Se comportan mal y no se preocupan por las apariencias. Su cabello era largo y despeinado y sus ropas arrugadas y viejas. Destrozaron nuestra hospitalidad e hicieron ruidos groseros durante mi presentación''.

El director dijo: “Nunca debí haberte enviado a la conferencia. Esos programadores viven más allá del mundo físico. Consideran que la vida es absurda, una coincidencia accidental. Ellos van y vienen sin conocer limitaciones. Sin cuidado, ellos viven sólo para sus programas. ¿Por qué deberían preocuparse por las convenciones sociales?

Ellos viven dentro del Tao”.
2.4
El discípulo preguntó al Maestro: “Este es un programador que nunca diseña, documenta o prueba sus programas. Sin embargo, todos los que lo conocen lo consideran uno de los mejores programadores del mundo. ¿Por qué es esto?”

El Maestro responde: “Ese programador ha alcanzado la maestría del Tao. Ha ido más allá de la necesidad de un diseño; no se enoja cuando el sistema se cae, pero acepta al universo sin preocupación. Ha ido más allá de la necesidad de documentación; no le importa si alguien más ve su código. Ha ido más allá de la necesidad de pruebas; cada uno de sus programas son perfectos en sí mismos, serenos y elegantes, su propósito es auto-evidente. Realmente, él ha penetrado en el misterio del Tao''.
LIBRO TERCERO: DISEÑO
Así habló el maestro programador:
“Cuando el programa está siendo testeado,
es demasiado tarde para hacer hacer cambios de diseño”
3.1
Hubo una vez un hombre que fue a una feria de informática. Cada día, al entrar le decía al guarda de la puerta: “soy un gran ladrón reconocido por mis hazañas de robo. Estás prevenido de que esta feria no escapará sin ser saqueada”.

Estas palabras incomodaron mucho al guardia, porque dentro había millones de dólares en equipamiento informático, así que observó cuidadosamente al hombre. sin embargo, el hombre simplemente vagaba de stand en stand, murmurando para sí.

Cuando el hombre se iba, el guardia se lo llevó aparte y buscó entre sus ropas, pero nada fue encontrado.

Al siguiente día de la feria, el hombre regresó y regañó al guardia diciendo: "Ayer escapé con un gran botín, pero hoy será todavía mejor". Así que el guardia lo observó incluso más de cerca, pero sin resultados.

En el último día de la feria, el guardia no pudo resistir más su curiosidad. "Señor Ladrón", dijo, "estoy tan confuso que no puedo vivir en paz. Por favor ilumíneme. ¿Qué es lo que está robando?"

El hombre sonrió. "Estoy robando ideas", dijo.
3.2
Había una vez un maestro programador que escribía programas no estructurados. Un programador novicio, buscando imitarlo, también comenzó a escribir programas no estructurados. Cuando el novicio le pidió al maestro que evaluara su progreso, el maestro lo criticó por escribir programas no estructurados, diciendo:

“Lo que es apropiado para el maestro no es apropiado para los principiantes. Debes entender el Tao antes de trascender la estructura”.
3.3
Hubo una vez un maestro programador en la corte del señor de Wu. El señor preguntó al programador: “¿qué es más fácil de diseñar, un paquete de contabilidad o un sistema operativo?”.

“Un sistema operativo”, respondió el programador.

El señor lanzó una exclamación de incredulidad. “Sin duda, un paquete de contabilidad es trivial al lado de la complejidad de un sistema operativo”, dijo.

“No es así”, dijo el programador, “cuando se diseña un paquete de contabilidad, el programador actúa  como mediador entre personas con distintas ideas: cómo debe operar, cómo deben aparecer sus informes, y cómo se deben cumplir las leyes de impuestos". Por el contrario, un sistema operativo no está limitado por las apariencias externas. En el diseño de un sistema operativo, el programador busca la armonía más simple entre máquina e ideas. Esta es la razón por la que el sistema operativo es más fácil de diseñar”.

El señor de Wu asintió y sonrió. “Eso está bien, pero, ¿qué es más fácil de depurar?”.

El programador no respondió.
3.4
Un gerente fue al maestro programador y le mostró el documento de requisitos para una nueva aplicación. El gerente preguntó al maestro: “¿Cuánto tiempo se tarda en diseñar este sistema si le asigno cinco programadores?”.

“Tomará un año”, dijo el maestro rápidamente.

“¡Pero necesitamos este sistema inmediatamente o incluso antes! ¿Cuánto se tarda si le asigno diez programadores?”.

El maestro programador frunció el ceño. “En este caso, se tardará dos años”.

“¿Y si le asigno cien programadores?”

El maestro programador se encogió de hombros. “Entonces el diseño no se completará jamás”, dijo.
LIBRO CUARTO: CODIFICACIÓN
Así habló el maestro programador:
“Un programa bien escrito es su propio cielo;
un programa mal escrito, su propio infierno”
4.1
Un programa debe ser ligero y ágil, sus subrutinas conectadas como las perlas de un collar. El espíritu e intencionalidad del programa debe mantenerse en todo momento. No debe ser ni mucho ni poco, ni bucles innecesarios ni variables sin utilidad, ni ausencia de estructura ni rigidez excesiva.

Un programa debe seguir la “Ley de la menor sorpresa”. ¿Qué es esta Ley? Simplemente que el programa debe responder siempre de la forma que menos sorprenda al usuario.

Un programa, no importa cuán complejo sea, debería actuar como una sola unidad. El programa debe ser dirigido por la lógica interna en lugar de por las apariencias externas.

Si el programa falla en estos requisitos, se llegará a un estado de desorden y confusión. La única manera de corregir esto es reescribiendo el programa.
4.2
Un discípulo preguntó al maestro: “Tengo un programa que a veces funciona y veces aborta. He seguido las reglas de la programación, y estoy totalmente desconcertado. ¿Cuál es la razón?”.

El maestro respondió: “Estás confuso porque no entiendes el Tao. Sólo un necio espera un comportamiento racional de sus semejantes humanos. ¿Por qué ibas a esperarlo de una máquina que los humanos han construido? Los ordenadores simulan determinismo; sólo el Tao es perfecto.
Las reglas de la programación son transitorias; sólo el Tao es eterno. Por tanto, debes contemplar el Tao antes de ser iluminado.”

“Pero, ¿cómo sabré que he sido iluminado?”, preguntó el discípulo.

“Tu programa funcionará correctamente”, respondió el maestro.
4.3
Un maestro estaba explicando la naturaleza del Tao a uno de sus discípulos. “El Tao está presente en todo el software, independientemente de su insignificancia”, dijo el maestro.

“¿Está el Tao en una calculadora de bolsillo?”, preguntó el novicio.

“Está”, fue la respuesta.

“¿Está el Tao en un videojuego?”, continuó el discípulo.

“Incluso en un videojuego”, dijo el maestro.

“¿Y está en el sistema operativo de un ordenador personal?”

El maestro tosió y cambió levemente de posición. “La lección ha acabado por hoy”, dijo.
4.4
El programador del Príncipe Wang estaba codificando software. Sus dedos bailaban sobre el teclado. El programa compiló sin errores y se ejecutó cual ligera brisa.

“¡Excelente!”, exclamó el Príncipe, “¡Tu técnica es infalible!”.

“¿Técnica?”, dijo el programador girándose desde su terminal, “¡Lo que yo sigo es el Tao más allá de toda técnica! Cuando empecé a programar, veía ante mí el problema completo como un todo.

Después de tres años ya no veía ese bloque: empecé a usar subrutinas. Pero ahora no veo nada. Mi ser existe en un vacío sin forma. Mis sentidos están ociosos. Mi espíritu, libre para trabajar sin un plan, sigue su propio instinto. En resumen, mi programa se escribe a sí mismo. Es cierto que a veces hay problemas complejos. Los veo acercarse, me detengo, observo en silencio. Entonces cambio una única línea de código y las dificultades se desvanecen como una voluta de humo. Compilo mi programa. Me quedo quieto y dejo que el gozo del trabajo llene mi ser. Cierro los ojos un momento, y entonces cierro mi sesión”.

El Príncipe Wang dijo “Ojalá todos mis programadores fueran tan sabios”.
LIBRO QUINTO: MANTENIMIENTO
Así habló el maestro programador:
“Incluso un programa de tres líneas algún día tendrá que se mantenido”
5.1
Una puerta bien usada no necesita aceite en sus bisagras.
Un río que fluye veloz no se estanca.
Ni el sonido ni los pensamientos pueden viajar a través del vacío.
El software se pudre si no se utiliza.
Son grandes misterios.
5.2
Un gerente preguntó a un programador que cuánto tiempo le llevaría terminar el programa en el que trabajaba. “Se acabará mañana”, respondió rápidamente el programador.

“Creo que no estás siendo realista”, dijo el gerente, “De verdad, ¿cuánto tiempo tardará?”.

El programador pensó un instante. “Tengo algunas características que me gustaría añadirle. Me llevará al menos dos semanas”, dijo finalmente.

“Incluso eso es demasiado esperar”, insistió el gerente, “me basta si simplemente me avisas cuando el programa esté completo”.

El programador asintió.

Varios años más tarde, el gerente se retiró. De camino hacia su almuerzo de jubilación descubrió al programador dormido sobre su terminal. Había estado programando toda la noche.
5.3
Un programador novicio fue una vez asignado a la codificación de un sencillo paquete financiero.

El novicio trabajó furiosamente muchos días, pero cuando su maestro revisó su programa descubrió que contenía un editor de pantallas, un conjunto de rutinas gráficas generales, y una interfaz de inteligencia artificial, pero ni la más mínima mención de nada financiero.

Cuando el maestro le preguntó acerca de ello, el novicio se indignó. “No seas tan impaciente”, dijo, “Incluiré los temas financieros al final”.
5.4
¿Acaso un buen agricultor descuidaría un cultivo que ha plantado?
¿Acaso descuidaría un buen profesor incluso al estudiante más humilde?
¿Acaso un buen padre permitiría que uno de sus hijos murieran de hambre?
¿Acaso un buen programador rechazaría mantener su propio código?
LIBRO SEXTO: GESTIÓN
Así habló el maestro programador:
“Sean los programadores muchos y gestores pocos;
todos ellos serán entonces productivos”
6.1
Cuando los gestores tienen reuniones infinitas, los programadores escriben juegos. Cuando los financieros hablan de beneficios cuatrimestrales, el presupuesto de desarrollo está a punto de ser recortado. Cuando los científicos hablan de cielo azul, las nubes están a punto de aparecer.

Ciertamente, esto no es el Tao de la Programación.

Cuando los gestores de comprometen, los juegos son ignorados. Cuando los financieros hacen planes a largo plazo, la armonía y el orden son restaurados. Cuando los científicos se centran en los problemas cercanos, los problemas estarán a punto de resolverse.

Ciertamente, esto es el Tao de la Programación.
6.2
¿Por qué los programadores son improductivos?
Porque pierden su tiempo en reuniones.

¿Por qué los programadores son rebeldes?
Porque la gestión interfiere mucho.

¿Por qué los programadores reniegan unos de otros?
Porque están quemados.

Después de haber trabajado para un mal gestor, ya no valoran sus empleos.
6.3
Un gerente estaba a punto de ser despedido, pero un programador que trabajaba para él inventó un nuevo programa que se hizo popular y se vendió bien. Como consecuencia, el gerente conservó su empleo.

El gerente intentó darle al programador una bonificación, pero éste se negó diciendo “yo escribí el programa porque pensé que era un concepto interesante, por lo que no espero ninguna recompensa”.

Al oír esto, el gerente comentó: “Este programador, a pesar de su baja autoestima, entiende bien los deberes de un empleado. ¡Vamos a promocionarlo hacia la posición de consultor de gestión!”.

Pero cuando se le dijo esto, el programador lo rechazó una vez más diciendo: “Vivo para la programación. Si fuera ascendido no haría más que desperdiciar el tiempo de todos. ¿Me puedo ir? Tengo un programa en el que trabajar”.
6.4
Un gerente se dirigió a sus programadores: “En cuanto a sus horas de trabajo, van a tener que venir desde las nueve de la mañana hasta las cinco de la tarde”. En ese momento todos se enfadaron y muchos de ellos renunciaron en el acto.

Así que el gerente dijo: “Bien, pues en ese caso podéis establecer vuestros propios horarios de trabajo, siempre que terminéis los proyectos a tiempo”. Los programadores, ahora satisfechos, comenzaron a llegar a mediodía y trabajar hasta altas horas de la madrugada.
LIBRO SÉPTIMO: CONOCIMIENTO CORPORATIVO
Así habló el maestro programador:
“Puedes mostrar un programa a un ejecutivo de la empresa,
pero no puedes hacerlo experto en informática”
7.1
Un discípulo preguntó al maestro: “En el Este hay una gran estructura con forma de árbol que los hombres llaman sede corporativa. Está excesivamente inflada con vicepresidentes y contables. Generan una gran cantidad de notas diciendo ‘ve aquí’ o ‘ve allá’ y nadie sabe lo que significa. Cada año se colocan nuevos nombres en las ramas, todo en vano. ¿Cómo puede existir una entidad tan innatural?”.

El maestro respondió: “Percibes esta inmensa estructura y te perturba que no tenga un propósito racional. ¿No puedes encontrar entretenimiento con sus giros sin fin? ¿No disfrutas de la facilidad de programar sin problemas refugiado bajo sus ramas? ¿Por qué te molesta su inutilidad?”.
7.2
En el Este hay un tiburón que es mayor que todos los otros peces. Se transforma en ave cuyas alas son como nubes llenando el cielo. Cuando es ave, se mueve por toda la tierra y trae un mensaje desde la sede corporativa. Este mensaje cae entre los programadores como una gaviota dejando su huella en la playa. Entonces el pájaro remonta el vuelo y, con el cielo azul a sus espaldas, vuelve a casa.

El programador novicio mira sorprendido el ave porque no lo entiende. El programador intermedio teme la llegada del ave porque teme su mensaje. El maestro programador continúa trabajando en su terminal, no sabe que el ave ha llegado y se ha marchado.
7.3
El Mago de la Torre de Marfil llevó su último invento para que lo examinara el maestro programador. El Mago acarreó una gran caja negra a la oficina del maestro, mientras éste esperaba en silencio.

“Esto es una estación de trabajo de propósito general integrada y distribuida”, comenzó el Mago, “diseñada ergonómicamente con un sistema operativo propietario, lenguajes de sexta generación y múltiples interfaces de usuario de tecnología punta. Construirlo costó a mis asistentes varios cientos de años/hombre . ¿No es sorprendente?”.

El maestro alzó sus cejas ligeramente. “Sin duda es increíble”, dijo.

“La sede corporativa ha ordenado”, continuó el Mago, “que todos usen esta estación de trabajo como plataforma para los nuevos programas. ¿Está de acuerdo con esto?” .

“Ciertamente”, respondió el maestro, “Lo transportaré al centro de datos inmediatamente”. Y el Mago retornó complacido a su torre.

Varios días después, un novicio vagaba por la oficina del maestro programador y le dijo: “No puedo encontrar el listado de mi nuevo programa. ¿Sabes dónde puede estar?”.

“Sí”, respondió el maestro, “los listados están apilados sobre la plataforma del centro de datos”.
7.4
El maestro programador se mueve de un programa a otro sin miedo. Ningún cambio en los gestores puede dañarle. No será despedido, ni siquiera aunque el proyecto en el que trabaja sea cancelado. ¿Por qué es esto?

El Tao está en él.
LIBRO OCTAVO: HARDWARE Y SOFTWARE
Así habló el maestro programador:
“Sin el viento, el pasto no se mueve. 
Sin software, el hardware es inútil”
8.1
Un discípulo preguntó al maestro: “Percibo que una compañía de ordenadores es mucho mayor que todas las demás. Se eleva por encima de su competencia como un gigante entre enanos. Cualquiera de sus divisiones podría abarcar todo el negocio. ¿Por qué es esto así?”.

El maestro respondió: “¿Por qué haces preguntas tan necias? Esa compañía es así de grande porque es grande. Si sólo fabricara hardware nadie lo compraría. Si sólo hiciera software, nadie lo usaría. Si sólo mantuviera sistemas, la gente los trataría como a sirvientes. Pero al combinar todas esas cosas, la gente piensa que son dioses. Al no buscar la confrontación conquista sin esfuerzo”.
8.2
Un maestro programador pasó un día junto a un novicio. El maestro notó la preocupación del novicio con un juego en un dispositivo portátil. “Disculpe”, dijo, “¿me permite examinarlo?”.

El novicio atendió y pasó el dispositivo al maestro. “Veo que el aparato afirma tener tres niveles de juego: fácil, intermedio y difícil”, dijo el maestro. “Pero aún cada dispositivo tiene otro nivel de juego, donde el apartado no busca conquistar al humano, ni ser conquistado por el humano”.

“Ruego, gran maestro”, imploró el novicio, “¿cómo hace uno para encontrar esa misteriosa configuración?”.

El maestro arrojó el dispositivo al suelo y lo aplastó bajo su pie. Y de pronto, el novicio fue iluminado.
8.3
Había una vez un programador que trabajaba con microordenadores. “Mira lo bien que estoy aquí”, dijo a un programador de mainframes que lo fue a visitar. “Tengo mi propio sistema operativo y dispositivo de almacenamiento de archivos. No tengo que compartir mis recursos con nadie. El software es consistente y fácil de usar. ¿Por qué no dejas tu trabajo actual y te vienes conmigo?”

Entonces, el programador de mainframes comenzó a describir su sistema a su amigo, diciendo: “El mainframe está sentado como un antiguo sabio meditando en el centro de datos. Sus discos se encuentran de extremo a extremo como un gran océano de maquinaria. El software es tan polifacético como un diamante, y enrevesado como una selva virgen. Los programas, cada uno único, se mueven a través del sistema como un río de corriente rápida. Por eso estoy feliz donde estoy”.

El programador de microordenadores, al oír esto, se quedó en silencio. Pero los dos programadores siguieron siendo amigos hasta el final de sus días.
8.4
Hardware y Software se encontraron en el camino hacia Changtse. Software dijo: “Tú eres Yin y yo soy Yang. Si viajamos juntos nos haremos famosos y ganaremos vastas sumas de dinero”. Y así, el equipo se unió, pensando que conquistarían el mundo.

Actualmente se encontraron con Firmware, que estaba vestido con harapos y cojeaba apoyado en un palo espinoso. Firmware les dijo: “El Tao está más allá del Yin y Yang. Es silencioso y quieto como un estanque de agua. No busca la fama, por tanto, nadie sabe de su presencia. No busca fortuna, porque es completo en sí mismo. Existe más allá del espacio y del tiempo”.

Software y hardware, avergonzados, regresaron a sus hogares.
LIBRO NOVENO: EPÍLOGO
Así habló el maestro programador:
“Es hora de que partas”