Continuando con mi humilde selección de lo más resaltante de Peopleware, aquí esta lo correspondiente a la segunda parte del libro. Revisen también el post anterior.
PART II
Not all work roles require that you attain a state of flow in order to be productive, but for anyone involved in engineering, design, development, writing, or like tasks, flow is a must. These are high-momentum tasks. It's only when you're in flow that the work goes well.
Unfortunately, you can't turn on flow like a switch. It takes a slow descent into the subject, requiring fifteen minutes or more of concentration before the state is locked in. During this immersion period, you are particularly sensitive to noise and interruption. A disruptive environment can make it difficult or impossible to attain flow.
If the average incoming phone call takes five minutes and your reimmersion period is fifteen minutes, the total cost of that call inflow time (work time) lost is twenty minutes. A dozen phone calls use up half a day. A dozen other interruptions and the rest of the work day is gone. This is what guarantees, "You never get anything done around here between 9 and 5."
If you're a manager, you may be relatively unsympathetic to the frustrations of being in no-flow. After all, you do most of your own work in interrupt mode -that's management- but the people who work for you need to get into flow. Anything that keeps them from it will reduce their effectiveness and the satisfaction they take in their work. It will also increase the cost of getting the work done.
What matters is not the amount of time you're present, but the amount of time that you're -working at full potential. An hour in flow really accomplishes something, but ten six-minute work periods sandwiched between eleven interruptions won't accomplish anything.
Management, at its best, should make sure there is enough space, enough quiet, and enough ways to ensure privacy so that people can create their own sensible workspace. Uniformity has no place in this view. You have to grin and bear it when people put up odd pictures or leave their desks a mess or move the furniture around or merge their offices. When they've got it just the way they want it, they'll be able to put it out of their minds entirely and get on with the work.
We are trained to accept windowless office space as inevitable. The company would love for every one of us to have a window, we hear, but that just isn't realistic. Sure it is. There is a perfect proof that sufficient windows can be built into a space without excessive cost. The existence proof is the hotel, any hotel. You can't even imagine being shown a hotel room with no window. You wouldn't stand for it. (And this is for a space you're only going to sleep in.) So hotels are constructed with lots of windows.
Even if there is a higher cost per worker to house people in the more agreeable space, the added expense is likely to make good sense because of the savings it provides in other areas. The real problem is that the cost is in a highly visible category (space and services), while the offsetting advantage is in poorly measured and therefore invisible categories (increased productivity and reduced turnover).
Copyright © 1999, 1987 by Tom DeMarco and Timothy Lister.
lunes, 26 de junio de 2006
martes, 20 de junio de 2006
El auge y la caida de CORBA
Este artículo me parece interesante. Habla de por qué fracasó CORBA como tecnología distribuida. En resumen, según el autor, se debió a graves errores técnicos y políticos (OMG):
The Rise and Fall of CORBA
Como para que los profes de algunos cursos de mi alma mater le den una revisada... no?
The Rise and Fall of CORBA
Como para que los profes de algunos cursos de mi alma mater le den una revisada... no?
martes, 13 de junio de 2006
Peopleware (Parte I)
Este libro es excelente en mi opinión, así que he decidido colocar los extractos que me parecen más resaltantes. Todo programador, desarrollador, líder técnico, funcional, arquitecto o jefe de proyecto debería leerlo. Mejor aún si lo compran. Aquí va lo más resaltante de la primera parte:
PART I
The catalyst is important because the project is always in a state of flux. Someone who can help a project to jell is worth two people who just do work.
The project that has to be done by an impossible fixed date is the very one that can't afford not to have frequent brainstorms and even a project dinner or some such affair to help the individual participants knit into an effective whole.
The statistics about reading are particularly discouraging: The average software developer, for example, doesn't own a single book on the subject of his or her work, and hasn't ever read one. That fact is horrifying for anyone concerned about the quality of work in the field; for folks like us who write books, it is positively tragic.
Productivity ought to mean achieving more in an hour of work, but all too often it has come to mean extracting more for an hour of pay. There is a large difference. The Spanish Theory managers dream of attaining new productivity levels through the simple mechanism of unpaid overtime. They divide whatever work is done in a week by forty hours, not by the eighty or ninety hours that the worker actually put in.
The Eagle project at Data General is a case in point. The project was a Spanish Theory triumph: Workaholic project members put in endless unpaid overtime hours to push productivity to unheard of levels. At the end of the project, virtually the entire development staff quit.
People under time pressure don't work better; they Just work faster. In order to work faster, they may have to sacrifice the quality of the product and their own job satisfaction.
We all tend to tie our self-esteem strongly to the quality of the product we produce, not the quantity of product, but the quality. Any step you take that may jeopardize the quality of the product is likely to set the emotions of your staff directly against you.
Managers jeopardize product quality by setting unreachable deadlines.
The nation (Japan) that is an acknowledged quality leader is also known for its high productivity. The trade-off between price and quality does not exist in Japan. Rather, the idea that high quality brings on cost reduction is widely accepted.
Hewlett-Packard is an example of an organization that reaps the benefits from increased productivity due to high, builder-set quality standards. The company makes a cult of quality. In such an environment, the argument that more time or money is needed to produce a high-quality product is generally not heard. The result is that developers know they are part of a culture that delivers quality beyond what the marketplace requires. Their sense of quality identification works for increased job satisfaction and some of the lowest turnover figures seen anywhere in the industry.
In some Japanese companies, notably Hitachi Software and parts of Fujitsu, the project team has an effective power of veto over delivery of what they believe to be a not-yet-ready product. No matter that the client would be willing to accept even a substandard product, the team can insist that delivery wait until its own standards are achieved. Of course, project managers are under the same pressure there that they are here: They're being pressed to deliver something, anything, right away. But enough of a quality culture has been built up so that these Japanese managers know better than to bully their workers into settling for lower quality.
In a healthy work environment, the reasons that some people don't perform are lack of competence, lack of confidence, and lack of affiliation with others on the project and the project goals. In none of these cases is schedule pressure liable to help very much. When a worker seems unable to perform and seems not to care at all about the quality of his work, for example, it is a sure sign that the poor fellow is overwhelmed by the difficulty of the work. He doesn't need more pressure. What he needs is reassignment, possibly to another company.
"In my early years as a developer, I was privileged to work on a project managed by Sharon Weinberg, now president of the Codd and Date Consulting Group. She was a walking example of much of what I now think of as enlightened management. One snowy day, I dragged myself out of a sick bed to pull together our shaky system for a user demo. Sharon came in and found me propped up at the console. She disappeared and came back a few minutes later with a container of soup. After she'd poured it into me and buoyed up my spirits, I asked her how she found time for such things with all the management work she had to do. She gave me her patented grin and said, Tom, this is management."
Copyright © 1999, 1987 by Tom DeMarco and Timothy Lister.
PART I
The catalyst is important because the project is always in a state of flux. Someone who can help a project to jell is worth two people who just do work.
The project that has to be done by an impossible fixed date is the very one that can't afford not to have frequent brainstorms and even a project dinner or some such affair to help the individual participants knit into an effective whole.
The statistics about reading are particularly discouraging: The average software developer, for example, doesn't own a single book on the subject of his or her work, and hasn't ever read one. That fact is horrifying for anyone concerned about the quality of work in the field; for folks like us who write books, it is positively tragic.
Productivity ought to mean achieving more in an hour of work, but all too often it has come to mean extracting more for an hour of pay. There is a large difference. The Spanish Theory managers dream of attaining new productivity levels through the simple mechanism of unpaid overtime. They divide whatever work is done in a week by forty hours, not by the eighty or ninety hours that the worker actually put in.
The Eagle project at Data General is a case in point. The project was a Spanish Theory triumph: Workaholic project members put in endless unpaid overtime hours to push productivity to unheard of levels. At the end of the project, virtually the entire development staff quit.
People under time pressure don't work better; they Just work faster. In order to work faster, they may have to sacrifice the quality of the product and their own job satisfaction.
We all tend to tie our self-esteem strongly to the quality of the product we produce, not the quantity of product, but the quality. Any step you take that may jeopardize the quality of the product is likely to set the emotions of your staff directly against you.
Managers jeopardize product quality by setting unreachable deadlines.
The nation (Japan) that is an acknowledged quality leader is also known for its high productivity. The trade-off between price and quality does not exist in Japan. Rather, the idea that high quality brings on cost reduction is widely accepted.
Hewlett-Packard is an example of an organization that reaps the benefits from increased productivity due to high, builder-set quality standards. The company makes a cult of quality. In such an environment, the argument that more time or money is needed to produce a high-quality product is generally not heard. The result is that developers know they are part of a culture that delivers quality beyond what the marketplace requires. Their sense of quality identification works for increased job satisfaction and some of the lowest turnover figures seen anywhere in the industry.
In some Japanese companies, notably Hitachi Software and parts of Fujitsu, the project team has an effective power of veto over delivery of what they believe to be a not-yet-ready product. No matter that the client would be willing to accept even a substandard product, the team can insist that delivery wait until its own standards are achieved. Of course, project managers are under the same pressure there that they are here: They're being pressed to deliver something, anything, right away. But enough of a quality culture has been built up so that these Japanese managers know better than to bully their workers into settling for lower quality.
In a healthy work environment, the reasons that some people don't perform are lack of competence, lack of confidence, and lack of affiliation with others on the project and the project goals. In none of these cases is schedule pressure liable to help very much. When a worker seems unable to perform and seems not to care at all about the quality of his work, for example, it is a sure sign that the poor fellow is overwhelmed by the difficulty of the work. He doesn't need more pressure. What he needs is reassignment, possibly to another company.
"In my early years as a developer, I was privileged to work on a project managed by Sharon Weinberg, now president of the Codd and Date Consulting Group. She was a walking example of much of what I now think of as enlightened management. One snowy day, I dragged myself out of a sick bed to pull together our shaky system for a user demo. Sharon came in and found me propped up at the console. She disappeared and came back a few minutes later with a container of soup. After she'd poured it into me and buoyed up my spirits, I asked her how she found time for such things with all the management work she had to do. She gave me her patented grin and said, Tom, this is management."
Copyright © 1999, 1987 by Tom DeMarco and Timothy Lister.
viernes, 9 de junio de 2006
Decisiones... cada dia....
Este texto me parecio un buen resumen de las decisiones que debemos enfrentar cuando desarrollamos aplicaciones Web J2EE (o Java EE). IMHO, tener el poder de decidir es bueno. Es uno de los pilares de la democracia y es una de las razones por las cuales prefiero el modelo open source a la dictadura de Microsof.
Yes, there seems to be nothing but choice when it comes to developing web applications.
To begin with, someone has to choose between ASPX, Java, PHP, Python, Ruby, et al. Once you choose Java, then you have to choose a web container, such as Jetty, Tomcat, Resin, WebLogic, or WebSphere, to name a few. Of course, you also have to build the application that runs in the container, which is where choosing Apache Struts comes in. Then, most teams also use a data access framework. Choices there include Cayenne, iBATIS, Hibernate, JDO, Turbine, and OJB, to name a few.
(Right about now, Ruby's single-stack approach must be sounding pretty good!)
But, wait, there's more! You also have to choose an editor or IDE: Eclipse? IDEA? NetBeans? UltraEdit? Some other? (Many teams decide to use more than one!) And do we use Ant, Maven, or the IDE to build it all?
Lest we forget: Someone also needs to choose a database system (DB2? Derby? Oracle? PostGres? MySQL?), a version control system (CVS? Subversion? Perforce?), a development methodology (eXtreme Programming? RUP? Scrum? Waterfall?), and, if you're lucky, an issue tracker (Bugzilla? JIRA? Scarab?).
Welcome to the jungle!
Tomado de: http://struts.apache.org/roadmap.html#choice
Yes, there seems to be nothing but choice when it comes to developing web applications.
To begin with, someone has to choose between ASPX, Java, PHP, Python, Ruby, et al. Once you choose Java, then you have to choose a web container, such as Jetty, Tomcat, Resin, WebLogic, or WebSphere, to name a few. Of course, you also have to build the application that runs in the container, which is where choosing Apache Struts comes in. Then, most teams also use a data access framework. Choices there include Cayenne, iBATIS, Hibernate, JDO, Turbine, and OJB, to name a few.
(Right about now, Ruby's single-stack approach must be sounding pretty good!)
But, wait, there's more! You also have to choose an editor or IDE: Eclipse? IDEA? NetBeans? UltraEdit? Some other? (Many teams decide to use more than one!) And do we use Ant, Maven, or the IDE to build it all?
Lest we forget: Someone also needs to choose a database system (DB2? Derby? Oracle? PostGres? MySQL?), a version control system (CVS? Subversion? Perforce?), a development methodology (eXtreme Programming? RUP? Scrum? Waterfall?), and, if you're lucky, an issue tracker (Bugzilla? JIRA? Scarab?).
Welcome to the jungle!
Tomado de: http://struts.apache.org/roadmap.html#choice
viernes, 2 de junio de 2006
El Codigo Florinchi (Parte II)
En nuestro ultimo episodio, nuestros heroes se encontraron ante un misterio aparentemente insodable.
Sigamos ahora con la historia...
Despues de la info proporcionada por los "tios del cliente", decidimos buscar en internet el parche para las clases propietarias de encriptacion. Finalmente lo encontramos en la pagina del proveedor (aunque no estaba muy visible que digamos). Pero, una vez mas, la suerte jugo en contra. Al intentar bajarlo, por algun motivo el browser nos daba time-out. Se habra caido la pagina? -pensamos.
Tras un par de llamadas a la gente indicada nos enteramos que la conexion a internet se habia caido en esa zona de San Isidro! En este punto ya empezamos a conjeturar por que estabamos teniendo tan mala suerte en este fuxxxing pase a produccion!! Y entonces........ sucedio.
Al voltear la mirada vimos la fuente de nuestra desdicha. Teniamos frente a nuestros ojos a Mr. Flores (alias Flowers). Ya empiezan a entender el por que del titulo de la presente saga... Y quien es este personaje? -se preguntara Uds. Pues es nada menos que uno de los "tios del cliente", el cual estaba a cargo del pase. El problema con el susodicho -que por cierto es buena gente y no tengo nada personal contra el- es que tiene una mala suerte con los pases a produccion que ni el personaje de Hanna-Barbera se le compara . Para muestra, baste decir que una vez empezo un pase un viernes por la noche y termino el domingo a las 3pm. Y no es exageracion...
Pero volvamos a la historia... tras intentar una y otra vez bajar el parche, finalmente lo conseguimos y tras unos pequeños tropiezos con la instalacion del mismo -pues no estaba bien documentada- todo salio bien. Al momento de probar el producto, sin embargo, obtuvimos nuevos mensajes de error. El tiempo seguia corriendo y si o si teniamos que dejar todo operativo para la mañana siguiente o eramos historia.
Indagando en los logs del servidor de aplicaciones y del web server, descubrimos que este ultimo estaba teniendo dificultades al intentar comunicarse con el primero mediante SSL. Buscando de nuevo en internet, decidimos bajar el ultimo parche del servidor web. Nos llevamos otra sorpresa cuando vimos que no habian parches sino que habia que reinstalar el servidor web... en fin. A estas alturas ya no podiamos ponernos exigentes.
Hicimos un backup del archivo de configuracion y reinstalamos el servidor. Al probar de nuevo la conexion, encontramos nuevos errores. Despues de un par de maldiciones a la mala suerte de Flowers, decidimos regenerar el certificado digital para reconfigurar la comunicacion SSL entre los servers. Finalmente lo logramos, pero al hacer la prueba obtuvimos nuevos errores. Esta vez, Jadclipse mediante, vimos que el problema era que el producto no podia desencriptar los passwords almacenados en los archivos de configuracion. Casi seguro se debia al upgrade que habiamos hecho de las librerias de seguridad.
Ya eran casi las 2 am y nuestra paciencia, si bien no se agotaba, ya saba señales de cansancio. Afortunadamente, los "tios del cliente" se portaron bien y compraron un pollito a la brasa, el cual fue devorado por los presentes. Armandonos de valor, buscamos el mensaje de error en la documentacion on-line y por suerte encontramos una pista.
Si bien lo que hallamos se referia a otra version del producto, al parecer aplicaba a nuestra situacion. La solucion pasaba por correr unos queries en la BD y regenerar otros archivos mediante comandos. Al realizar esto y probar otra vez... finalmente funciono! Pudimos extraer los documentos del servidor de contenido y todo se veia bien.
Sin embargo, la mala suerte de Flowers paracia no descansar. Esto lo descubrimos al salir del edificio y dirigirnos al estacionamiento donde el Agente X habia dejado su auto. Era tan tarde que estaba cerrado y no habia nadie que nos abriera las rejas.... chess!!! Despues de un par de gritos y forcejeos decidimos zafar a nuestros hogares... en el fondo satisfechos de haber cumplido la tarea.
Pero aun hay mas!! ....Cuando todo parecia bien... al dia siguiente tuvimos una desagradable sorpresa. Como nos habiamos amanecido en el bendito pase, nos correspondia llegar tarde a la chamba. Pero a eso de las 10 u 11 recibi varias llamadas de gente del cliente y de mi empresa diciendo que los usuarios no podian conectarse a "El Content" y subir sus documentos escaneados. Diablos!! Si ayer todo funcionaba....
Tuve que dejar mi merecido descanso y volar al lugar del desastre para encontrar que simplemente se trataba de un error de conexion. Como la prueba que habiamos hecho la noche anterior fue en el mismo server todo habia salido OK. El tema era que al regenerar el certificado digital habiamos cambiado el hostname por el nombre calificado de la maquina (hostname + dominio) y las maquinas de los usuarios estaban apuntando al nombre anterior.
Para colmo, el servidor de contenido no estaba inscrito en el servidor DNS -por extrañas razones que no comprendo-, sino que estaba en cada archivo hosts de los usuarios. Y, obviamente, solo estaba el nombre corto. Corregido este impase todo fluyo a la perfeccion y pudimos respirar tranquilos.... no sin antes decir una vez mas... Flowers salado!!
Suscribirse a:
Entradas (Atom)