De qué va todo esto (propuesta de traducción)

[José Manuel Beas]

¿Alguien se anima a traducir el último artículo de UncleBob?

http://cleancoder.posterous.com/software-craftsmanship-things-wars-commandmen

Bueno, o a discutirlo en esta lista. También sería interesante. (Eso
sí, obligatorio leerlo antes, claro) :-)

Un saludo,
Jose Manuel Beas

http://agilismo.es
http://jmbeas.iexpertos.com
http://twitter.com/jmbeas

[Abel Muiño Vizcaino]

Yo no soy muy partidario del Craftmanship… no porque sea mala idea, si no porque debería estar incluido "de serie". Hacer algo especial es como aceptar que nunca te preocupó el código y ahora tienes que aprender a marchas forzadas.

En realidad, creo que todo el mundo con un mínimo interés en su trabajo (cualquiera que lea blogs de tecnología, esté suscrito a esta lista, etc…) está entre esos "craftmans". Da igual que la moda ahora sea TDD o las Katas… son gente con interés que, casi seguro, estarán por encima de la media del mercado laboral.

Sobre el artículo en si, voy a manipularlo ligeramente ;-)

* We are tired of writing crap
* We will delight our customers by writing the best code we can.

Francamente, si escribes mal código, cuando escribas el mejor código que sepas, seguirá siendo malo. Es un objetivo bastante bajo (todo el mundo puede trabajar "como mejor sabe"… lo importante es cuanto sabe). Bueno, y está el tema de si a tu cliente le "deleita" que escribas ese código ¿vuestros clientes _miran_ vuestro código?

También está el milagro de las fechas de entrega y la velocidad de desarrollo. Por ser un artesano, mágicamente cumples los deadlines.
* We will meet our schedules by knowing that the only way to go fast is to go well.

Ignorando totalmente los temas de gestión, comunicación y otros soft skills imprescindibles para que un proyecto vaya bien (así que, sí que pone el código en el centro de todo, aunque lo niegue).

Por último me parece muy interesante como el 2º comentario rebate su simil con músicos y otros profesiones que practican fuera del escenario. Nosotros no tenemos escenario… o peor, estamos en él, al menos, 8 horas al día.

Todo esto me lleva al autobombo y mi antiguo post [1]: aprende a costa de tus clientes (o, en polite, aprende cada día, pero hazlo con problemas reales y no con problemas de juguete).

[1] http://blog.abelmuino.com/2010/09/aprende-a-costa-del-cliente.html

(y espero haber generado suficiente controversia para que surjan réplicas interesantes! :-) )

> --
> Has recibido este mensaje porque estás suscrito al grupo "agile-spain" de Grupos de Google.
> Para publicar una entrada en este grupo, envía un correo electrónico a agile...@googlegroups.com.
> Para anular tu suscripción a este grupo, envía un correo electrónico a agile-spain...@googlegroups.com
> Para tener acceso a más opciones, visita el grupo en http://groups.google.com/group/agile-spain?hl=es.
>

--
Abel Muiño
http://abelmuino.es

[Martin Perez]

Creo que con ese "we are not offering cheap certifications el amigo UncleBob" se podría llevar el título a maestro de la "retranca" gallega. 

Estoy con Abel con lo de que muchas de esas cosas tendrían que venir de serie. De hecho ¿ no son algunas de esas cosas las que muchos colegios claman que no se cumplen debido al intrusismo (chorradas) ? De todos modos es que el mensaje dentro de lo "bonito" es en mi opinión treméndamente utópico por dirigirse al mundo mundial en general.

Asimismo también creo que el texto contiene algunos mensajes (no todos) que todos los "lead developer", "senior architect", "team lead", "jefes de equipo", "jefes de desarrollo", "desarrolladores senior" o cualquier otra persona con una mínima responsabilidad técnica, debería tatuarse en el pecho. Especialmente porque estos mensajes requieren la capacidad para saber decir "no" o "hasta aquí hemos llegado", y esa responsabilidad no se debe mover al equipo de desarrollo, en gran parte porque la mayoría muchos están todavía en proceso de aprendizaje. 

Creo que se comentaba en uno de esos posts que se mencionan con bastante acierto. ¿De qué sirve firmar un manifiesto si no sabes escribir buen código? Puedes prometer y prometes, pero en el día a día resulta que escribes crap de cualquier modo, seguramente porque no has tenido a los tutores adecuados. O lo que a veces es peor, puedes estar escribiendo código fantástico que resulta que cuando pasa al mundo real es absoluta basura porque te has pasado por el forro todo el análisis no funcional de lo que querías hacer. 

Saludos,

Martín

2011/1/18 Abel Muiño Vizcaino <amu...@gmail.com>

--
Martín Pérez

Founder,
http://www.jobsket.com

[Jesús Jiménez]

Abel, siempre andas picando!!! Eso es bueno ;)

Creo que el problema es el de siempre, ponerle nombre a todo. Tenemos una manía especial a que todo lo que hacemos tiene que tener un nombre, el cual por cierto va cambiando cada X tiempo... Ahora es craftsmanship. A mi me gusta el movimiento, más allá del nombre que tenga, pero como me gusta lo que dicen y lo que hacen, pues me uno a ellos y trato de ser un buen artesano o aprendiz de artesano o como se quiera llamar, el caso es que busco la mejora contínua.

El problema viene en lo que dices de "debería estar incluido de serie". No lo está, y por eso surgen estos movimientos. Si todos fuéramos profesionales, no harían falta más nombres de nada, seríamos todos profesionales (cada uno a su nivel por la experiencia/conocimientos que tenga) y viviríamos en el mundo de la piruleta.

No creo que a día de hoy se pueda practicar en el trabajo una mejora contínua, o al menos no la gran mayoría de las empresas por las que yo he pasado. Si yo no practicara y me preocupara por mejorar en casa, no habría pasado de ser un desarrollador más o menos decente con los 2 o 3 frameworks que estén de moda en las empresas. Cuando tú te metiste a desarrollar en RoR, ¿lo hiciste desde la empresa? La mayoría de casos que conozco no ha sido así, ya que Ruby no es un lenguaje muy extendido a día de hoy en la empresa española (o al menos en el mundo de las consultoras grandes que es el que más conozco y el que da trabajo a gran parte de los desarrolladores aquí en España). Si no pudiste trabajar con ello desde 0 en tu empresa, es que practicaste en casa, ¿no?

No voy a hacer la comparación del desarrollador y el médico a la hora de trabajar practicando con el cliente, porque me parece muy exagerada, pero si por ejemplo a mi me diera por practicar el TDD directamente sobre el código del cliente, seguramente lo que me saldría sería una basura además de tardar días en hacer un hola mundo. Por eso me parece importante practicar en casa (y cuando digo casa, me refiero fuera del trabajo, ya sean eventos o desarrollos en casa).

Quizás a día de hoy se esté centrando por parte del movimiento craftsmanship todo en el código, pero es que ha sido ese gran olvidado y supongo que se quiere ir a un extremo para al menos quedarse en mitad del camino. Es decir, tiro más fuerte hacia mi lado para conseguir atraer un poco hacia mi lado.

Un saludo.

[José Manuel Beas]

Lo siento Abel, no estoy de acuerdo con que debamos aceptar tu
afirmación "Nosotros no tenemos escenario… o peor, estamos en él, al
menos, 8 horas al día." como cierta e inexorable: yo quiero dejar de
trabajar así. No me parece ético hacer que mis clientes paguen para
que yo aprenda a usar el framework tal o la herramienta pascual. No me
parece bien que yo no pueda dar estimaciones fiables de mi trabajo
simplemente porque no tengo el conocimiento o la preparación necesaria
para ello. Claro, el "mundo real", se me olvidaba... pero me resisto a
que el dichoso "mundo real" sea la única realidad posible. Sé que no
lo es y quiero que tampoco sea la mía.

Respecto a tu "manipulación" del texto. Efectivamente, has manipulado
a tu interés. (No entiendo bien por qué) Pero UncleBob lo dice bien
claro cuando dice:
We are not putting code at the center of everything.
We are not turning inward and ignoring the business and the customer.
nada más empezar.

¿Dónde se lee en el texto "Ignorando totalmente los temas de gestión,

comunicación y otros soft skills imprescindibles para que un proyecto

vaya bien"? No sé, no sé... yo no consigo leerlo. ;-)

Respecto a lo de que "debería venir de serie". ¡POR SUPUESTO! En eso
estamos, ¿no?

Y, por cierto, estoy con lo de que las etiquetas es lo de menos. A mi
también me la refanfinfla bastante el término a usar. Quizás el
término más acertado sea el más obvio: profesional.

Por cierto, gracias Jesús, has resumido mis pensamientos
perfectamente. Creo que hemos coincidido ya en demasiados sitios. :-)

[Rafa de Castro]

Habemus discusión. :D :D

Yo no veo donde se menosprecian las soft skills. De hecho me acabais de asombrar porque parece que de vuestras frases que se puede escribir buen código sin haber hecho unas buenas especificaciones (por ejemplo ;) ). Creo que parte de que un código sea bueno es que haga lo que se supone que debe de hacer. Parece bastante obvio. Creo que lo que él llama buen código lleva implícitas muchas cosas más que el TDD ;) 

Vale que las katas, los coding dojos y esas cosas se saltan ciertas partes del proceso pero es que son para practicar otras áreas. ¿Que no hay "katas" para practicar una buena comunicación con el el cliente? Cierto, pero es que probablemente a nadie se le ha ocurrido cómo hacerlo de manera medianamente amena :D También debería de haber katas de promocionar un producto o de cómo hacer que los egos de 15 desarrolladores no choquen. El día que a alguien se le ocurra una manera de hacerlas tendrá cientos de seguidores. De momento solo tenemos FizzBuzz :D

Y otra de arena: a mi me parece bien que los clientes paguen porque Fulanito aprenda a hacer la cosa X o Y si ellos estiman que el coste que conlleva es adecuado y que el resultado es el que esperan. A mi me da igual si pago por un proyecto un precio que considero justo que a quien se lo haya vendido adquiera conocimiento por el camino siempre que me entregue lo que he pedido. ;) Sin engaños de por medio no veo ningún problema ;) Aprender es un trabajo también. ¿Por que no va a estar remunerado? Miradlo desde este punto. Vosotros sois vuestra propia empresa y el lugar para el que trabajáis es vuestro cliente. Vuestro cliente necesita Y Horas de alguien que sepa "MegaFramework 2.0". Vosotros asignáis X horas de las 160 horas mensuales que le vendeis al mes para aprender "MegaFramework 2.0" e Y horas para trabajar en el cliente de vuestro cliente. No se, yo lo veo como una transacción de lo más normal. No me vengáis con las "ventas de expertos de palo" porque eso es mentir y eso es otra cosa. 

