Peopleware (Parte VI)

Finalmente, esta es la última entrega de los resúmenes del libro Peopleware y corresponde a la sexta sección. Los resúmenes anteriores están en los siguientes enlaces:

• Peopleware (Parte I)
• Peopleware (Parte II)
• Peopleware (Parte III)
• Peopleware (Parte IV)
• Peopleware (Parte V)

PART VI

Whether it is named or not, coaching is an important factor in successful team interaction. It provides coordination as well as personal growth to the participants. It also feels good. We tend to look back on significant coaching we've received as a near religious experience. We feel a huge debt to those who have coached us in the past, a debt that we cheerfully discharge by coaching others.

The act of coaching simply cannot take place if people don't feel safe. In a suitably competitive atmosphere, you would be crazy to let anyone see you sitting down to be coached; it would be a clear indication that you knew less than your coach about some subject matter. You would be similarly crazy to coach someone else, as that person may eventually use your assistance to pass you by.

Our point here is somewhat more limited: Any action that rewards team members differentially is likely to foster competition. Managers need to take steps to decrease or counteract this effect.

The paradox of the CMM is that process improvement is good, but process improvement programs aren't, or at least they often aren't. Competent people are involved in process improvement all the time: They take pride in progress and growth, and these can only come from getting more proficient at what they do. This kind of low-level process refinement is the basic hygiene of knowledge work, but formal process improvement moves responsibility up from the individual to the organization. The individual may strive for, practice, and/or promote good skills, but the organization can only institutionalize them. It is in this institutionalization that the danger lies.

Organizations that build products with the most value to their customers win. Those that build products that make the world yawn lose, even though they build them very, very efficiently. Even those who stumble while building products of high value win over the efficient yawners. Process isn't worth a rip unless it's applied to projects that are worth doing.

When process improvement (as in "Level 3 by the end of the year!") becomes the goal, the scary projects get put onto the back burner. It's those scary projects, unfortunately, that are
probably the ones worth doing. All the projects that carry real benefit carry real risks along
with them. It is the project that has some novelty, some innovation or invention, that might grab the customer's imagination and wallet.

Copyright © 1999, 1987 by Tom DeMarco and Timothy Lister.

Peopleware (Parte V)

Esta es la quinta entrega correspondiente al resumen de la quinta sección del libro Peopleware. Pueden acceder a las anteriores entregas aquí:

• Peopleware (Parte I)
• Peopleware (Parte II)
• Peopleware (Parte III)
• Peopleware (Parte IV)
  

PART V

A pilot project is one in which you set the fat book of standards aside and try some new and unproved technique. The new technique will be unfamiliar initially, and so you can expect to be inefficient at the start in applying it. This is a cost of change. On the other side of the ledger is the improvement in productivity gained from using the new technique. Also on the plus side of the ledger is the Hawthorne Effect, the boost in energy and interest that infuses your people when they're doing something new and different.

One caveat about pilot projects: Don't experiment with more than one aspect of development technology on any given project. For all the talk about the importance of standards, it's surprising how often managers abandon all standards on the rare project that is designated a pilot. They often try out new hardware, new software, new quality control procedures, matrix management, and new prototyping techniques, all on the same project.

War games help you to evaluate your relative strengths and weaknesses and help the organization to observe its global strengths and weaknesses. For these reasons, two of our client companies are now undertaking a program of annual war games, used by their employees to gauge improvements in their own skills over time. Once a year, they subject themselves to the confidential testing process, much as you would submit yourself to a physical exam.

For the purpose of stimulating creative disorder, the most effective form of war game calls for participants to take part in teams. When you pull this off successfully, people will tell you they've had the most exciting and enjoyable experience of their entire careers; nothing less than that is your goal. Expect to achieve that goal, though it may take a few tries.

Running the project through a whole night, for some reason, adds to the fun. People love an excuse to get tired together, to push back sleep and let their peers see them with their hair down, unshaved, rumpled, and grumpy, with no makeup or pretense. And it makes them feel more closely bound to each other.

Perhaps this is a sad comment on the dismal corporate workplace, but everybody relishes a chance to get out of the office. The chance that workers relish most is one combining travel with their peers and a one-of-a-kind experience. It might be going off together for a training session, particularly a provocative one, or taking in the International Conference on Whatever.

