Entradas

Mostrando las entradas de julio, 2007
Etapas “reales” de un proyecto… July 30th, 2007 | Curiosidades A veces todos esos cursos y seminarios de métodos organizacionales, sirven para dos cosas… 1. Optimismo inicial 2. Fase de desorientación 3. Desconcierto generalizado 4. Período de desorden incontrolable 5. Búsqueda implacable de culpables 6. Sálvese el que pueda 7. Castigo ejemplar a los inocentes 8. Recuperación del optimismo perdido 9. Finalización inexplicable del proyecto 10. Condecoraciones y premios a los no participantes tomado de: http://www.regioblogs.com/2007/07/30/etapas-reales-de-un-proyecto/
Quiero un trabajo” Esa es, literalmente, la búsqueda que ha traído aquí a alguien hace un rato. Supongo que no habrá encontrado nada demasiado relevante… pero a mí me va a dar pie a una reflexión. Mentira. El que escribió eso en Google, miente. O al menos, no dice toda la verdad. Estoy seguro de que no quiere “un trabajo”. Querrá “un trabajo en el que se gane mucho, se trabaje poco, no sea incómodo ni me exija demasiado esfuerzo o preparación”. Porque trabajo hay. Lo hay en España, y seguro que también en Alemania. El otro día, cortándome el pelo en mi peluquería habitual (cerca del trabajo; así aprovecho el ratito de mediodía porque no cierran), comenté con el dueño que habían quitado el cartel de “Se busca oficial de peluquería” que había puesto unos meses antes. Me dijo que sí. Pero no porque hubiese encontrado a alguien, sino por lo contrario: había desistido viendo la gente que durante meses se había presentado. Gente sin preparación suficiente, gente impuntual, gente qu...
Humor de fin de semana y fallas Como todo no han de ser sesudos análisis, voy a poneros un poco de humor del bueno... ¿Es verdad eso de que las mascotas se parecen a sus dueños? Estaban cinco hombres alardeando sobre la inteligencia de sus perros. El primero era ingeniero, el segundo era contable, el tercero era químico, el cuarto era informático y el quinto, funcionario. Comienzan las demostraciones y el ingeniero llama a su perro: - Escuadra, haz lo que sabes. Escuadra saltó hasta la mesa tomó un papel y un lápiz y rápidamente dibujo un círculo, un cuadrado y un triángulo. El contable dijo que su perro podía hacer algo mejor, llamó a su perro y le ordenó: - Diario haz lo tuyo. Diario fue hasta la cocina y volvió con una docena de galletas, las dividió en cuatro montones de tres galletas cada una. Todos admitieron que eso era genial, pero el químico dijo que su perro podía hacer algo mejor. - Probeta hazlo. Probet...
It's Not About Lines of Code By Charles Connell Everyone wants programmers to be productive. Managers of programmers want maximum productivity -- it gets the work done faster and makes the managers look good. All other things being equal, programmers like being productive. They can get home earlier, reduce stress during the workday, and feel better about their finished products. Programming productivity is even in each country's national interest, since it advances the country's position in the worldwide software industry. Unfortunately, the standard definitions of software productivity are incorrect. They miss the essence of software development. This article examines some of the usual definitions for programmer productivity, shows why they are wrong, and then proposes an alternate definition that accurately captures what programming is really about. Lines of code per day -- This is the classic definition of software productivity for individual programmers. Unf...
Imagen
Hace tiempo ya, oí hablar sobre el libro The Mytical Man-Month , de Frederick P. Brooks, donde se asegura que los mejores programadores rinden hasta 28 veces más que los que se encuentran en el lado opuesto, los peores. Otras fuentes, si bien no llegan a estos extremos, introducen relaciones hasta de diez a uno en cuanto a la diferencia de productividad de estos profesionales. Sin duda, la productividad en el desarrollo es algo más que tirar muchas líneas de código por día ; ya lo comenta Charles Connell en su artículo It's not about lines of code , donde explica por qué la productividad no puede ser medida en esos términos, de hecho, ¿muchas líneas de código implican un trabajo bien hecho? ¿y si se trata de un nido de bugs ? Así, a lo largo de su artículo, Charles va definiendo y añadiendo características que debería presentar el código creado hasta llegar a una posible unidad de medida de la productividad, líneas de código limpio, simple, correcto y bien documentado por día , par...
Venciendo el síndrome de la Reina Roja . Por jaimeglz Nadie es capaz de leer, entender y aplicar a corto plazo esta pavorosa masa de conocimientos y buenas prácticas. Me he topado varias veces con la metáfora de la Reina Roja, de la obra Through the Looking-Glass , de Lewis Caroll (misma que no he leído pero, por lo que puedo apreciar, es algo así como un objeto de culto en el ambiente de los matemáticos y de los estudiosos de la lógica formal). Pido me disculpen por no contar con el texto original, pero lo que entendí de esta metáfora es que, en una carrera organizada por la Reina Roja, Alicia se percata que no puede avanzar, no importa que tan rápido esté corriendo. La reina le explica: “Aquí tienes que correr todo lo que puedas, simplemente para mantenerte en donde estás. Si quieres llegar a algún lado, ¡tienes que correr dos veces más rápido!”. Y, bueno, ahí nos tienen a sus seguros servidores dirigiendo...
Imagen
How will Sun bounce back? Sun's pumped out some exciting news lately... Project Blackbox is the coolest thing ever, their financial picture continues to improve (less loss is the new profit), and they finally FINALLY open-sourced Java . The new(ish) CEO Jonathan Schwartz is making good things happen at the top. But if Sun is really going to pull this off, they need more than strategic decisions, hot products, and new technologies. Focusing on the top of the org chart won't work unless the bottom gets just as much attention. Maybe more . Why is it that so often the employees who have the most direct human-to-human customer contact are the ones who get the least respect? Customer service is managed by someone, but you rarely catch a manager answering a customer call. Customer education is managed by someone, but you won't catch a manager training a customer. This doesn't apply particularly to Sun of course--I'm just picking on them because I was--and st...
No somos recursos Somos personas. Algo que parece obvio, pero que desgraciadamente se olvida enseguida. Y como personas que somos, queremos exactamente lo mismo que quiere todo el mundo: algo de respeto por nuestra persona, por nuestro trabajo, sentir que aprendemos algo, sentir que nuestro trabajo se valora un poco. Si muchos departamentos de recursos humanos pasaran algo del tiempo que dedican a cuadrar Projects imposibles de cumplir preocupándose por hacer sentir a los machacas que su trabajo se valora, todos saldríamos ganando. Empezando por ellos, que son los que al final facturan lo que nosotros, los recursos, hacemos. http://www.design-nation.net/es/archivos/003801.php
Principio de Pareto De Wikipedia, la enciclopedia libre El Principio de Pareto es también conocido como la regla del 80:20 y recibe este nombre en honor a Vilfredo Pareto , quien lo enunció por primera vez. Descripción Pareto observó que la gente en su sociedad se dividía naturalmente entre los «pocos de mucho» y los «muchos de poco», dividiéndose así en dos grupos de proporciones 80:20 tales que uno el grupo minoritario, formado por un 20% de población, ostentaba el 80% de algo y el grupo mayoritario, formado por un 80% de población, el 20% de algo. Estas cifras son meramente descriptivas, no siendo exactas y pudiendo variar. Su aplicación reside en la descripción de un fenómeno y como tal son aproximadas y ligeramente adaptables a cada caso particular. El principio de Pareto se ha aplicado con éxito a los ámbitos de la política y la economía. Se describió cómo una población de aproximadamente el 20% ostentaba el 80% del poder político y la abundanc...
72 acrónimos para entender de que habla un Geek Como geeks cuantas veces te has encontrado gente a la que le empiezas a contar cosas de lo que haces o en lo que trabajas y se te quedan con una cara de “bobos” al no saber que significan esas palabrejas que estás soltando . En casa estoy sindicando los FEEDS ya que los RSS de CSS generados dinámicamente con ROR validan con W3C y me ayudan a mejorar para la WAI…. La verdad es que visto así, puede marear a cualquiera. Marcado y diseño CSS : Cascading Style Sheets — CSS es un lenguaje usado para modificar el aspecto de la estructura HTML DHTML : Dynamic HyperText Markup Language — DHTML es un término usado para referirse a la conjunción de HTML + Javascript + CSS HTML : HyperText Markup Language — HTML es un lenguaje de marcado de tags que componen todas las páginas web de Internet WML : Wireless Markup Language — WML es similar a HTML, basado en XML y orientado para telefonos móviles. X...
30 Oportunidades de mejora comunes en el Desarrollo de Software Top 30 oportunidades de mejora en del desarrollo de software El desarrollo del software se ha crecido grandemente desde los días de los binarios, de COBOL, etc. Todavía me fascina, sin embargo generalmente se cae en las mismas equivocaciones incurridas antes. Debajo están las top 30 en que se incurre dentro del proceso del desarrollo del software. Es asombroso ver que ningunos de éstos tienen nada que ver con el lenguaje en sí. No entender las necesidades del usuario. Carencia de información del usuario, o ni siquiera preguntar. Subestimar del tamaño del proyecto. Apresurar la etapa de planeamiento, o evitar el planeamiento. ¡Codear primero, planear más adelante! ¡MALO! ¡No probar suficientemente pronto, a menudo, o nunca! ¡Hazte el hábito! El elegir una "nueva y mejorada metodología" al comenzar, en vez de una que ya hayas trabajado en el pasado. No usar una metodología. Dejar a un desarrollador realizar...
Imagen
Yo he visto unos pocos Vía Menéame leo un artículo muy acertado de Enrique Dans ¿Alguien ha visto un programador? . Lo comenté muchas veces en este blog, pero para dar unas respuestas muy escuetas a lo que creo son algunos de los problemas: Las empresas grandes que pueden pagar bien a los buenos programadores tienen obsoletas estructuras piramidales que lo único que logran es quemar a los buenos programadores en menos de un año. Las puntas de esas pirámides suelen ser aquellos que no quieren saber nada de programación y se dedican a ascender, delegando toda responsabilidad a los “analistas senior”, que a su vez delegan y culpan a los “analistas junior” y así abajo en la cadena hasta llegar al buen programador que está a punto de dejar porque ya está quemado. Empresas grandes que venden carne de ingenieros al kilogramo pagando salarios de becarios y haciendo verdaderas chapuzas porque al final nadie es el responsable. ¿Alguien recuerda al web del Congreso y tantas otras administracio...
¿Alguien ha visto un programador? ¿Qué es un programador? Según el Diccionario de la RAE , no demasiado prolijo en detalles, un programador es una "persona que elabora programas de ordenador". Si acudimos a un medio con una definición algo más elaborada, como la Wikipedia , nos veremos que un programador es alguien que "se encarga de la implementación de algoritmos mediante un lenguaje de programación que pueda entender un ordenador", una categoría profesional que tradicionalmente se dividía en analistas, capaces de analizar un problema y describirlo con el propósito de ser solucionado mediante un sistema de información, y programadores propiamente dichos, un trabajo mecánico y de baja cualificación que consistía en trasladar las especificaciones del analista recogidas en un cuaderno de carga en código ejecutable por la computadora. Sin embargo, como bien continúa el artículo de la Wikipedia, hoy la concepción original del programador ha desaparecido, siendo sustit...