A mi me llama la atención cómo parece que esto es un movimiento de "code monkeys" que salen del armario. Que el sr A sea físicamente el que apriete las teclas no quiere decir que sea el responsable único de lo que se escribe ahí. El código es de todos. Desde el que se comunica con el cliente hasta el que instala las máquinas de desarrollo. Todos aportan su granito de arena y todos tienen que sentir el producto/proyecto como suyo. Cada uno debe de hacer lo mejor en su parte. Supongo que ahí está la razón subyacente de todo esto. A todos les tiene que doler como parte de su culpa el que haya un bug en el código (que se refleja en una expectativa no cumplida). Es que parece que un manager de personas no pueda tratar su trabajo como un artesano. El producto final normalmente el un binario generado con un código o incluso el mismo código. Por eso a lo mejor el término utilizado es ese. 

Y yo tampoco creo que esto venga de serie. Ni de coña :D Pero en ninguna profesión. Ni los desarrolladores ni los camareros. 

2011/1/18 Jesús Jiménez <jjba...@gmail.com>

--
Rafa de Castro
raf...@micubiculo.com

[Enrique Comba Riepenhausen]

Buenas noches Abel,

voy a ir contestando caso por caso lo que expones.

Abel Muiño Vizcaino wrote:

> Yo no soy muy partidario del Craftmanship… no porque sea mala idea, si no porque debería estar incluido "de serie". Hacer algo especial es como aceptar que nunca te preocupó el código y ahora tienes que aprender a marchas forzadas.

En un mundo ideal, todo el que trabaja haciendo software llevaría la profesionalidad "de serie". En los últimos 16 años no he trabajado con mucha gente que realmente considere profesionales en lo que hacen (ya sean programadores, jefes de proyecto, comerciales, etc.). La triste realidad (y esto se puede aplicar a todas las profesiones) es que la mayoría de la gente decide trabajara para poder pagarse su piso y su estilo de vida (que suele ser bastante diferente de sus vidas profesionales).

Cuando tienes la suerte de dar con un profesional que realmente le apasiona lo que hace es cuando realmente ves lo diferente que puede ser la experiencia. Ejemplos: cuando era un chaval y iba al colegio (cosa que me aburría bastante) había un profesor que realmente hacia que disfrutara de cada instante de sus clases, se notaba que realmente le apasionaba enseñar. En un caso mas reciente, el medico de paliativos, que visito a mi difunta madre después de su operación, fue como una bendición. El poder que tenia de transmitir preocupación y la forma en la que hablaba y entendía los miedos de mi madre fueron una de las mejores experiencias de profesionalidad fuera de mi profesión que haya vivido jamás.

La realidad: profesionalidad y pasión por el trabajo no vienen de serie.

> En realidad, creo que todo el mundo con un mínimo interés en su trabajo (cualquiera que lea blogs de tecnología, esté suscrito a esta lista, etc…) está entre esos "craftmans". Da igual que la moda ahora sea TDD o las Katas… son gente con interés que, casi seguro, estarán por encima de la media del mercado laboral.

No creo que un mínimo sea suficiente.

> Sobre el artículo en si, voy a manipularlo ligeramente ;-)
>
> * We are tired of writing crap
> * We will delight our customers by writing the best code we can.
>
> Francamente, si escribes mal código, cuando escribas el mejor código que sepas, seguirá siendo malo. Es un objetivo bastante bajo (todo el mundo puede trabajar "como mejor sabe"… lo importante es cuanto sabe). Bueno, y está el tema de si a tu cliente le "deleita" que escribas ese código ¿vuestros clientes _miran_ vuestro código?

Es cierto que si no sabes programar el que programes lo mejor que puedas no puede dar buen resultado.

Una de las razones por las que practicamos todos los días fuera del trabajo para poder mejorar y saber ayudar a nuestros clientes con buen criterio. Razón por la que buscamos a otros profesionales con ideas semejantes para que nos enseñen sus formas de resolver problemas y sus técnicas. Razón por la que viajamos a otras empresas para programar con ellos durante unos días y aprender como afrontan ellos los retos del día a día.

Para contestar a tu pregunta. Si, alunos de nuestros clientes miran nuestro código.

> También está el milagro de las fechas de entrega y la velocidad de desarrollo. Por ser un artesano, mágicamente cumples los deadlines.
> * We will meet our schedules by knowing that the only way to go fast is to go well.

No es un acto de magia ni nada semejante. Si soy un profesional y entiendo mi oficio, puedo realmente dar estimaciones que se asemejen bastante mas a la realidad que cualquier otra persona, es lo que da la experiencia. Yo cuando doy una fecha la cumplo. ¿Porque? Por profesionalidad, honor. ¿Como? Basandome en mi experiencia y haber programado cosas semejantes en el pasado.

> Ignorando totalmente los temas de gestión, comunicación y otros soft skills imprescindibles para que un proyecto vaya bien (así que, sí que pone el código en el centro de todo, aunque lo niegue).

¡Nada mas lejos de la realidad! Un artesano usa los *soft skills* todo el rato. A nosotros (aquí estoy hablando de nuestro taller) no nos hace falta un gestor, jefe de proyecto, etc ya que somos nosotros los que hacemos estas tareas.

Un artesano debería saber como escribir código en diferentes lenguajes (al fin y al cabo estamos en esta profesión), hablar con clientes, estimar el trabajo, vender un proyecto con honestidad, incluso abrir su propia empresa. Obviamente nadie sabe hacer eso de cero, todo requiere aprendizaje y dedicación.

Como nuestro trabajo central se basa en escribir código, eso es lo primero que debemos aprender y aprender bien.

> Por último me parece muy interesante como el 2º comentario rebate su simil con músicos y otros profesiones que practican fuera del escenario. Nosotros no tenemos escenario… o peor, estamos en él, al menos, 8 horas al día.

Nuestro escenario es nuestro sitio de trabajo, en el intentamos colaborar con nuestros clientes, entender su problema y darles la mejor solución (la mayoría de las veces teniendo que basar nuestra solución en problemas vistos anteriormente en otros proyectos y en nuestra practica).

Si no tratas tu dia laboral como tu escenario nunca darás lo mejor de ti (cuando estoy practicando puedo cometer errores, frustrarme, ir a la cocina a por otro cafe, darme un paseo para aclarar mi cabeza).

En el caso de las 8 horas laborales... Dudo mucho que te puedas concentrar durante un periodo de 8 horas seguidas (yo no puedo). Si trabajas realmente concentrado, totalmente enfocado en el problema en cuestión (ya sea escribiendo código o hablando con tu cliente definiendo la puesta en producción o haciendo un release plan) después de 6 a lo máximo 7 horas estas rendido y lo que vas a poder producir será de peor calidad (a mi me gusta ofrecer la mejor calidad posible a mis clientes).

> Todo esto me lleva al autobombo y mi antiguo post [1]: aprende a costa de tus clientes (o, en polite, aprende cada día, pero hazlo con problemas reales y no con problemas de juguete).

Aprender a costa de mis clientes me parecería una estafa. De hecho me he encontrado con situaciones en las que no tenia una solución técnica a un problema (en el ultimo caso tarde 2 días en encontrar una solución) y naturalmente no cobre a mi cliente por esos días ya que no me parecía justo.

> (y espero haber generado suficiente controversia para que surjan réplicas interesantes! :-) )

No se si has generado controversia o no, pero espero que la respuesta sea al menos interesante...

Enrique Comba Riepenhausen

[Alfredo Casado]

No entiendo muy bien cual es el razonamiento para llegar desde: "me interesa mejorar como escribo al código" hasta: "sólo me importa el código y el resto me da igual".

Es necesario un movimiento donde alguien diga de una vez que para hacer buen software hay que escribir buen código. Que sin buen código da igual todas las soft skills que tengas que lo más probable es que la cosa fracase, o como poco, no sea la mitad de bueno de lo que podría ser.

Además de esto, de la poca gente que conozco que de verdad se pueden considerar "craftmanship" lo más que me sorprende no es la calidad de su código (que tampoco lo he visto) es la relación que dicen tener con sus clientes y la forma de encararla. Precisamente donde yo creo que más se diferencian del resto en la preocupación por tener clientes verdaderamente satisfechos con su trabajo y por establecer mecanismos de comunicación con el cliente mucho más cercanos que un documento de requisitos. Yo no he visto esa preocupación por los clientes ni por entender sus problemas en ningún sitio, lo que veo siempre es que lo que único que preocupa es cobrar haciendo lo menos posible, coger un documento de requisitos, guardarlo a buen recaudo, y utilizarlo como arma arrojadiza contra el cliente a la primera de cambio, y por supuesto luego cobrar una pasta por "mantenimiento" de un software que en realidad nunca llego a funcionar.

No existe esa dualidad "o el código o la gestión", la realidad es que donde hay buena gestión suele haber buenos profesionales y buen código, y donde hay mala gestión suele haber becarios escribiendo crap a toneladas.

[Jose Diaz]

Bueno mis cinco centavos alrededor de este tema.

En Perú nosotros somos una consultora con tres años de fundada y muchas de las cosas que dice el articulo que no se deben hacer las hemos hecho. Bueno para ser cinturón negro hay que pasar por el blanco y a veces que se te "caiga el pantalón".

Nos ha costado hacer buen código,  satisfacer al cliente en todos los sentidos (software, planes, reuniones, atención, delivery, etc)  o, decir "NO", no se hacerlo, o no estoy aun en condiciones.  Pues siempre nos arrastra el decir que todo sabemos hacer con tal de vender, con tal de pagar las cuentas y decir tengo proyectos, mira que tal entrada. Pero luego se vienen los problemas.

Al final hemos perdido muchos clientes y dinero por seguir la costumbre de muchas consultoras y la falta de información de otras alternativas a desarrollar software. Pues la gestión y el código , o lo que diría la táctica  y la técnica andaban divorciados, no se encontraban.

No quiero volver a leer o discutir el manifiesto ágil o el de  Craftsmanship. Pero, quiero asegurarles que si no hubiese llegado a nuestro equipo los aportes de comunidades, personas interesadas en estos temas, en querer hacer mejor software, mejorar nuestros skills y tener clientes fieles, es decir, en aportar esa diferencia respecto a otras consultoras, hoy estaríamos cada uno de nuestro equipo en diferentes trabajos, mandándonos mails y lamentándonos nuestra suerte.
Sabíamos que teníamos el equipo para grandes cosas, pero, no teníamos un orden, técnica y táctica para enfrentar los retos.

Así que en mi humilde experiencia estamos aportando cada uno para hacer buen código, y mejorar la gestión. Nos viene resultando, tenemos clientes que incluso ya no buscan otros proveedores. Salvo, le digamos que no hemos tenido experiencia en el tema nuevo y que sugerimos busque alguien que lo haya hecho antes y nosotros poder apoyar en lo que podamos.

