{"id":133,"date":"2008-12-03T21:18:20","date_gmt":"2008-12-03T19:18:20","guid":{"rendered":"https:\/\/blogs.ua.es\/especialistajava\/?p=133"},"modified":"2008-12-04T17:18:51","modified_gmt":"2008-12-04T15:18:51","slug":"una-filosofia-pragmatica","status":"publish","type":"post","link":"https:\/\/blogs.ua.es\/especialistajava\/2008\/12\/03\/una-filosofia-pragmatica\/","title":{"rendered":"Una Filosof\u00eda Pragm\u00e1tica"},"content":{"rendered":"<p lang=\"es-ES\">Me encanta el modo en que empieza el cap\u00edtulo. Ser un programador pragm\u00e1tico es una actitud, un estilo, un filosof\u00eda a la hora de enfocar los problemas y sus soluciones. Consiste en pensar m\u00e1s all\u00e1 del problema inmediato, siempre intentando situar el problema en su contexto global, siempre intentando ser conscientes del todo (<em>bigger picture<\/em>).<\/p>\n<p lang=\"es-ES\">Y qu\u00e9 decir del t\u00edtulo del primer apartado: <strong>El Gato Se Comi\u00f3 El C\u00f3digo Fuente<\/strong> \ud83d\ude42 Parece la excusa de un ni\u00f1o de primaria cuando le piden los deberes en clase.<\/p>\n<p lang=\"es-ES\">Un programador pragm\u00e1tico se equivoca, como todos los programadores, pero reconoce sus errores sin excusas. No tiene miedo ni verg\u00fcenza de admitir los errores o el desconocimiento. Las cosas siempre terminan, en alg\u00fan momento, por ir mal. Las entregas se retrasan, aparecen problemas t\u00e9cnicos inesperados, \u2026 y en ese momento, aparece la grandeza del programador pragm\u00e1tico que de una manera honesta y directa, reconoce su parte de culpa.<\/p>\n<h3>Tip 3: Ofrece Soluciones, No Des Excusas Baratas (<em>Provide Options, Don&#8217;t Make Lame Excuses<\/em>)<\/h3>\n<p lang=\"es-ES\">Y antes de dar excusas, m\u00edrate a un espejo, y date a ti mismo las mismas excusas \u00bftienen alg\u00fan sentido? \u00bfte sirven de algo? \u00bfvan a arreglar o mejorar algo? Pues entonces ah\u00f3rratelas, y busca soluciones. Quiz\u00e1s el uso de prototipos, la refactorizaci\u00f3n, una mayor cobertura de pruebas, etc .. habr\u00edan evitado el problema.<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"alignright\" src=\"http:\/\/www.codinghorror.com\/blog\/images\/broken_windows.jpg\" alt=\"Ventanas Rotas\" width=\"280\" height=\"210\" \/><\/p>\n<p lang=\"es-ES\">El segundo apartado, <strong>Entrop\u00eda del Software<\/strong>, relata una de las historias m\u00e1s conocidas de este libro. La entrop\u00eda se relaciona con el orden dentro del caos, y m\u00e1s directamente, se define como la cantidad de desorden de un sistema. Esto siempre me recuerda a mi escritorio f\u00edsico (no virtual), cuando viv\u00eda con mis padres. Mi madre dec\u00eda que mi escritorio era un caos, pero yo sabia donde estaba todo. Si extrapolamos mi escritorio al software, hemos de tener nuestro c\u00f3digo ordenado, saber donde est\u00e1 todo, y evitar que nuestro software se pudra. Para evitar que nuestro c\u00f3digo huela mal y se deteriore poco a poco, requiere de un cuidado continuo para evitar la tendencia al desorden.<\/p>\n<h3>Tip 4: No Vivas Con Ventanas Rotas (<em>Don&#8217;t Live with Broken Windows<\/em>)<\/h3>\n<p lang=\"es-ES\">Mediante esta moraleja, los autores comparan una aplicaci\u00f3n con un edificio, en tanto que cuando un edificio, estando deshabitado pero manteniendo una apariencia visual agradable, se mantiene en buen estado. En cuanto se rompe una ventana, y aparecen pintadas, en poco tiempo, todo el edificio se deteriora, se rompen todas las ventanas, y pasa de estar deshabitado a abandonado.<\/p>\n<p lang=\"es-ES\">\u00bfQu\u00e9 tenemos que hacer nosotros como programadores pragm\u00e1ticos? Cuando se rompe una ventana (una funcionalidad) de nuestra aplicaci\u00f3n, tenemos que arreglarla. Seguro que alguna vez has visto alg\u00fan <em>bug<\/em> en la aplicaci\u00f3n que est\u00e1s desarrollando, pero por no tocar, o no perder el tiempo, o porque no lo has provocado t\u00fa, no te has parado a arreglarlo. Mal. Muy mal. No hay nada peor que mirar hacia el otro lado. Ese no es el camino.<\/p>\n<p lang=\"es-ES\">Puedes pensar que ya vendr\u00e1 alguien y lo arreglar\u00e1, pero si todos pensamos as\u00ed, el fallo estar\u00e1 ah\u00ed siempre. \u00bfY qu\u00e9 decir de una aplicaci\u00f3n que constantemente falla? No apetece nada ponerse a arreglarla, m\u00e1s cuando todo el c\u00f3digo es un caos, no hay dos lineas iguales, diferente nomenclatura, sin convenciones de c\u00f3digo. Para evitar una aplicaci\u00f3n con todas la ventanas rotas, hay que mantenerlas limpias desde el principio. Lo que no se ensucia, no hace falta limpiarlo. Dicho de otro, quien no mancha, no tiene que limpiar. \u00bfEst\u00e1 claro? Pues entonces desde un principio, vamos a ser limpios y cuidadosos con nuestro c\u00f3digo. Sin chapuzas ni trozos de c\u00f3digo para salir al paso. Siempre con la mejor soluci\u00f3n. Al menos, la mejor soluci\u00f3n que nosotros conocemos.<\/p>\n<p lang=\"es-ES\">El tercer apartado, <strong>Sopa de Piedras y Sapos Hervidos<\/strong>, comienza con un cuento muy bonito sobre unos soldados hambrientos que llegan a un poblado donde los aldeanos tambi\u00e9n pasan hambre y son reacios a abrirles la puerta para darles de comer, pero los soldados son muy listos, y se aprovechan de la curiosidad de los aldeanos para obtener a partir de una sopa de piedras un poco de su preciado alimento. A partir de lo que aporta cada aldeano, consiguen crear una sopa \u201crica, rica\u201d. Moraleja: la uni\u00f3n hace la fuerza. Es m\u00e1s, estos aldeanos no sab\u00edan que si un\u00edan sus recursos a los de sus vecinos, iban a mejorar, tanto ellos mismos como personas c\u00f3mo sus recursos (el producto final).<\/p>\n<h3>Tip 5: S\u00e9 El Catalizador del Cambio (<em>Be a Catalyst for Change<\/em>)<\/h3>\n<p lang=\"es-ES\">Nosotros como pragm\u00e1ticos que somos, tenemos que ver la necesidad de dar ese empuj\u00f3n a nuestros compa\u00f1eros para mejorar. \u00bfCuantas veces te has dicho \u201cque mal se hacen las cosas en esta empresa\u201d, y no has hecho nada para arreglarlo? Pues si has sido capaz de darte cuenta que hab\u00eda algo mal, tambi\u00e9n ser\u00e1s capaz de encontrar la soluci\u00f3n. Y una vez tengas la soluci\u00f3n, dif\u00fandela, prop\u00e1gala dentro de la empresa, haz participe a todos los que te rodean, para que la soluci\u00f3n se haga realidad.<\/p>\n<p lang=\"es-ES\">La segunda mitad de la moraleja se centra en como los soldados enga\u00f1an a los aldeanos. El truco de las piedras hace que los aldeanos se centren en lo que est\u00e1n haciendo los soldados, y no en lo que \u00e9stos quieres conseguir.<\/p>\n<h3>Tip 6: Recuerda el Todo (<em>Remeber the Big Picture<\/em>)<\/h3>\n<p lang=\"es-ES\">Si solo nos fijamos en lo que hacemos ahora, en nuestra peque\u00f1a parcela, el todo, la aplicaci\u00f3n entera, va a ir creciendo y deterior\u00e1ndose poco a poco, normalmente en los puntos de uni\u00f3n de nuestras parcelas con las de nuestros vecinos m\u00e1s cercanos.<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"alignright\" src=\"http:\/\/blogs.ideal.es\/blogfiles\/cambioclimatico\/FAQ-boiled-frog-syndrome_01.gif\" alt=\"Recuerda el Todo\" width=\"156\" height=\"188\" \/><\/p>\n<p lang=\"es-ES\">Mediante la historia del sapo hervido se transmite la idea de que cuando los cambios llegan poco a poco, nadie se da cuenta, y al final, un gran <span style=\"text-decoration: none\">c\u00famulo<\/span> de peque\u00f1os fallos hace un gran fallo irreversible. No seas sapo, y ten un ojo siempre en lo que sucede a tu alrededor.<\/p>\n<p lang=\"es-ES\">El cuarto apartado, <strong>Software Suficientemente Bueno<\/strong>, comienza con la utop\u00eda de los chips. Ojala al desarrollar software pudi\u00e9semos saber de antemano los errores que tiene una aplicaci\u00f3n. Como no somos capaces, lo \u00fanico que podemos hacer es un software lo suficientemente bueno, desde el punto de vista del cliente, algo que resuelva los requisitos y que sea mantenible. Por esto, cuando se definen los requisitos de un proyecto, adem\u00e1s de los requisitos funcionales, se debe definir la calidad y el alcance del proyecto.<\/p>\n<h3>Tip 7: Haz de la Calidad un Requisito (<em>Make Quality a Requirements Issue<\/em>)<\/h3>\n<p lang=\"es-ES\">Y este no es un tip, pero qu\u00e9 gran frase: \u201cUn buen software hoy es mejor que un software perfecto ma\u00f1ana\u201d. La temprana retroalimentaci\u00f3n del software mejora nuestra aplicaci\u00f3n, y por esto, es mejor que vayamos haciendo entregas desde el principio, entregas evolutivas que van a implementar de forma creciente los requisitos del proyecto, y permitir\u00e1 pulir los requisitos ya implementados.<\/p>\n<p lang=\"es-ES\">Continuando con lo de suficientemente bueno, no hay que quedarse corto, ni pasarse de largo. Ni mucho ni poco. El software es suficientemente bueno cuando no tenemos que hacer nada m\u00e1s y no nos falta nada por hacer. Hay que saber cuando parar, porque la sobreingenier\u00eda cuesta, recursos temporales y econ\u00f3micos.<\/p>\n<p lang=\"es-ES\">En estos tiempos de crisis, quiero resaltar la entradilla del quinto apartado, <strong>Tu Portafolio de Conocimiento<\/strong>, la frase de <em>Benjamin Franklin<\/em>, que dice as\u00ed: \u201cUna inversi\u00f3n en conocimiento siempre devenga los mejores intereses\u201d. Aquello que nos define como profesionales es nuestro conocimiento y nuestra experiencia.<\/p>\n<p lang=\"es-ES\">El problema con el conocimiento, aparte de lo que cuesta adquirirlo, es que caduca. Las tecnolog\u00edas avanzan a ritmos vertiginosos. No paran de aparecer nuevos lenguajes, nuevas librer\u00edas, APIs, sistemas de comunicaci\u00f3n, etc&#8230; Tenemos que adquirir conocimiento y renovar el que tenemos de una forma constante.<\/p>\n<h3>Tip 8: Invierte Regularmente en tu Portafolio de Conocimiento (<em>Invest Regularly in Your Knowledge Portfolio<\/em>)<\/h3>\n<p lang=\"es-ES\">Para invertir en nuestro portafolio (s\u00edmil financiero) de conocimiento, debemos invertir regularmente (coger un h\u00e1bito de estudio, lectura), diversificar (cuantas m\u00e1s cosas diferentes sepamos, m\u00e1s valiosos somos), gestionar los riesgos (si solo centramos nuestro conocimiento en una sola tecnolog\u00eda, si \u00e9sta se va a pique, nosotros seguiremos su camino), comprar barato y vender caro (aprender tecnolog\u00edas emergentes puede darnos gran ventaja competitiva) y revisar y hacer balance (mirar la vista atr\u00e1s, revisar lo que sabemos , preguntarnos si deber\u00edamos reciclarnos, \u2026).<\/p>\n<p lang=\"es-ES\">Comprar barato y vender caro. \u00bfQu\u00e9 crees que deber\u00edas aprender ahora para poder ser m\u00e1s competitivo en el mercado, es decir, optar a un puesto de trabajo bien remunerado? \u00bfJavaEE? \u00bfAlg\u00fan lenguaje de scripting (Ruby\/Groovy) con su framework web (Rails\/Grails)? \u00bfQuiz\u00e1s .Net?<\/p>\n<p lang=\"es-ES\">Lo que est\u00e1 claro, es que no tenemos que parar de aprender, de reciclarnos. Una vez nos veamos c\u00f3modos en un campo, saltar. Otra tecnolog\u00eda, otro lenguaje, \u2026<\/p>\n<p lang=\"es-ES\">Y que hay de las oportunidades de aprender. El libro comenta el reto que supone cuando alguien recurre a ti, porque se supone que eres experto (o tienes un nivel aceptable) sobre alguna tecnolog\u00eda,  y te hace una pregunta que nos sabes responder. Acaba de lanzarte un reto que no debes rechazar. Busca la respuesta, apoyate en tu guru personal (ese compa\u00f1ero de trabajo, alg\u00fan ex-compa\u00f1ero de otra empresa, amigo de estudios, etc..), busca en la biblioteca, Internet, haz lo que sea, pero encuentra la respuesta. As\u00ed conseguimos que nuestro portafolio crezca.<\/p>\n<p lang=\"es-ES\">Y luego est\u00e1n los foros, los RSS, los libros tecnol\u00f3gicos, y si nos parece poco, hay multitud de sitios que nos plantean art\u00edculos de los que podemos aprender. \u00bf Y cuando leerlos ? Hay quien prefiere irse de la oficina 30 minutos m\u00e1s tarde para dedicarse a leer, o bien despu\u00e9s de comer. Hay quien prefiere escribir en papel, y aprovecha los viajes en autob\u00fas, metro, las visitas al dentista\/m\u00e9dico de cabecera, etc&#8230; Lo que esta claro es que tienes que buscarte tus huecos para leer.<\/p>\n<p lang=\"es-ES\">Vale, ya tenemos tiempo para leer, y estoy leyendo. Pero \u00bfvale la pena lo que estoy leyendo? La informaci\u00f3n de la que dispongo, \u00bfes objetiva? Hay que tener mucho cuidado con el marketing. Que un libro aparezca en Internet no significa que sea bueno, del mismo modo, que si un articulo dice que el mejor producto es X, posiblemente sea porque el art\u00edculo lo ha escrito el creador de X.<\/p>\n<h3>Tip 9: Analiza Cr\u00edticamente Lo Que Lees y Escuchas (<em>Critically Analyze What You Read and Hear<\/em>)<\/h3>\n<p lang=\"es-ES\">Conforme uno adquiere m\u00e1s conocimiento, tenemos mayor capacidad de an\u00e1lisis, y sabremos si lo que leemos y escuchamos es verdad o una verdad a medias. Adem\u00e1s, el hecho de dudar de lo que estamos leyendo, buscarle las tres patas al gato, esa pregunta \u201cpu\u00f1etera\u201d que nadie se atreve a hacer pero a ti se te ocurre, \u2026 todo esto mejora la calidad de nuestro conocimiento.<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"alignright\" src=\"http:\/\/www.cals.ncsu.edu\/course\/ent425\/tutorial\/Communication\/communicate.gif\" alt=\"Comunicate\" width=\"254\" height=\"139\" \/><\/p>\n<p lang=\"es-ES\">El sexto y \u00faltimo apartado, <strong>Comun\u00edcate<\/strong>, se plantea la idea de que como todo el idea nos estamos comunicando, via email, foros, documentos, c\u00f3digo fuente, etc&#8230; hemos de hacerlo bien. Para ello tenemos que saber que es lo que queremos decir (\u00bfporque no hacerse un guion de lo que vamos a decir?), conocer a nuestra audiencia (no seamos demasiado t\u00e9cnicos cuando no debemos serlo, ni viceversa), elegir el momento (seguro que cuando erais peque\u00f1o no le pediais dinero a vuestro padre cuando estaba cansado o con hambre, \u00bfverdad?), elegir un estilo (a veces hay que enrollarse, otras veces, cuando m\u00e1s escueto es uno, mejor), darle una buena apariencia (una buena comida mal presentada no es una buena comida, y que hay de esas delicatessen tan bonitas que luego no saben a nada, &#8230;. cuidado con la ortografia), involucra a la audiencia (mediante borradores), escucha (escucha para ser escuchado, pide consejos, pregunta por la opini\u00f3n sobre lo que has comunicado), contesta (si no contestamos a los que nos preguntan\/piden, luego nosotros seremos los ignorados). Y de cosecha propia, hay que predicar con el ejemplo, nada de <em>&#8220;a Dios rogando, y con el mazo dando&#8221;<\/em>.<\/p>\n<h3>Tip 10: Es Tan importante Lo Que Dices Como La Manera En Que Lo Dices (<em>It&#8217;s Both What You Say and The Way You Say It)<\/em><\/h3>\n<p lang=\"es-ES\">Cuanto mejor nos comuniquemos, m\u00e1s influyentes seremos.<\/p>\n<p lang=\"es-ES\">Conforme voy releyendo cada apartado, aparte de la idea que los autores quieren transmitir, observo que hay m\u00faltiples consejos que quedan en el camino, pero son tan importantes como los aqu\u00ed resaltados. Si te has le\u00eddo el cap\u00edtulo, y luego todo este rollo, vuelve a leerte el cap\u00edtulo a ver si consigues obtener nuevas conclusiones. Cu\u00e9ntanoslas. Comun\u00edcate \ud83d\ude42<\/p>\n<p lang=\"es-ES\">Bueno, espero que os haya gustado &#8230; para aquellos que no os habeis leido el cap\u00edtulo, a ver si as\u00ed os pica la curiosidad. El segundo cap\u00edtulo es un poco m\u00e1s extenso, asi que volver\u00e9 despues de las navidades. Feliz 2009 \ud83d\ude42<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Me encanta el modo en que empieza el cap\u00edtulo. Ser un programador pragm\u00e1tico es una actitud, un estilo, un filosof\u00eda a la hora de enfocar los problemas y sus soluciones. Consiste en pensar m\u00e1s all\u00e1 del problema inmediato, siempre intentando &hellip; <a href=\"https:\/\/blogs.ua.es\/especialistajava\/2008\/12\/03\/una-filosofia-pragmatica\/\">Continue reading <span class=\"meta-nav\">&rarr;<\/span><\/a><\/p>\n","protected":false},"author":903,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[307],"tags":[3954],"class_list":["post-133","post","type-post","status-publish","format-standard","hentry","category-articulos","tag-pragmatic"],"_links":{"self":[{"href":"https:\/\/blogs.ua.es\/especialistajava\/wp-json\/wp\/v2\/posts\/133","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blogs.ua.es\/especialistajava\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blogs.ua.es\/especialistajava\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blogs.ua.es\/especialistajava\/wp-json\/wp\/v2\/users\/903"}],"replies":[{"embeddable":true,"href":"https:\/\/blogs.ua.es\/especialistajava\/wp-json\/wp\/v2\/comments?post=133"}],"version-history":[{"count":24,"href":"https:\/\/blogs.ua.es\/especialistajava\/wp-json\/wp\/v2\/posts\/133\/revisions"}],"predecessor-version":[{"id":156,"href":"https:\/\/blogs.ua.es\/especialistajava\/wp-json\/wp\/v2\/posts\/133\/revisions\/156"}],"wp:attachment":[{"href":"https:\/\/blogs.ua.es\/especialistajava\/wp-json\/wp\/v2\/media?parent=133"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blogs.ua.es\/especialistajava\/wp-json\/wp\/v2\/categories?post=133"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blogs.ua.es\/especialistajava\/wp-json\/wp\/v2\/tags?post=133"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}