Peter Wayner, escribiendo en “CIO” y
haciendo mucho uso del humor desde la perspectiva del programador, hace un
interesante análisis de los 15 principales obstáculos que bloquean el progreso
en programación:
1.
Reuniones
El trabajo de
programación incluye un esfuerzo mental que implica concentración para poder
profundizar en temas como manipulación de conceptos abstractos y mover el switche para pasar del modo de
codificación al modo de reuniones no es nada simple. Las reuniones
requieren otras habilidades y atención y no son fáciles para las programadores
donde adicionalmente, el mal manejo de estos encuentros en muchas ocasiones las
extiende innecesariamente. Lo ideal es
que las reuniones sean cortas y concretas.
2.
Responder todos los correos electrónicos
Si para evitar reuniones se concentra
el esfuerzo en correo electrónico, la alternativa puede ser hasta peor. Un
gran volumen de correos puede conducir a un abandono total del uso del correo
electrónico por parte del programador. Por esa razón hay que buscar los mecanismos idóneos para hacer el uso
racional del mismo. Como lograr esto
dependerá de cada ambiente de trabajo.
3.
Tratar de medir productividad
Cuándo se enfoca la medición de la
productividad de una manera mecánica, por ejemplo usando como indicadores el
número de líneas de código o el número de bugs, se está desviando del objetivo
real. Hay que asegurar que los programas funcionen como se espera, que se
completen dentro del tiempo previsto y que se integren. Es importante medir la productividad, y
existen herramientas que pueden ayudar a disminuir el código y la redundancia,
pero no existe una solución fácil a este problema, ya que es imposible medir
elegancia.
4.
Desarrolladores “prima donna”
Desde el punto de vista del
desarrollador solo existe una figura peor que la de su jefe: el colega desarrollador
que hizo la última modificación del programa sobre el que debe trabajar y el cual no funciona. Esta actitud
también se puede extender a la generación anterior de desarrolladores y a la
forma en que estos programaban. Por supuesto,
muchos no consideran que no se disponía de las librerías que existen hoy en
día para facilitar la vida del desarrollador.
Estas actitudes de “prima donna” de algunos programadores pueden
retrasar un proyecto, ya que el orgullo y el egocentrismo puede llevar a
ignorar código adecuado ya hecho y a reconstruir continuamente en la búsqueda
de la “vía correcta”.
5.
La mentalidad de “lo arreglo más tarde”
En proyectos nunca parece existir el
tiempo necesario para construir todo lo necesario. Para poder cumplir con
los compromisos se apura el trabajo, se buscan vías para recortar el tiempo y
muchas veces se termina parcheando el código. Hay quienes llaman esto
“deuda técnica” y existe en todos los proyectos. En la generación
siguiente de programadores aparecen estas “deudas técnicas” y son ellos
quienes tienen que corregir la situación que encuentran.
6.
Gerentes no programadores
Hay personas que llegan a cargos de
gerencia técnica sin tener la formación académica y la experiencia apropiada en
programación. Esto puede alegrar a programadores que disfrutan engañando
a sus jefes, pero en mucha ocasiones estos Gerentes no pueden ofrecer mucha
guía y su principal contribución es proveer calidad en las pruebas.
7.
Gerentes programadores
También ocurre que al mismo tiempo que
programadores se quejan de jefes que no conocen el tema, por otro lado pueden
sufrir con gerentes que saben “demasiado” de tecnología. El gerente que
fue un genio programador puede hacer micro-gerencia e incluso realizar cambios
a nivel de código. El problema principal es que el Gerente puede perder la
visión global por estar concentrado en el detalle y no gerenciar realmente la unidad.
8.
Programadores “macho”
Los programadores admiten que hay
problemas que pueden estar del lado de ellos, muchas veces son malos
comunicándose y no son famosos por darle peso a los sentimientos o los
egos. Con frecuencia los programadores se desvían exclusivamente hacia los
temas técnicos y esto puede llevar a malas consecuencias cuando dentro de un equipo
se concentran en convencer sobre su visión técnica, en lugar de trabajar para
conseguir resultados prácticos.
9.
Programadores egoístas
El programador narcisista hace un
trabajo brillante de codificación, pero deja en manos de otros las pruebas.
Frecuentemente en los equipos de trabajo de un proyecto esto se descubre
demasiado tarde. Todo luce bien con el código al inicio, pero cuando
alguien se comienza a procesar data real allí se descubre que nadie se había
preocupado por detectar los problemas de la aplicación.
10. Documentación pobre
Documentar toma tiempo, pero el
programador considera que le están pagando por producir código. Así que
se deja para más tarde la documentación. También ocurren situaciones en las cuales hay documentación disponible, pero esta se refiere a una versión anterior hecha meses o años
antes.
11. Devoción esclavista a
la documentación
Igual que hemos experimentado
proyectos sin documentación, también existen las situaciones en las cuales hay
proyectos que fallan donde no se dedicó esfuerzo suficiente al código,
pero en cambio sí hay mucha documentación. Hasta hay quienes juran que se
les paga por el volumen de documentación!! Otra situación que ocurre
es cuando se escribe mucha documentación sin resumir y ello hace su aprovechamiento muy difícil, ya
que es como se si estuviera escribiendo la documentación en otro lenguaje de
programación.
12. Ambiente de circo
Los programadores requieren silencio
del tipo que existe en las bibliotecas. Conversaciones u otros ruidos
pueden llevar al programador a desconectarse de su zona mental de trabajo
abstracto y entrar en otra realidad. En algunos lugares se les proveen
mesas de ping-pong a los desarrolladores, pero se olvida que también se
necesita un ambiente de silencio para la concentración.
13. “Afinidad cultural”
Los equipos trabajan mejor cuando las
personas tienen un estilo común. Los equipos que no encuentran el terreno
común fallan rápidamente, ya que no se establecen buenas vías de
comunicación. Es difícil generalizar sobre cuál es el mejor ambiente de
trabajo, es mejor dejar que eso lo encuentre y defina el equipo de
trabajo. Eso implica que para ciertas circunstancias es mejor que las
personas trabajen uno cerca del otro, pero existen otras condiciones como el
trabajo de creación de un algoritmo complejo donde es preferible trabajar
aislado.
14. Aferrado a tecnología
legacy
En Dice.com hay una lista de 70.000
cargos, solo 680 son para programadores de Cobol. Sin embargo, todavía el
1% de los programadores que son defensores de Cobol dirán que es una gran
tecnología y para que re-escribirla? ….
Con esta actitud es difícil lograr el uso de tecnología nueva y siempre
se tendrán aplicaciones que pocos conocen y que algún día generaran problemas mayores de
mantenimiento.
15. Lujuria por lo nuevo
Las herramientas más recientes son
simpáticas para jugar con ellas, pero deben ser utilizadas en una fábrica de
software considerando que hay que reprogramar lo hecho la semana próxima?
Gente que trabaja en la tecnología de punta con frecuencia están
desechando secciones de API y reescribiéndolas, obligando a los que trabajan
río abajo a re-escribir su código. Realmente las nuevas herramientas
deben ser probadas en el tiempo.
No hay comentarios.:
Publicar un comentario