Cuando empecé hace un año a hablar de TDD, Continuous Integration, SCRUM a mi equipo, muchos dijeron "agggg" , ni caso me hicieron. Cuando empezaron las capacitaciones y miraron el grado de madurez de los que si lo usaban, si sintieron raros y renunciaron por si solos. No tuve que despedirlos. Yo mismo me he contagiado de todo esto y ando practicando mis katas solo o compartiendo "figuritas" de álbum de cuando eramos niños con otros chicos porque no hay katas o katayunos como veo en su país aquí. Sino tenemos la "hora del lonchecito" donde compartimos algo de katas entre nosotros del team.

En resumen el código y la gestión deben ir bien alineados. Sin técnica y sin táctica no se puede tener éxito en mi humilde opinión. Y la técnica la ganas practicando y practicando.

Aun de las derrotas se aprende muchísimo. Pero no siempre tenemos segundas oportunidades, así que a cuidarse.

Saludos

Joe

2011/1/17 Alfredo Casado <casado....@gmail.com>

[Abel Muiño Vizcaino]

El 17/01/2011, a las 15:41, Jesús Jiménez escribió:

Abel, siempre andas picando!!! Eso es bueno ;)

Es que si no, nos volvemos autocomplacientes :-)

No voy a contestar a todo, que hay mucha gente dándome caña (¡y me mola!)… Además entramos en situaciones personales y no en la discusión del artículo.

Brevemente:

No creo que a día de hoy se pueda practicar en el trabajo una mejora contínua, o al menos no la gran mayoría de las empresas por las que yo he pasado.

Siempre digo lo mismo en estos casos… cambia de empresa o crea la tuya. Y al que me diga que esto es más difícil que cambiar el mundo a base de manifestos, no le contesto :-)

Cuando tú te metiste a desarrollar en RoR, ¿lo hiciste desde la empresa?

Pues la verdad es que sí y después seguí con http://thecloudmarket.com, dónde uno de los clientes era yo. Otro problema real. 

Y la experiencia de todo eso me permite cobrar por desarrollar en RoR y dejar a los clientes contentos. ¿Alguien puede defender que hacer la kata de los números romanos te permitirá hacer los mismo?

Recuerda, no estoy en contra de aprender… No tengo nada en contra de quien quiera hacer katas, pero no comparto que el juego de la vida o las ruby koans supere en apredizaje a los problemas reales. Y si tienes problemas reales, ¿porqué conformarse con un sustituto?

si por ejemplo a mi me diera por practicar el TDD directamente sobre el código del cliente, seguramente lo que me saldría sería una basura además de tardar días en hacer un hola mundo.

Por eso haces baby steps y no cambios revolucionarios. Recuerda que te pagan para resolver problemas. Pero no te dicen cómo. Asume riesgos y sus consecuencias.

--

Abel Muiño

http://abelmuino.es

[Abel Muiño Vizcaino]

Idem, muy breve (después de todo, estoy en USA y esto mola mogollón :-) )…

El 17/01/2011, a las 15:47, José Manuel Beas escribió:

> Lo siento Abel, no estoy de acuerdo con que debamos aceptar tu
> afirmación "Nosotros no tenemos escenario… o peor, estamos en él, al
> menos, 8 horas al día." como cierta e inexorable: yo quiero dejar de
> trabajar así.

No entiendo a qué te refieres con "así". ¿Menos de 8 horas? Se puede, yo lo hago :-)

Por poner lo de las 8 horas en contexto. El argumento de Uncle Bob es que como los músicos practican, también debemos practicar nosotros.
Pero un músico solo "trabaja" (actúa) unas pocas horas por semana, nosotros muchas más. Como todas las comparaciones que se hacen entre la profesión X y la nuestra, es muy imperfecta… los paralelismos están bien para "ilustrar", pero no se sostienen como argumento del que derivar conclusiones.

> No me parece ético hacer que mis clientes paguen para
> que yo aprenda a usar el framework tal o la herramienta pascual. No me
> parece bien que yo no pueda dar estimaciones fiables de mi trabajo
> simplemente porque no tengo el conocimiento o la preparación necesaria
> para ello. Claro, el "mundo real", se me olvidaba... pero me resisto a
> que el dichoso "mundo real" sea la única realidad posible. Sé que no
> lo es y quiero que tampoco sea la mía.

Ólvidate del mundo real, no lo he mencionado.
Tus clientes te pagan por resolver un problema. Con que framework lo hagas es (normalmente) tu problema.

Y las estimaciones… en fin… hay montones de managers muy buenos en la lista que te pueden hablar de su exactitud. Yo sólo diré que (en mi experiencia) los conocimientos técnicos no son el único parámetro ni el más importante.

> Respecto a tu "manipulación" del texto. Efectivamente, has manipulado
> a tu interés. (No entiendo bien por qué) Pero UncleBob lo dice bien
> claro cuando dice:
> We are not putting code at the center of everything.
> We are not turning inward and ignoring the business and the customer.
> nada más empezar.

Y yo he discutido eso, en lugar de aceptar la palabra de Uncle Bob como verdad absoluta, manipulando el texto para argumentarlo. Pero es mi interpretación y acepto que puede no ser "la correcta".

> ¿Dónde se lee en el texto "Ignorando totalmente los temas de gestión,
> comunicación y otros soft skills imprescindibles para que un proyecto
> vaya bien"? No sé, no sé... yo no consigo leerlo. ;-)

Está en el espacio negativo que dejan los "We will". No hay ningún "We will have a healthy relationship with our customers" o cualquier otro tema de gestión.

Así que mi razonamiento es que Uncle Bob realmente sostiene que "we will meet our deadlines" simplemente con conocimientos técnicos.

[Abel Muiño Vizcaino]

Hola Enrique,

Como siempre, es un placer leerte… lamentablemente yo no tengo el tiempo para contestar punto por punto y con tanto detalle (espero que nadie lo considere una falta de respeto).

Estoy de acuerdo contigo en que no todo el mundo es un gran profesional. Pero todos esos malos profesionales sin pasión por su trabajo jamás se interesarán en el craftmanship… Y los que sí se interesan son profesionales y apasionados por su profesión.
Así que el Craftmanship predica a conversos. Y en ese contexto casi nada de lo que dice Uncle Bob tiene sentido.

Alejándonos del artículo en si…

Entiendo que no te guste cobrar a tus clientes por tu aprendizaje. Ya hemos cruzado emails sobre esto… mi opinión es que en todos los proyectos necesitas aprender. En caso contrario tu trabajo sería automatizable y sobrarías.
En resumen, siempre cobras por aprender a costa de tus clientes.
El debate real es… ¿hasta que punto es "aceptable" aprender durante el proyecto? Cada uno traza su línea. Tu comentas el caso en el que no cobraste por el tiempo que dedicaste a investigar. Yo he tenido clientes que me han pedido explícitamente que les cobre ese tiempo.

Sobre el tema de estimaciones y soft-skills… yo hablo desde la interpretación del artículo, no desde un caso particular. Estoy más que seguro que en tu caso vas más allá de esa lista que hace Uncle Bob… aunque sólo sea por lo que cuenta la gente.

[Jesús Jiménez]

No creo que a día de hoy se pueda practicar en el trabajo una mejora contínua, o al menos no la gran mayoría de las empresas por las que yo he pasado.

Siempre digo lo mismo en estos casos… cambia de empresa o crea la tuya. Y al que me diga que esto es más difícil que cambiar el mundo a base de manifestos, no le contesto :-)

En mi empresa tampoco podría practicar todo lo que me gustaría. No creo que quedara muy bien que me pusiera a probar lenguajes y frameworks con aplicaciones para cliente... unas veces me saldría bien y perfecto, otras veces sería un fracaso y cliente perdido. Al igual que técnicas como TDD sigo sin estar de acuerdo en que pueda probarlas directamente en el trabajo

 

Cuando tú te metiste a desarrollar en RoR, ¿lo hiciste desde la empresa?

Pues la verdad es que sí y después seguí con http://thecloudmarket.com, dónde uno de los clientes era yo. Otro problema real. 

Me alegro, de verdad, pero sabes que no es el caso mayoritario. Una gran parte de los desarrollos a día de hoy son sota, caballo y rey. Y tú mismo me dijiste hace un tiempo que las empresas que conocías que buscaban desarrolladores de RoR los querían con experiencia. Y te pongo el caso de RoR porque se que estás metido con ello, pero te diría lo mismo de cualquier otro lenguaje/framework/técnica/metodología/etc. Si eres early adopter, vas a ir por delante de "la industria", como es normal, por lo que necesitas practicar antes de ponerte a ello.

 

Y la experiencia de todo eso me permite cobrar por desarrollar en RoR y dejar a los clientes contentos. ¿Alguien puede defender que hacer la kata de los números romanos te permitirá hacer los mismo?

Recuerda, no estoy en contra de aprender… No tengo nada en contra de quien quiera hacer katas, pero no comparto que el juego de la vida o las ruby koans supere en apredizaje a los problemas reales. Y si tienes problemas reales, ¿porqué conformarse con un sustituto?

 

Son diferentes objetivos. Las katas te sirven para que una vez que te enfrentes a un problema real, tengas ya un abanico de soluciones probadas de antemano y sepas cual le va mejor. Sí, esto también te lo da la experiencia, pero cuanto más hayas practicado, en el trabajo y fuera, mejor... Y no es que sean sustitutos, son complementos. Por ejemplo, el día que quedé con Alberto (@plagelao) para hacer la kata de los números romanos, él tenía una idea en la cabeza de estructura que quería probar a ver que tal quedaba. Esto con un problema real si te sale bien a la primera perfecto, has triunfado, pero si haces una chapuza te hace tener que volver a empezar, cosa que es mucho menos admisible si trabajas para cliente.

si por ejemplo a mi me diera por practicar el TDD directamente sobre el código del cliente, seguramente lo que me saldría sería una basura además de tardar días en hacer un hola mundo.

Por eso haces baby steps y no cambios revolucionarios. Recuerda que te pagan para resolver problemas. Pero no te dicen cómo. Asume riesgos y sus consecuencias.

Por qué asumir riesgos si puedo ir más aprendido? Hay cosas que creo que practicar a medias es pérdida de tiempo, o las haces completas o no las hagas. No se trata de hacer cambios revolucionarios, pero si quiero saber que tal me desenvuelvo con TDD y aprender a hacerlo, para luego crearme un criterio de si a mi me funciona o por el contrario voy a peor, casi mejor hacerlo en casa. También puedo optar por la solución de no introducir más cambios que probar la librería tal o el framework cual, pero yo prefiero practicar todo lo que leo que me parece interesante (leído casi todo mola mucho) y luego quedarme con lo que creo que seré más productivo.

De todas formas, estando por USA no se que haces escribiendo en estos foros... ;) Pásalo bien!

Un saludo.