Is a few thousand dollars for a getaway experience too rich for your discretionary disorder budget? Maybe you could spring for forty dollars. One of the most innovative managers we know has a penchant for putting on unexpected lunches for his staff. He once went down to the city street and hired a hot dog vendor, complete with cart, sauerkraut, yellow mustard, and a blue and orange umbrella, to come up thirty floors and serve lunch to the team. The
lunch was a nutritionist's nightmare but a sociologist's dream come true. Those who were there got high on good spirits and began to do bits and skits about their work, their managers, and each other. The noise level went up with their enthusiasm. It cost forty dollars and has been talked about ever since. Of course, that manager wrote it up as a business lunch, but it wasn't a lunch at all, it was a celebration.

The mark of the best manager is an ability to single out the few key spirits who have the proper mix of perspective and maturity and then turn them loose. Such a manager knows that he or she really can't give direction to these natural free electrons. They have progressed to the point where their own direction is more unerringly in the best interest of the organization than any direction that might come down from above. It's time to get out of their way.

It doesn't take great prescience to see that one of these measures is all you're likely to pull off successfully. If you try more, you will just diffuse your efforts. The rumpus you'll raise will be more confusing than constructive, and your colleagues and those above you in the corporate hierarchy are likely to write you off as a whiner. One change is plenty. Even a single substantive change to the sociology of your organization will be a mammoth accomplishment.
The key to success in fostering the kind of change we're advocating is that you not try to wrestle the bull. You're certainly not strong enough for that.A single person acting alone is not likely to effect any meaningful change. But there's no need to act alone. When something is
terribly out of kilter (like too much noise in the workplace), it takes very little to raise people's consciousness of it. Then it's no longer just you. It's everyone.

Sociology matters more than technology or even money. It's supposed to be productive, satisfying fun to work. If it isn't, then there's nothing else worth concentrating on. Choose your terrain carefully, assemble your facts, and speak up. You can make a difference...

Copyright © 1999, 1987 by Tom DeMarco and Timothy Lister.

Sobre optimización de aplicaciones

Acerca de la optimización prematura de aplicaciones hay tres citas famosas que copiaré a continuación:

• "The First Rule of Program Optimization: Don't do it. The Second Rule of Program Optimization (for experts only!): Don't do it yet." - Michael A. Jackson
• "More computing sins are committed in the name of efficiency (without necessarily achieving it) than for any other single reason - including blind stupidity." - W.A. Wulf
• "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil." (Knuth, Donald. Structured Programming with go to Statements, ACM Journal Computing Surveys, Vol 6, No. 4, Dec. 1974. p.268.)

Creo que ya pueden intuir por donde va mi opinión al respecto. Básicamente, la tendencia moderna dentro de la ingeniería de software es escribir código bien diseñado desde el punto de vista del paradigma de programación que se esté utilizando (ej: OOP) y legible, es decir, que sea comprensible para aquellos que lo van a mantener o modificar en el futuro. Por lo tanto, debería ser expresivo, minimizar las duplicaciones y exhibir, idealmente, algunas (o todas) de las cualidades mencionadas aquí.

Esto no quiere decir que uno debe olvidarse del rendimiento de la aplicación. Lo hay que tener es la capacidad de comprender y prevenir aquéllos puntos críticos donde el performance podría verse adversamente afectado. Como bien sabemos, casi todos los sistemas empresariales actuales tienen interfaces a sistemas externos (bases de datos, ERPs, middlewares, legacies, etc). Por lo tanto, hay que tener en cuenta todas estas interacciones, junto con la configuración del application server y de la JVM, pues el rol que juegan en el ámbito del rendimiento suele ser mucho mayor que, por citar algo que comúnmente se menciona, la cantidad de instancias de una determinada clase.

En realidad, lo que se recomienda al diagnosticar y resolver problemas de performance es aplicar un enfoque similar al que explican en este artículo. La idea es eliminar todas las posibles causas externas para un rendimiento subóptimo antes de empezar a revisar el código (asumiendo que el código está bien estructurado y diseñado).

Desde luego, como las suposiciones siempre son peligrosas, todo buen desarrollo debe efecutar pruebas periódicas de stress y rendimiento (de preferencia lo más pronto posible) para encontrar y corregir problemas antes de que exploten en producción. Para esto hay herramientas específicas que se pueden utilizar (load testers, profilers, extensiones de JUnit como JUnitPerf, etc)

En conclusión, mi recomendación (y la de muchas otras personas dentro de la industria), en lo que al desarrollo de aplicaciones empresariales se refiere, va por privilegiar un buen diseño que exprese el dominio del problema o negocio lo mejor posible mediante un código correctamente estructurado y lo más legible posible. Una vez alcanzado este objetivo, los problemas de performance (que siempre los hay) se pueden atacar y resolver con las herramientas adecuadas.