[Jesús Jiménez]

El 18 de enero de 2011 04:09, Abel Muiño Vizcaino <amu...@gmail.com> escribió:

Estoy de acuerdo contigo en que no todo el mundo es un gran profesional. Pero todos esos malos profesionales sin pasión por su trabajo jamás se interesarán en el craftmanship… Y los que sí se interesan son profesionales y apasionados por su profesión.
Así que el Craftmanship predica a conversos. Y en ese contexto casi nada de lo que dice Uncle Bob tiene sentido.

Es que, según lo entiendo yo, en general el mundo craftsmanship (siempre habrá excepciones), no trata de convertir a nadie, aquí no hay evangelizadores, ni certificaciones (espero que no las haya) ni nada parecido. Esto es un movimiento para como dices los conversos, y es lo que trata de decir Uncle Bob en el artículo, el craftsmanship es sólo porque queremos dejar de hacer mierda. Da igual lo que hagan los demás, cada uno sabrá cual puede ser la mejor manera para aprender y cada uno que siga la suya, sea en el mundo de la artesanía o en otro

[Luis Fraile]

Buenas a todos, después de leer todo el hilo, y de seguir últimamente con bastante interés lo que se está escribiendo acerca del software craftmanship, la verdad es que mi punto de vista está cercano al de Abel.

 

Por supuesto que tenemos que ser profesionales en nuestro trabajo, y por supuesto que no todo nuestro aprendizaje se lo tenemos que repercutir al cliente, y por supuesto que la calidad del código, más allá del lenguajes o frameworks, es fundamental, la calidad de nuestro software, en gran medida (no sólo) define la calidad del producto final.

 

Pero también son ciertas muchas otras cosas,, como que estamos 8 horas al día aprendiendo y prácticando con problemas reales de nuestros clientes, que poco o nada tienen que ver con las katas, y aunque estas me parezcan estupendas, no sólo con katas podemos aprender.

 

Respecto al ejemplo de los músicos, bueno quizá no sea el más adecuado, o sí (a mi si me lo parece), pero ¿acaso creéis que cuando compráis un coche, una lavadora o cualquier producto, en parte de su precio, no estáis pagando las horas de invesitgación, de aprendizaje, y de pruebas de nuevas tecnologías para hacer mejores y más eficientes los productos? Por supuesto que las pagamos, y digo más, me encanta pagarlas, eso significa que detrás de todas esas mejoras hay un trabajo con una dedicación y unos medios, más allá de que algún ingeniero lo haya probado en casa.

 

Por supuesto, que con este mismo ejemplo, muchos ingenieros, antes de ir a probar esas nuevas soluciones, se les han ocurrido en su casa probando cosas nuevas, eso es normal, pero el trabajo "grande" detrás, ocurre más allá del tiempo o la capacidad de practicar cada uno en sus ratos libres.

 

Por eso, y siempre teniendo muy claro que tampoco todo vale a la hora ni de programar, ni de aprender a costa del cliente, creo que este movimiento, es simplemente: preocupate más por tu trabajo y por la dedicación que en ello pones. Cosa que puede que haya gente que no lo cumpla, pero por mucho que le pongas manifiestos, va a seguir sin cumplir.

 

Y por tanto, totalmente de acuerdo con que el craftmanship predica a conversos, y que no estoy del todo de acuerdo en muchas de sus argumentaciones.

Un saludo,
Luis Fraile
http://www.lfraile.net
[MCSD .NET]   [MCTS TFS]
[MVP Team System]

2011/1/18 Jesús Jiménez <jjba...@gmail.com>

--

[German DZ]

Antes que nada, gracias a todos los que vienen aportando, porque da gusto leer cosas de las que uno aprende.

Respecto a las katas vs problemas de cliente. Se aprende con todo, pero una pregunta:

Luego de entregar al cliente, ¿cuántos siguen mejorando ese código/solución a pesar de estar "aceptado"?

Las katas, los dojos y los retreats nos dan un espacio seguro, en el cual podemos arriesgar, probar y ensayar cosas que no se puede hacer en la construcción de una solución. Yendo hacia las odiosas comparaciones con otras disciplinas;

- Un marinero practica nudos y maniobras con buen clima incluso en puerto. No se inventa un nudo durante una regatta o tormenta.

- Un bombero de rescate, no se inventa un arnés cuando tiene una persona con riesgo de vida.

Esas prácticas, aunque parezcan triviales o futiles, hacen al hábito y permiten tener una destreza y tranquilidad al momento de ejecutar las maniobras de forma tal de concentrarse en el objetivo final.

Os seguiré leyendo atentamente.

2011/1/18 Luis Fraile <lfr...@gmail.com>

[Leo Antoli]

Interesante hilo :-)

Yo creo que una de las cuestiones de fondo que se está discutiendo en este hilo es cuanto tiempo deberíamos dedicar a la profesión, como ya se ha comentado p.e. en  https://groups.google.com/forum/#!topic/software_craftsmanship/qOvxAkRbFAk

En un mundo en el que sólo nos quisiéramos dedicar al trabajo, está claro que cuanto más tiempo le dediquemos, mejor seremos en el trabajo. Eso no quiere decir que haya gente a la que le apasione su trabajo pero no dedique todo su tiempo a él.

Como dice Abel, nosotros ya practicamos todos los días 8 horas o más con el cliente, y creo que la "controversia" es en cuanto tiempo hay que practicar después del trabajo con el cliente, en fines de semana, etc.   

Sin querer profundizar mucho en lo ético o no ético de aprender en el trabajo, creo que lo no ético es venderle al cliente que eres la máquina en algo que no tienes ni idea, pero creo que incluso el más experto en un framework -o lo que sea- seguro que sigue aprendiendo cosas cuando lo usa en el cliente. Creo que es ético mientras se vaya con honestidad al cliente.

Me ha parecido interesante la respuestas de Jose María Arranz que pongo a continuación a raíz de un post en Javahispano de JM Beas:

(pongo el texto porque no hay links a comentarios individuales)

"""

Yo por mi parte me gustaría contar mi teoría de la "mediocridad multidimensional elástica"

Esa chorrada de título no quiere decir más que el ser humano vive en un espacio de tiempo, tiene limitaciones en lo que es capaz de hacer/aprender en ese tiempo y que su vida es multidimensional: familia, amistad, hobbies, descanso, cultura, ocio, deporte... y como no... trabajo.

La mayor o menor dedicación a cualquiera de esas dimensiones supone un índice de mediocridad, a mayor dedicación a una dimensión más mediocre eres en las demás.

Cada dimensión pugna por llevarse todo tu tiempo y defenderá que es la dimensión más importante y que merece todo el tiempo de mundo.

La mediocridad es inevitable, un ejemplo tonto muy sencillo, si eres buen programador con total seguridad serás un absoluto mediocre en el ámbito de la cirujía y viceversa.

Dicho esto cada uno, si puede, debe decidir cuanto mediocre es con su trabajo, con su familia, con sus amigos, con su bienestar físico, con su cultura, con su descanso, con sus aficiones, con su ocio.

Ahora bien, cualquiera con un dedo de frente sabe que la supremacía abusiva de una dimensión suele acarrear muuuuuuchos problemas de todo tipo (mentales, físicos, familiares, sociales, laborales etc etc).  

Respecto algunos gurus hay que ser prudente, pues cada uno tiene su agenda, a Robert Martin le interesa que

* Leas SUS libros

* Que asistas a SUS conferencias

* Que leas SU blog

* Que leas SU Twitter

... y que gracias a todo eso estés mucho más cerca de contratarle SU consultoría y/o SU coaching.

 No digo que esté mal pero de ahí a extraer leyes universales de lo que debes hacer con tu vida...

"""

[Juan Carlos Quijano Abad]

Buenas,

Mi resúmen de lo que comenta Bob es el mismo que solté ayer en el twiter en cuanto lo leí: Si tienes el poder de hacerlo realidad , está muy bien. Si no es pura basura.

Pero traduzco alguna lineas y sobre ellas doy mi opinión.

What we are not doing: Cosas que no vamos a hacer.

• We are not putting code at the center of everything.
  

• No vamos a poner el codigo en el centro de todo.
  
  Posiblemente con lo que más de acuerdo estoy. Una vida profesional, centrada unicamente en el código es mala. El desarrollo es MUCHO MAS que esto. Mucho, mucho, mucho más. Y muy divertido.
  

• We are not turning inward and ignoring the business and the customer.
  

• No vamos a quedarnos mirandonos a nosotros mismos y olvidar a la empresa y a los clientes.
  
  Obvio. Tan obvio que es curioso como algunos caen una y otra vez en esto.
  
  
• We are not inspecting our navels.
  No nos vamos a mirar el ombligo
  
  También una obviedad en la que caen algunos. Centrados en la "pureza del camino" y en abanderar de manera furibunda la calidad del software y olvidandose de lo bonito que es el desarrollo más allá de la codificación.
  
  
• We are not offering cheap certifications.
  No vamos a ofrecer certificaciones baratas (también se puede traducir como "cutres").
  
  Esto supongo que es una pulla para alguién. Pero las certificaciones no son buenas por su precio. Si no por quien está detrás. Y, he argumentado en varios hilos, el porqué pienso que las certificaciones son buenas.
  
  
• We are not forgetting that our job is to delight our customers.
  No olvidamos que nuestro trabajo es satisfacer a nuestros clientes.
  
  Otra obviedad, pero muy cierta. Y que es importante que los desarrolladores seamos consciente que el satisfacer al cliente depende en gran medida de cosas que están fuera del desarrollo.
  

El siguiente bloque es más polémico:

• We will not make messes in order to meet a schedule.
  No vamos a hacer líos con el fin de cumplir un calendario.
  
  Ole si tienes el poder de hacer algo así. O es tu empresa (y no siempre) o tienes un cargo o carguillo que te permite hacerlo (en mi caso es carguillo). Pero si no tienes ese poder, y es casi en todos los casos, esto es pura basura. Es demagogía. La inmensa mayoría trabajamos por dinero. Y no te lo vas a jugar si te aprietan. Que tarde o temprano te vayas es volver al punto de si tienes poder o no para hacerlo.
  
  
• We will not accept the stupid old lie about cleaning things up later.
  No aceptamos la estupida mentira sobre "ya lo arreglaremos despúes".
  
  Amén. Pero si lo llevas a rajatabla es romper con "No ponemos el código en el centro de todo". Hay causas empresariales, estratégicas o de de calendario que te empujan a tener que dejar una cosa sin acabar o mejorar, para empezar otra. Hay mil ejemplos.
  
  
• We will not believe the claim that quick means dirty.
  (no estoy seguro) No creemos en la afirmación que es mejor hacerlo mal si se hace más rápido.
  
  Amen.
  
  
• We will not accept the option to do it wrong.
  No aceptaremos la opción de hacerlo mal.
  
  Amen, si tienes el poder de decidir. Si no lo tienes está afirmación es demagogica.
  
  
• We will not allow anyone to force us to behave unprofessionally.
  No vamos a permitir que nadie nos oblige a comportarnos de modo poco profesional.
  
  Amen, si tienes el poder de decidir. Si no lo tienes está afirmación es demagogica. Pero esto tiene el problemón de definir qué es el modo profesional. Y tenemos para un hilo completo de debate sobre profesionalidad.
  

• We will meet our schedules by knowing that the only way to go fast is to go well.
  

• Vamos a cumplir nuestros calendarios sabiendo que la única vía para hacerlo derpisa es haciendolo bien.
  
  Ufff, frase de autoayuda. Si los calendarios se cumplieran SOLAMENTE por hacerlo bien, yo sería muy feliz y mi jefe aún más. Esta frase no tiene sentido, no dice nada. ¿Qué es hacerlo bien? Recordemosr que el primer punto es "No vamos a poner el codigo en el centro de todo."  Y que el desarrollo del código es una variable de la formula, una de tantas.
  
  
  

• We will delight our customers by writing the best code we can.
  

• Satisfaremos a nuestros clientes escribiendo el mejor código que podamos.
  
  
• We will honor our employers by creating the best designs we can.
  Respetaremos a nuestros empleadores escribiendo creando el mejor diseño que podamos.
  
  
• We will honor our team by testing everything that can be tested.
  Respetaremos a nuestro equipo.testeando todo aquello que pueda ser testeado.
  
  
• We will be humble enough to write those tests first.
  Vamos a ser lo suficientemente humildes como para escribir las primeras pruebas.
  
  ¿Qué tiene que ver una técnica de programación con la humildad?
  
  
• We will practice so that we become better at our craft.
  Vamos a practicar para que podamos mejorar en nuestro arte (artesania).
  
  
  Solamente me parece válida la última frase. Las demás son de autoayuda, que no dicen nada. Buenas intenciones. Son del tipo "Voy a ser mejor cada dia y voy a ser FELIZ".
  

• Anything worth doing is worth doing well.
  Si vas a hacer algo, hazlo bien
  
• Slow and steady wins the race.
  Despacio y con constante ganan la carrera
  Despacito y con buena letra
  
  Esto es falso en las carreras. El más rápido y constante gana la carrera. El camarón que se duerme se lo lleva la corriente. Por eso prácticamos para hacer más en menos tiempo y de forma lo más limpia posible.
  
  
• Measure twice cut once.
  Antes de cortar mide dos veces.
  
• Practice, Practice, Practice.

El resto del documento no me ha dado tiempo de traducir. A ver si mañana me dá tiempo de aportar mis opiniones al interesante debate.

Solamente puntualizar dos entradas.

JMB:

"No me parece ético hacer que mis clientes paguen para
que yo aprenda a usar el framework tal o la herramienta pascual."

Esto se llama I+D o I+D+I. Directa o indirectamente el coste del aprendizaje se carga en los proyectos. Acaso cuando compramos un hardware nos molesta pagar el precio del I+D del fabricante o es algo a valorar positivamente?. ¿Si la empresa va a ganar dinero con la mejora en el conocimiento, porqué debe asumir el coste el desarrollador? 

"No me parece bien que yo no pueda dar estimaciones fiables de mi trabajo
simplemente porque no tengo el conocimiento o la preparación necesaria
para ello."

Nop, hay muchas más cosas que hacen que las estimaciones fallen que el conocimiento o preparación o experiencia de quienes las realizan. Problemas de RRHH (bajas, rotación, incompatibilidades,  etc.), problemas profesionales (conocimiento, entusiasmo, talento del equipo), requisitos (requisitos invisibles, requisitos desconocidos, requisitos emergentes, requisitos cambiantes), problemas empresariales (estrategia empresarial, apuesta tecnológica, barreras de entrada de mercado, apertura de nuevos mercados) y muchas mas razones.

Alfredo:

"Yo no he visto esa preocupación por los clientes ni por entender sus problemas en ningún sitio""

Te puedo asegurar, en primera persona, que esos sitios existen. Si bien es cierto que cuanto más capacidad de decisión se tenga, más facil es hacer que la relación con el cliente sea como indicas que no te has encontrado.


P.D. A ver si mañana puedo seguir comentando en este interesante hilo.
--

Un saludo

Juan Quijano

 

Blog de .Net y Gestión de proyectos

Blog de opinión social

Blog de World of Warcraft

Blog de Tiro con Arco

[Alfredo Casado]

Solo una cosa juan carlos: todos tenemos el poder de decidir, sólo hay que despertarse y darse cuenta. 

Yo decido como hago mi trabajo, lo hago siempre lo mejor que puedo, y no voy a aceptar de nadie que me "obligue" ha hacerlo peor porque eso es poner en juego mi profesionalidad. Además que tampoco hay ningún motivo coherente para "hacerlo peor", peor significa más lento, y mucho antes de lo que parece.

Siempre pongo el ejemplo de un carpintero, mi primo es carpintero, y si hace una mesa la hace bien o no la hace, porque si hace una porquería de mesa y alguien la ve y sabe que es suya su profesionalidad queda en entredicho. Muchos que se jactan de títulos e ingenierías podrían aprender mucho sobre profesionalidad de un "simple" carpintero.

En realidad la frase de arriba tiene una excepción, hay gente que no tiene poder para decidir que va a hacer un buen trabajo: los que no saben hacer un buen trabajo. El conocimiento es libertad, es un echo que también aplica al desarrollo de software.

[Juan Carlos Quijano Abad]

Buenas,

"Solo una cosa juan carlos: todos tenemos el poder de decidir, sólo hay que despertarse y darse cuenta. "

Je, je, je quisiera darte la razón pero esta frase tiene tanta validez como "Despierta, TU PUEDES, SE FELIZ". La validez depende muchísimo de quien la lea.

Quien es jovén sin ataduras ni hipotecas tiene mucho más poder de decisión que alguién con 55 tacos, dos hijos, separado y con una grandísima experiencia en un framework de programación como Gotta (vamos que no consigue trabajo ni a empujones).

Como se dice en tantos casos... depende. O al menos así lo veo yo que estoy haciendo un sobreesfuerzo continuado para mitigar la parte de los años con mantenerme todo lo renovado que pueda. Que lo de ganar años es una jodienda.

--

Un saludo

Juan Quijano

 

Blog de .Net y Gestión de proyectos

Blog de opinión social

Blog de World of Warcraft

Blog de Tiro con Arco

[jorge]

No quisiese ser aguafiestas pero... Depende. Cada uno tiene un concepto de hacerlo bien, en tiempo, calidad, coste, o lo que quiera que cada uno piense que puede ser muy similar o muy diferente.

Son bonitas palabras que, excepto un bromista, no aceptaría. Sobre cómo mejorar y la validez de las analogías del artículo original y de la lista podemos estar más o menos deacuerdo:

• La mayoría de los músicos son intérpretes, ejecutan mejor o peor el mismo problema una y otra vez. Los autores, son una minoría y de esta minoría podríamos discutir qué es de calidad y qué no ya que muchas veces es cuestión de sensaciones y, bueno, en los conciertos hay improvisación ;)
• Lo de los abogados, sinceramente, cómo practican?
• La abuela *de un amigo* tiene una mesa que heredaron generación tras generación y, os lo aseguro, es horrible!! Supongo que a ellos les gusta ;)

Lo primero que quiero decir en mi contra es que el tema de la práctica me lo creo a medias, que como concepto encaja pero luego, en el escenario no repito el mismo problema, sólo lo hago cuando practico. Pero también podríamos decir que qué mejor que dar conciertos todos los días durante 8 horas!!! 

No es lo mismo Messi o CR7 (sí, esto es fútbol) que son los mejores del mundo (o esto era Xavi ;) ) que el mejor de la liga del barrio o el mejor de mi patio.

2011/1/18 Juan Carlos Quijano Abad <juancarl...@gmail.com>

[Edu Rodríguez]

Amén!

Yo de todo esto saco que la artesanía consiste en hacerlo lo mejor que se puede teniendo en cuenta las circunstancias en las que se encuentra el proyecto, no en hacer el código perfecto, sino dejarlo asegurado para que otro (o tu mismo) pueda perfeccionarlo con el tiempo. Para hacer tirarte horas engloriado haciendo código perfecto están las katas. Eso es de sentido común.

Coincido con Alfredo en que todos tenemos el poder de decidir. Quizá, si, por ejemplo, eres programador junior no puedas cambiar la metodología de tu empresa pero bien podrás automatizar una tarea que antes se hacía manualmente, por poner un ejemplo chorra o quizá, si ya vas por historias más ambiciosas, puedas hablar con tu superior e intentar explicarle qué quieres cambiar y en qué os vais a ver beneficiados.

Pero para poder decidir mejorar tú trabajo primero tienes que sentarte a pensar en qué puedes mejorarlo tú. Y eso hay gente que le cuesta. Se llama empatía hacia ti y tus compañeros. Hay gente que carece de ese sentimiento. A estos, no los soporto.

Un saludo 

2011/1/18 Alfredo Casado <casado....@gmail.com>

--
Edu

[Abel Muiño Vizcaino]

Ha salido varias veces el tema de si puedo o no puedo venderme como experto en algo que no conozco, meter un framework nuevo "para aprender", etc…

Así que contesto aquí que me viene a mano, pero es la misma respuesta para varios mensajes:

El 18/01/2011, a las 02:06, German DZ escribió:

- Un marinero practica nudos y maniobras con buen clima incluso en puerto. No se inventa un nudo durante una regatta o tormenta.

- Un bombero de rescate, no se inventa un arnés cuando tiene una persona con riesgo de vida.

Esto viene de la frase: "We will practice so that we become better at our craft."

Veo muy diferente adquirir "core competencies", "practicar" (con problemas de juguete) y "adquirir experiencia" (practicar con problemas reales).

No me gusta, pero voy a meterme con paralelismos imperfectos:

Es como sacarse un título universitario.

Vas a clase y adquieres las "core competencies".

Luego consigues un empleo con ese título y te caen tortas por todas partes… como tienes las "core competencies" navegas como puedes y "adquieres experiencia".

Lo de "practicar" con katas (problemas de juguete) está bien, no sobra, pero ni te da "core competencies" ni "experiencia". Si queréis, sirve para "fijar conocimientos".

Y otro paralelismo imperfecto… Por mucho que yo repase la tabla del 8 no seré mejor matemático :-)

[Alfredo Casado]

alguién con 55 tacos, dos hijos, separado y con una grandísima experiencia en un framework de programación como Gotta 

Esa persona tenía el poder de decidir, y decidió no invertir en su profesión. Todos podemos decidir, pero luego hay que apechugar con las decisiones tomadas. Si tenías unas responsabilidades económicas (familia, hipotecas etc,etc) y no has invertido en tu profesión para poder cumplir con esas responsabilidades, pues sinceramente, ya es tarde para lamentarse.

Y conste que no cuestiono la decisión, cada uno es muy libre de decidir en que invertir su tiempo y sus esfuerzos, pero las decisiones tienen consecuencias y hay que asumirlas.

[Harald Messemer]

Sobre uno de los temas tratados en este hilo: "vender cosas que
alguien no sabe o aprender pagado".

Opino que la transparencia es clave en este aspecto. He visto y he
aprendido que no se debe enganar al cliente relativo a lo que sabes,
sino hay que decir de la manera mas objetiva posible la experiencia
que tienes como persona o empresa.

En consecuencia hay situaciones donde no eres competitivo, porque hay
otros que saben mas que tu y por eso son mejores que tu en este temas.
Si es asi me retiro y asi esta bien en mi opinion.

Pero hay situaciones donde le conviene al cliente de contratar alguien
que no sepa o donde simplemente no tiene otro remedio que contratar
alguien aunque no sepa o sepa poco. Dos ejemplos:

1) Conocimientos multiples

Los proyectos de hoy en dia suelen requerir alguien que conoce la
tecnologia, el sector, las soluciones de la casa, que tenga
metodologia, que sepa gestionar y hablar como Steve Jobs. Muchas veces
no hay una empresa que cumple todo esto y se tiene que.contratar
alguien con conocimiento sectorial, aunque tendra que aprender la
tecnologia.

2) Tecnologia nueva

Sale algo nuevo y no hay nadie en el mercado que sepa. En este caso
puede ser razonable de contratar alguien que ha demostrado su
capacidad de aprendizaje y el valor diferencial es la velocidad de
aprendizaje

Vamos, no le veo ningun problema en cobrar aunque no sepas, pero el
cliente deberia saberlo antes y tomar la decision que mas le conviene.

Saludos,
Harald

2011/1/18, Abel Muiño Vizcaino <amu...@gmail.com>:

> --
> Has recibido este mensaje porque estás suscrito al grupo "agile-spain" de
> Grupos de Google.
> Para publicar una entrada en este grupo, envía un correo electrónico a
> agile...@googlegroups.com.
> Para anular tu suscripción a este grupo, envía un correo electrónico a
> agile-spain...@googlegroups.com
> Para tener acceso a más opciones, visita el grupo en
> http://groups.google.com/group/agile-spain?hl=es.
>
>

--
Gesendet von meinem Mobilgerät

[jcesarperez]

A mi Uncle Bob o Robert C. Martin me encanta cuando habla de cosas
técnicas y me encanta cómo programa. He aprendido muchisimo leyéndole.

Pero cuando se sale de ahí, no sé, hay una parte que no termina de
encajarme.

Por ejemplo:
Algunos habéis dicho que no está diciendo que el código sea lo más
importante. O al menos no lo interpretáis así.
Este artículo que estamos discutiendo es del 17 de Enero del 2011.
El 17 de Octubre de 2010 escribía lo siguiente:

_More importantly, what is the single most effective way to increase
the chances of project success? Is it improving requirements?
Management? Schedules and budgets? All those things would help, but
they are all secondary to the thing that truly drives project
failure: The cost of the code._

La fuente: http://thecleancoder.blogspot.com/2010/10/cost-of-code.html.

Y esto no quiere decir que no esté en parte de acuerdo con las ideas
que transmite. A lo mejor es que cogemos sus párrafos y los sacamos de
contexto hasta el punto de perder de vista la idea principal que
intenta transmitir. O a lo mejor es como dicen otros que predica
principalmente a conversos y así es muy fácil, tanto predicar como
vender.

En lo que no estoy de acuerdo es en que a algunos les parezca pecado
que parte de lo que paga el cliente por un producto se use para
aprender. No sé los demás, pero yo me podría tirar toda la vida
estudiando y practicando que nunca llegaría a saberme al 100% ningún
lenguaje o framework complejo, ni a conocer al dedillo el negocio del
cliente, ni a enfrentarme a todos los problemas técnicos que no salen
en los libros, tutoriales o ejemplos didácticos, ni a saber de qué pie
cojean mi jefe, mis compañeros y los interlocutores del cliente,...
etc.

A lo mejor los que trabajan para si mismos y facturan en base a lo
entregado y no en jornadas, pueden decirlo. Pero a mi no se me ocurre
decirle a mi jefe que me decuente del salario las horas que he pasado
experimentando con tecnologías o analizando el negocio del cliente o
simplemente en internet.

Un saludo,
Julio.

[Arturo Herrero]

Creo que el software craftsmanship va un poco más allá. No sólo se trata de ser profesional, sino de una mejora continua. Quizás se olvida la parte que trata de colaboración, de aportar más valor añadido y de tener esa predisposición a ir un paso más lejos.

El practicar con katas es simplemente un ejemplo de entre otras miles de cosas que se pueden hacer para mejorar. Los que creen que las katas no aportan nada, que practiquen con un proyecto personal. De hecho, creo que voy a montar 12 meses 1 startup, con un poco de suerte hasta podemos practicar y hacernos millonarios.

PD. Un abogado puede mejorar leyendo sobre su profesión, compartiendo conocimientos con el resto de sus compañeros, especializándose en algún tema muy concreto, leyendo el libro Cómo hablar en público y embaucar con su sonrisa a un jurado, grabándose en vídeo y mejorando su lenguaje corporal, viendo todas las pelis de abogados del mundo... Muchos abogados aprobaron su oposición y quieren hacer lo mínimo, pero a algunos otros les apasiona su trabajo, quieren seguir mejorando y quizás estos últimos algún día se denominen advocacy craftsmanships.

[Carlos Ble]

Joer macho como procastinais :-)

--

Has recibido este mensaje porque estás suscrito al grupo "agile-spain" de Grupos de Google.
Para publicar una entrada en este grupo, envía un correo electrónico a agile...@googlegroups.com.
Para anular tu suscripción a este grupo, envía un correo electrónico a agile-spain...@googlegroups.com
Para tener acceso a más opciones, visita el grupo en http://groups.google.com/group/agile-spain?hl=es.

--
Carlos Ble
www.MavenCharts.com
www.iExpertos.com
www.carlosble.com

[Abel Muiño Vizcaino]

El 18/01/2011, a las 14:19, Arturo Herrero escribió:

De hecho, creo que voy a montar 12 meses 1 startup, con un poco de suerte hasta podemos practicar y hacernos millonarios.

Si quieres practicar "cosas técnicas", con la startup vas muy mal… eso es lo fácil y lo que menos tiempo te llevará. Pero te puedo garantizar que practicar, vas a practicar (otras cosas, eso si). En todo caso, acorta el tiempo. Construir tu MVP no puede llevarte un año… 

Puestos en esa línea, a mi me parece mucho más interesante dedicar el tiempo a copiar a los chicos de Eden y trabajar en un proyecto para una ONG. Tienes cliente, proyecto real y te centras sólo en la parte "informática" (gestión y técnica).

https://github.com/edendevelopment/cfi

[Miguel Angel]

Hola.

Me ha gustado la propuesta de traducción. Como era poquito, lo tenéis en mi blog

http://magmax.org/drupal/craftmanship

Parece que la gente comenzó por el final, por discutirlo en la lista :D

Un saludo.

El 17 de enero de 2011 23:19, José Manuel Beas <jose....@gmail.com> escribió:

¿Alguien se anima a traducir el último artículo de UncleBob?

http://cleancoder.posterous.com/software-craftsmanship-things-wars-commandmen

Bueno, o a discutirlo en esta lista. También sería interesante. (Eso
sí, obligatorio leerlo antes, claro) :-)

Un saludo,
Jose Manuel Beas

http://agilismo.es
http://jmbeas.iexpertos.com
http://twitter.com/jmbeas

--
Has recibido este mensaje porque estás suscrito al grupo "agile-spain" de Grupos de Google.
Para publicar una entrada en este grupo, envía un correo electrónico a agile...@googlegroups.com.
Para anular tu suscripción a este grupo, envía un correo electrónico a agile-spain...@googlegroups.com
Para tener acceso a más opciones, visita el grupo en http://groups.google.com/group/agile-spain?hl=es.

--
Miguel Ángel García Martínez
http://www.magmax.org
http://twitter.com/magmax9

[Juan Carlos Quijano Abad]

Buenas,

Absolutamente en desacuerdo contigo. Me parece un juicio durísimo, basado en conclusiones que no indica la frase señalada.

--

Un saludo

Juan Quijano

 

Blog de .Net y Gestión de proyectos

Blog de opinión social

Blog de World of Warcraft

Blog de Tiro con Arco

[jorge]

Mi granito de arena: http://www.slideshare.net/MindProject/de-la-conceptualizacin-a-la-ejecucin-5913998 (sólo hace falta ver la slide de la rana, la 3 ;) )

Aún así, alfredo y juan carlos, de lo que estás hablando es de otra cosa totalmente diferente que tiene que ver con el paternalismo industrial y que, en mi opinión, pertenece a otro ámbito.

Yo creo que, intentando simplificar, como en casi todos o todos los ámbitos de la vida, podría decir que hay gente que va a remolque y gente que no (en los dos hay muchos muchos muchos grises). Sobre esto hay mucho escrito: éxito aplazado, zona de confort, los 7 hábitos y un larguísimo etcètera que me parece que está mucho más relacionado y es de mucho mayor calado que el artículo.

Por otro lado, es gratis criticar y poner en duda las decisiones de los demás, mirando al pasado y decirnos a nosotros mismos *yo nunca haré/seré...* porque, para los que no sean ranas (las del slide 3, sí) es mucho más fácil convertirse en ellas que para los que ya lo somos ;)

2011/1/19 Juan Carlos Quijano Abad <juancarl...@gmail.com>

[Alejandro Pérez García]

Ciertamente es un juicio durísimo, pero bastante acertado.

La vida es un juego de largo recorrido, por eso hay que hacer inversiones de todo tipo (profesionales, amigos, familia, salud, ...).

Esas inversiones que hacemos hoy son las que nos rentarán cuando tengamos 55 años. Si hoy no invertimos (y con "hoy" me refiero a todos los días), cuando seamos "mayores" no tendremos esas "rentas", por lo que el ámbito de nuestra vida donde no hicimos la inversión seguramente esté en peligro (ya sea el amor de nuestra pareja, la compañía de nuestros amigos, o nuestro puesto de trabajo).

El gran problema es que nos encanta (y me incluyo) echar valones fuera y culpar de todo lo malo que nos pasa a cualquiera menos a nosotros mismos (que si el gobierno, que si la sociedad, que si la industria, que si mi empresa, que si mi jefe, que si mis compañeros, ...). Esto es algo natural ya que nos hace sentir más "cómodos" con nosotros mismos (vamos, que no lo digo yo, que está estudiado).

Cuando se habla del craftmanship, o de profesionalidad, de lo que estamos hablando es de esto, de estar preparado de hacer esas inversiones, de ser conscientes de nuestra situación, de ese "coraje" del que habla muchas veces Xavi Gost, coraje para tomar decisiones, en muchos casos difíciles.

Una buena muestra de que la edad no es condicionante, podría ser Uncle Bob, que ya tiene unos añitos y sin embargo sigue siendo referente y motor de cambio (y como él hay muchos otros). No creo que Uncle Bob este donde está por casualidad, ni que le haya resultado fácil, pero es una clara muestra de que es posible.

Saludos

--

Alejandro Pérez García

Socio fundador de Autentia y www.adictosaltrabajo.com

(Desarrollo, Consultoría, Formación)

mailto:aleja...@autentia.com

Tel.: 655 99 11 75

Autentia Real Business Solutions S.L.

       "Soporte a Desarrollo"

http://www.autentia.com

Este mensaje, y en su caso cualquier fichero anexo al mismo, puede contener información confidencial y/o privilegiada, siendo para uso exclusivo del destinatario. Si Vd. no es el destinatario o lo ha recibido por error, por favor, informe inmediatamente al emisor y destrúyalo. Está estrictamente prohibido por la legislación vigente realizar sin autorización cualquier copia, revelación o distribución del contenido de este mensaje sin la autorización expresa del remitente. Las opiniones expresadas en este correo son las de su autor y no son, necesariamente, compartidas por Autentia Real Business Solutions S.L.

This e-mail, and in the case of any file annexed to it, may contain confidential and/or privileged information, and it is exclusively for the use of the addresses of the message. If you are not the intended recipient (or have received this e-mail in error), please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden by current legislation. The points of view expressed in this e-mail are solely those of the author and may not necessarily be from, or supported by, Autentia Real Business Solutions S.L.

[jorge]

Alejandro, seguro que te suena el speech de jobs en standford con el que se te pone un nudo en la garganta ;), la parte que habla de el ciclo de la vida... justo antes de lo de 'stay hungry, stay foolish'

2011/1/19 Alejandro Pérez García <aleja...@autentia.com>

[Roberto Vázquez González]

Muchas gracias por tu trabajo Miguel Ángel

[Abel Muiño Vizcaino]

Sólo para que me quitéis la razón y me quede tranquilo…

No está nadie diciendo que el Craftsmanship <==> Profesionalidad ni que para ser buen Craftsman debas renunciar a "invertir" en familia y amigos ¿verdad?

Es que me da la sensación de que, para algunos, ese tio de 55 años del que se habla se convirtió en un no-craftsman (y por lo tanto mal profesional) de repente por tener una hipoteca y niños… y preferir pasar los fines de semana con su familia en lugar de irse a hacer code katas a algún lugar remoto.

(Y no digo que no se puedan hacer las dos cosas, pero es que hay gente que lo hace bien sin "comulgar" con el craftmanship… ni TDD, ni katas, ni retreats… pero aun así apasionada y dando buenos resultados en su trabajo).

Ya es bastante difícil encontrar a gente con la que tener una buena conversación técnica como para empezar a descartar a los que no cumplen con la checklist de Uncle Bob porque "no son profesionales".

--

Abel Muiño

http://abelmuino.es

[Jesús Jiménez]

No se que pensarán los demás, pero ahí va lo mío.

El 20 de enero de 2011 17:46, Abel Muiño Vizcaino <amu...@gmail.com> escribió:

Sólo para que me quitéis la razón y me quede tranquilo…

Lo intentaremos :)

 

No está nadie diciendo que el Craftsmanship <==> Profesionalidad ni que para ser buen Craftsman debas renunciar a "invertir" en familia y amigos ¿verdad?

Hace poco salió en la lista de craftsmanship algo de este tipo. En él si no recuerdo mal, uncle bob (del que hablas más abajo) decía que cada uno tiene que saber a cuánto renunciar del resto de cosas por mejorar en su profesión. Estoy bastante de acuerdo, creo que todo depende de lo que quieras conseguir y de lo que estés dispuesto a renunciar.

Y no, Craftsmanship no es lo mismo que profesionalidad. Es que realmente el movimiento Craftsmanship no te dice lo que tienes que hacer, simplemente es un movimiento para hacer bien las cosas, ya sea con o sin tdd, con o sin katas, con o sin agilismo... vamos, al final se trata de cosas de sentido común.

 

Es que me da la sensación de que, para algunos, ese tio de 55 años del que se habla se convirtió en un no-craftsman (y por lo tanto mal profesional) de repente por tener una hipoteca y niños… y preferir pasar los fines de semana con su familia en lugar de irse a hacer code katas a algún lugar remoto.

Lo que se dice de ese tío de 55 años es que si durante los 30 que lleve trabajando no ha hecho NADA por mejorar y lo único que sabe es una tecnología (o lo que sea) que ya no tiene futuro, es algo que él mismo se ha buscado. No se trata de que esté a la última y practique a diario ni nada, eso es algo que va en cada uno, pero en esta profesión o le dedicas un poquito de tiempo a actualizarte o sabes que tendrás fecha de caducidad. Y con 55 años, hipoteca e hijos, difícil volverte a poner al nivel necesario para el mercado.

 

(Y no digo que no se puedan hacer las dos cosas, pero es que hay gente que lo hace bien sin "comulgar" con el craftmanship… ni TDD, ni katas, ni retreats… pero aun así apasionada y dando buenos resultados en su trabajo).

Esto ya lo he contestado :)

 

Ya es bastante difícil encontrar a gente con la que tener una buena conversación técnica como para empezar a descartar a los que no cumplen con la checklist de Uncle Bob porque "no son profesionales".

Creo que Uncle Bob no habla de una checklist, y sino no tienes más que leerte (si no lo has hecho ya) el Clean Code. En este libro sobretodo habla de cosas de sentido común como buen naming, métodos cortos, clases cortas, buena orientación a objetos (si trabajas en este paradigma), etc...

Y vuelvo a repetir algo que ya he dicho, el craftsmanship no trata de convertir a nadie, no predica con nada, no busca convercer a nadie de que lo siga, no hay evangelistas, no hay certificaciones,... 

No se si te he tranquilizado o ha sido para peor :)

[jorge]

Sólo quería comentar que, en una empresa de (según ellos) I+D, la directora general me dijo face2face que "en esto de las IT lo que valen son los años de experiencia."

Intenté decir que no es lo mismo un año diez veces que diez años de experiencia y se rió en mi cara...

Con esto no quiero demostrar nada, sólo que hay diferentes formas de ver *la vida* ;)

2011/1/20 Jesús Jiménez <jjba...@gmail.com>

--

[Alfredo Casado]

Como yo veo si que existe una relación directa entre el craftmanship y la profesionalidad. El craftmanship es un camino para mejorar como profesional. Pero como para todo hay muchos caminos posibles.

Tampoco creo que nadie haya dicho nunca que para seguir este camino haya que renunciar a todo lo demás en la vida, no creo que nadie lo haga, y la verdad, no parece algo muy sano. Lo que si hemos dicho es que si quieres mejorar como profesional tienes que dedicar tiempo ha hacerlo, es algo de perogrullo la verdad y no entiendo tanta sorpresa por este asunto, y cada uno tomará sus decisiones y decidirá que aspectos de su vida quiere potenciar.

Lo que ocurre es que si has decidido dedicar tu vida a otras cosas como: hobbys, familia o convertirte en campeón mundial de cinquillo pues bien, cada cual que decida libremente, pero si luego profesionalmente estas "fuera de juego" con 55 años, pues sencillamente es a consecuencia de tus decisiones anteriores, que nadie se sorprenda. Igualmente, si te vuelves un craftmancrazy y le dedicas 20 horas al día pues a lo mejor te abandona tu mujer y tus hijos no te invitan a su boda, pues tu te lo has buscado oye.

Lo ideal es encontrar un equilibrio, y cada uno que busque el suyo, yo no soy quien ni estoy capacitado para aconsejar a nadie como hacerlo que es un tema muy personal. Te puedo decir lo que a mi me funciona, como me dedico a algo que me gusta no me importa echarle unas horillas más al día fuera de mi trabajo, porque en realidad es también mi hobby. Lo ideal quizá sea conseguir que tu trabajo se convierta en una parte de tu vida de la que puedas disfrutar igual que disfrutas de otras, no es fácil ni todo el mundo tiene esa suerte, pero me parece importante hacer algo por conseguirlo ya que al final, nos guste o no, si queremos comer todos los días tienes que dedicar una buena parte de tu vida al trabajo. Como decía un señor chino: "busca un trabajo que te guste y no volverás a trabajar un sólo día de tu vida".

--

[Juan Carlos Quijano Abad]

Buenas,

Solamente señalar un cosa:

alguién con 55 tacos, dos hijos, separado y con una grandísima experiencia en un framework de programación como Gotta.. "tiene menos poder de decisión".

Entiendo que Alfredo le encante darle vuelta a las cosas para que al final su enorme ego de desarrollador nos asombre a todos con su sapiencia y valentia contra el sistema. Pero este ejemplo lo dí en el contexto de rebatir que los cambios vitales no siempre son cuestión de voluntad, no es suficiente con "despertarse". Si fuera así, estariamos todos con Alberto como aprendices en Eden.

El ser humano tiene tendencia a pensar que las cosas son inamovibles. Pero la tecnología te puede dejar atrás antes de lo que piensas. Y os puedo dar un ejemplo:
Yo, década de los 90, me hago un experto en multimedia. Obtengo un Sobresaliente en la Uned con mención especial. Me paso la década entera aprendiendo animación, diseño, 3D, sonido, escritura de guiones y Macromedia Director para ser un autor multimedia completo. Y en menos de tres años aparecio la Web y me quede siendo un becario carísimo. No fué algo que se venia venir. Fue una auténtica putada. Mi suerte, que me paso antes de los treinta y tuve el tiempo de darle la vuelta y de reorientar mi carrera más hacia la gestión, sin dejar de picar nunca, para que la tecnología no me volviera a dejar con el culo al aire.

¿Alguno se atreve a poner la mano en el fuego que en 10 años POO o Java no sean un callejón sin salida tecnológico? No lo hagais... la tecnología cambia a una velocidad de vértigo. Y es como el clima, es muy facil decir lo que abria que haber echo una vez pasado.

[Ruben Orta]

Tienes toda la razón pero ser buen profesional, hacer las cosas bien y aprender día a día estoy seguro que no va a pasar nunca de moda.

Rubén.

2011/1/20 Juan Carlos Quijano Abad <juancarl...@gmail.com>

--

[jcesarperez]

¿Cómo?
No lo pillo.
¿La Web mató al Multimedia?
Pero hay una cosa en la que tienes toda la razón. Lo que nunca va a
pasar de moda es ser Jefe.

Donde yo pongo la mano en el fuego es en que lo que tampoco va a pasar
de moda nunca es resolver problemas. Eso es lo que hacemos los
Desarrolladores y no POO, ni Java, ni Picar.

Saludos cordiales.
Julio

On 20 ene, 19:35, Juan Carlos Quijano Abad

<juancarlosquij...@gmail.com> wrote:
> Buenas,
>
> Solamente señalar un cosa:

> *

> alguién con 55 tacos, dos hijos, separado y con una grandísima experiencia

> en un framework de programación como Gotta*.. "tiene menos poder de

> decisión".
>
> Entiendo que Alfredo le encante darle vuelta a las cosas para que al final
> su enorme ego de desarrollador nos asombre a todos con su sapiencia y
> valentia contra el sistema. Pero este ejemplo lo dí en el contexto de
> rebatir que los cambios vitales no siempre son cuestión de voluntad, no es

> suficiente con *"despertarse"*. Si fuera así, estariamos todos con Alberto

> como aprendices en Eden.
>
> El ser humano tiene tendencia a pensar que las cosas son inamovibles. Pero
> la tecnología te puede dejar atrás antes de lo que piensas. Y os puedo dar
> un ejemplo:
> Yo, década de los 90, me hago un experto en multimedia. Obtengo un
> Sobresaliente en la Uned con mención especial. Me paso la década entera
> aprendiendo animación, diseño, 3D, sonido, escritura de guiones y Macromedia
> Director para ser un autor multimedia completo. Y en menos de tres años
> aparecio la Web y me quede siendo un becario carísimo. No fué algo que se
> venia venir. Fue una auténtica putada. Mi suerte, que me paso antes de los
> treinta y tuve el tiempo de darle la vuelta y de reorientar mi carrera más
> hacia la gestión, sin dejar de picar nunca, para que la tecnología no me
> volviera a dejar con el culo al aire.
>
> ¿Alguno se atreve a poner la mano en el fuego que en 10 años POO o Java no
> sean un callejón sin salida tecnológico? No lo hagais... la tecnología
> cambia a una velocidad de vértigo. Y es como el clima, es muy facil decir lo
> que abria que haber echo una vez pasado.
>
> --
> Un saludo
> Juan Quijano
>

> Blog de .Net y Gestión de proyectos <http://1poquitodtodo.blogspot.com/>
> Blog de opinión social <http://unmalnacido.blogspot.com/>
> Blog de World of Warcraft <http://historiasdesdeazeroth.blogspot.com/>
> Blog de Tiro con Arco <http://litelllon.blogspot.com/>

[Jesús Jiménez]

El 20 de enero de 2011 19:35, Juan Carlos Quijano Abad <juancarl...@gmail.com> escribió:

¿Alguno se atreve a poner la mano en el fuego que en 10 años POO o Java no sean un callejón sin salida tecnológico? No lo hagais... la tecnología cambia a una velocidad de vértigo. Y es como el clima, es muy facil decir lo que abria que haber echo una vez pasado.

Justo de esta incertidumbre es de lo que hablo. Como no se que va a pasar dentro de 10 años, ni dentro de 2, ya estoy jugando en casa con Ruby on Rails, lenguaje con el que espero hacer alguna aplicación y cosas así, de cara a que si mañana Java deja de molar, yo tengo un respaldo importante de que conozco otras cosas. Y lo próximo que me plantee sea trabajar con lenguajes funcionales. Y entre medias de todo eso, me trato de formar en cosas generales del desarrollo. Y no es que yo también este sacando el ego como el malo malísimo Alfredo, sino que como no quiero encontrarme con 50 años y que de repente (que nunca es tan de repente, pero bueno...) lo que vengo usando durante 20 años ya no valga, pues me voy formando en otras cosas por dos motivos: por diversión y "por si acaso". Precisamente lo que trato es de no decir que habría hecho una vez pasado, sino que lo hago ahora por si acaso!

[Alfredo Casado]

¿Darle la vuelta a que?, si digo lo mismo todo el rato. bueno da igual, cada uno que saque sus conclusiones, no voy a discutir contigo más que tengo el ego cansao ya.

[Pablo Escribano]

... mi respuesta a esto ... es la siguiente tenemos que hacernos empresarios, porque de manejar dinero nadie se queda obsoleto.

Pablo

Este mensaje y sus anexos son confidenciales. No podrá ser revelado ni utilizado por nadie que no sea el destinatario. Si lo recibiera por error, por favor avise al remitente, y destruya el mensaje inmediatamente. Gracias.

This message and its attachments are confidential. If you have received it in error, please notify us  and destroy this message inmediately. You must not copy, distribute or take any action in reliance on it. Thank you.

[Joaquín Engelmo Moriche]

Buenas a todos! :)

Voy a aprovechar un descanso largo entre pomodoros para dar mi opinión sobre lo que acabo de leer... a veces asustáis, en serio, como nos desviamos del tema ;) Si el motivo del hilo era hacer la traducción (sí, también la discusión pero ahí Beas podría haberse ahorrado eso, lo hacemos "por defecto" xD) no he vuelto a ver eso en casi nada de las conversaciones (traducciones de frases sueltas para interpretarlas no era el objetivo... a mi entender). Quería dar las gracias a Miguel Ángel por llevar a cabo el propósito principal y ponerlo en su blog ;)

Vamos a la segunda parte opcional, discusión. Los sindicalistas del teclado al poder! :P No tanto... pero tenemos (me incluyo) un ego cojonudo cuando *nos tocan los códigos*. Creo que el artículo deja bastante bien claro "que no es" el concepto/movimiento de "artesanía del software" para que sigamos dándole todas las vueltas posibles. Ahora, ¿es tan bueno como dicen? ¿se puede lograr en el "mundo real" (ni que fuera Matrix, de verdad, tenemos un problema)? ¿a que huele lo que no huele? Un código cojonudo mola y que cumpla con las funcionalidades que pide/necesita el cliente es un logro brutal. ¿Ambas son condiciones necesarias para desarrollar software? Todos sabemos que no, que basta con, más o menos, lo segundo. ¿Por qué? A veces, como soy así de "curioso", miro el interior de las cosas, por ejemplo, "que forro más chulo tiene esa chaqueta" y mis amigos me dicen: "siempre igual, si lo de dentro no se ve!!" ... tengo la sensación que con el software es lo mismo, es una chaqueta, funciona para lo que funciona una chaqueta, ¿quién c... se fija en el forro de dentro? Es posible que si el forro es de mala calidad se rompa antes o tenga "filtraciones" por las cuáles se cuela la lluvia o el frío... pues eso, no voy a seguir explicando el símil ;)

Quién quiera ofrecer software (voy a dar por hecho que cumple las funcionalidades del cliente) con un forro "menos bueno" que otro, genial, si con eso tiene lo que necesita... que luego se lo llevan 5 veces en un año para coser alguna costura suelta, pues se cobra, total, el cliente no entiende de forros :) Quién quiera, como me gustaría a mi algún día, ofrecer software con un forro de alta calidad pues igual de genial que el anterior, ni más ni menos, cada uno es feliz a su manera. ¿Quién te evalúa como profesional? Entre nosotros podemos decir: "ese código podría estar mejor" pero el cliente dirá: "para mi este tío es un profesional, tengo un software que hace lo que quiero".

Simplemente... a modo de contra refrán: "el interior mola pero lo que al final se valora por quién paga es el exterior" :P (cómo la vida misma)

Ahí queó! :)

El 20 de enero de 2011 10:40, Roberto Vázquez González <rober...@gmail.com> escribió:

Muchas gracias por tu trabajo Miguel Ángel

--

[jorge]

Tiene algo que ver eso del forro con lo de la obsolescencia programada? ;)

>> agile-spain...@googlegroups.com<agile-spain%2Bunsu...@googlegroups.com>

[Harald Messemer]

Me gusta de resumen :-) igualmente quisiera dar un vuelta sobre el forro.

En mi opinion la calidad / prestaciones que no se ven a la primera
tambien muchas veces, aunque no siempre, son requerimientos del
cliente que corresponden a una necesidad. Si no corresponden a una
necesidad / requerimiento no deben programarse.

Es decir, si mi necesidad es una chaqueta para trabajar en taller de
coches como mecanico en el mediterraneo, no necesito un forro de seda,
ni termico. Si necesito un formulario de un solo uso, talvez no
necesito una arquitectura para crear familias de formularios.

Saludos,
Harald

2011/1/21, Joaquín Engelmo Moriche <kiniso...@gmail.com>:

>> agile-spain...@googlegroups.com<agile-spain%2Bunsu...@googlegroups.com>

>> Para tener acceso a más opciones, visita el grupo en
>> http://groups.google.com/group/agile-spain?hl=es.
>>
>
> --
> Has recibido este mensaje porque estás suscrito al grupo "agile-spain" de
> Grupos de Google.
> Para publicar una entrada en este grupo, envía un correo electrónico a
> agile...@googlegroups.com.
> Para anular tu suscripción a este grupo, envía un correo electrónico a
> agile-spain...@googlegroups.com
> Para tener acceso a más opciones, visita el grupo en
> http://groups.google.com/group/agile-spain?hl=es.
>
>

--
Gesendet von meinem Mobilgerät

[Edu Rodríguez]

> Si necesito un formulario de un solo uso, talvez no
> necesito una arquitectura para crear familias de formularios.

No, pero necesitas garantizar un mínimo de calidad. Ni más, ni menos que la adecuada. Más que nada para que el día que lo usen, funcione. Creo que el movimiento este ya deja bien clara cual es la postura a tomar ante la sobreingeniería.

Esto ya no va por tu mensaje:

También entiendo que para que alguien nos mire como a un profesional y piense que hemos hecho un trabajo de "calidad" se deben cumplir las siguientes:

• Hay que dar solución a los problemas del cliente.
• Hay que cumplir planificaciones.
• Hay que garantizar un mínimo de calidad.
• Hay que satisfacer las necesidades "cambiantes" del negocio.

Si tu código fuente no está diseñado para garantizar que se cumplan estas cosas y asegurado, para evitar que un manazas (yo mismo) lo rompa. Poco éxito auguro a tu proyecto software. Aunque sea un único formulario.

Si esperas a que el cliente te pida que tu código fuente esté bien diseñado y asegurado para comenzar a hacerlo, vas listo evaristo :-)

Si esperas a que te lo diga un directivo de tu empresa, tu gerente o cualquier persona por encima de un puesto de J.P y casi que ni esos, vas listo evaristo :-)

Luego quien se queda sí o sí a arreglar todo lo que falla, somos nosotros.

Cada cual verá lo que hace con su vida.

Un saludo

2011/1/21 Harald Messemer <harr...@gmail.com>

--
Edu