url: http://glnconsultora.com/blog/?p=84
Introducción
Hoy dia en las empresas de desarrollo de software o en aquellas organizaciones que cuentan con profesionales de IT entre sus filas, muchas veces habremos oido la expresión sobre que tal o cual persona es un buen o mal programador. Tal afirmación, muchas veces es tan particular o relativa a quien la expresa, se suele pensar que esta sobreentendido quien cae en tal o cual vereda. Es por eso, que para no ser menos, se me ocurrio indagar un poco en la web para ver que opiniones hay al respecto y asi poder plantear la mia en este post. Dejo de lado el analisis del programador de su casa, o el que programa por mero hobby.Un poco de análisis del tema
Existe un articulo en el cual se investigó este dilema. Este articulo e bastante conocido y lo comprobarán si prueban googlear al respecto. Aborda con mucha claridad determinando factores que influyen en la productividad de un programador: compromiso, eficiencia, por supuesto que el nivel tecnico, entre otras, que permiten afirmar que no sólo se debe medir por el número de líneas de un desarrollador, ni solo en el tiempo exclusivo de desarrollo. En este punto claramente coincido: ser un buen programador es algo que va obviamente mas alla de la cantidad de tiempo que se insuma en la tarea (los malos programadores muchas veces son los que mas horas estan en las oficinas y no por esto se vuelven buenos)Entre las conclusiones del articulo, la mas significativa es la siguiente: existe una relacion 10:1 entre los buenos y malos programadores. Un buen programador equivale 10 malos programadores en cuanto a productividad se refiere. Y dentro del tema de la productividad cita diferentes puntos a considerar en el perfil de un buen programador. A continuación algunos extractos:
Hay muchos aspectos en la productividad del desarrollador, pero todos se caen bajo un principio principal (tomando prestado un término de la industria financiera): TCO (Total Cost Of Ownership):
1 – Los buenos desarrolladores lo toman como propio, así que tú no tienes que hacerlo.
Una situación que me viene a la mente, fue con un desarrollador que había contratado (bajo un montón de presión para contratar a todos los que pudiese) como formador de la compañía. Entregué a este compañero un Proyecto para que lo llevase. Unos cuantos días después pasé por allí y no escuché consulta alguna de su parte, así que asumí que las cosas estaban yendo bien.
Dejé pasar unos días y pasé a ver cómo iba la cosa, y el desarrollador me dice que no entiende algunos requisitos y que ha estado haciendo un esfuerzo tratando de entenderlo todo este tiempo.
2 – Los buenos desarrolladores escriben código con menos errores
Esta es una de las primeras formas en que los buenos desarrolladores son más productivos que los desarrolladores medios.
Ellos hacen suyo el proyecto. En lugar de gastar una semana haciendo esfuerzos porque no entienden un requisito, un buen desarrollador toma decisiones y arroja algo de claridad.
Igualmente, un buen desarrollador no requiere que le des un empujoncito a cada momento para asegurarte de que están progresando. Si se atascan demasiado en un problema, ellos irán a ti o sus compañeros de trabajo para resolver el problema.
Un desarrollador que puede escribir código rápido, pero no toma como propios sus proyectos no es muy productivo, porque acaban malgastando tu tiempo.
3 – Los buenos desarrolladores escriben código mantenible
Una vez trabajé con un desarrollador que venía avalado por mi jefe por ser extremadamente rápido escribiendo código. ¡Y desde luego que era rápido! Pero también lo era para meter ‘bugs’ en el código. Su código era descuidado y difícil de entender.
La medidad clave que no figuraba en su medida de productividad era la cantidad de productividad perdida por el equipo de QA, intentando reproducir errores introducidos en su código, junto con el tiempo gastado en arreglar estos errores por otros desarrolladores.
Todos se enfocan en su tiempo para la ‘terminación’, pero no en el coste total de propiedad de ese código. El código no está completo cuando un desarrollador dice que está completo. No es el momento de parar el cronómetro. Es cuando QA ha dado su SI cuando puedes parar el cronómetro, por el momento.
Como me gusta decir, la productividad no trata de correr mucho. Trata de velocidad media. Tú puedes ir rápido, pero si vas en la dirección errónea, no estás ayudando a nadie.
De la mano con el escribir menos errores, está el escribir código entendible y mantenible. Tran pronto como una línea de código aparece en pantalla, estás en modo mantenimiento sobre esa línea.
El código que es frágil y difícil de cambiar, malgasta horas y horas de ciclos de desarrollo cuando intentas enmendar un sistema con actualizaciones y nuevas funcionalidades. Escribiendo código mantenible, un buen desarrollador puede hacer estos cambios más rápidamente y también aumenta la productividad de su equipo, quien más adelante tendrá que trabajar con ese código.
4 – Los buenos desarrolladores hacen más con menos código
Otro sello distintivo de un buen programador es que saben cuándo no escribir código.
Salvo unas cuantas excepciones, el síndrome NIH (Not Invented Here-No inventado aquí) es un asesino patológico de la productividad.
He visto a desarrolladores comenzar a escribir sus propios frameworks para la validación de formularios hasta que les he apuntado que ya hay uno escrito en ASP.NET que hace el trabajo (No es perfecto, pero es mejor que el que les he visto escribir).
Todo ese tiempo gastado reinventado la rueda se ha perdido porque alguien ya había escrito ese código para ti. Y en muchos casos, hizo un trabajo mejor porque era su único objetivo. En tal situación, encontrar una librería existente que nos de el trabajo hecho puede darnos un enorme impulso a la productividad.
La advertencia en este caso es ser cuidadoso y evitar las librerías no extensibles y rígidas de terceras partes, especialmente para requisitos muy especializados. Puedes perder un montón de tiempo intentando meter una ficha redonda en una caja cuadrada.
Incluso cuando tú debas inventar aquí (NHI), los buenos desarrolladores tienden a escribir menos código (pero todavía legible) que hace más. Por ejemplo, en lugar de escribir una máquina de estados para parsear texto de un gran String, un buen desarrollador puede usar una expresión regular (Ok, alguno dirán que un regex no es legible. Pero es más legible que miles de líneas de texto de código de parseo).
Y por casa como andamos?
Del extracto anterior se desprende claramente que un buen programador sera aquel que mejor salga parado al evaluar su relación para con su codigo (legible, mantenible, documentado, sin bugs), con sus compañeros de equipo (no romper builds, ayuda a otros programadores), con su proyecto (costo de propiedad, ownership). Un buen programador es un todo, no una mera parte tecnica. Un buen programador debe ser responsable con todo y todos los que intervienen, junto con él, en la construcción de un sistema informático.Es entonces en este sentido, que todo programador deberia (antes de que lo hagan otros) evaluarse en estos temas y tomar acciones correctivas en el caso que se encuentre fallando. Esta evaluación no es sencilla y deberá considerar los conocimientos técnicos, optimización del tiempo, comunicación con el equipo, que postura tengo hoy para con el proyecto y cliente, etc.
Concentrandonos un poco en el aspecto ténico o de producción, el buen programador aprovecha su tiempo para codificar los requerimientos, de la manera mas practica y eficiente posible. Pero ¿que es aprovechar el tiempo?, bueno, digamos que de las 8 horas que trabajamos, cuantas en definitiva las estamos abocando correctamente a producir resultados esperados y utiles para el proyecto. Saber cuanto tiempo invertimos (o perdemos) en determinados temas será vital como punto de inicio para la mejora de cada uno. Una forma que me parece apropidada y practica de implementar, es que dia a dia los programadores, al tomar o asignarsele una tarea de relevancia, al cerrarla completen un registro de cuanto tiempo insumieron en produccion neta de dicha funcionalidad, cuanto tiempo tuvieron que investigar, cuanto tiempo estuvieron tratando de comprender lo que debian hacer, cuanto descansaron, cuanto tiempo tuvieron en corrección de bugs, etc. Aquel programador que la mayoria del tiempo se encuentre investigando puede denotar necesidades de capacitación en la temática investigada, quien pierda mucho tiempo tratando de comprender las tareas que se le asignan denotará que el problema de su mal rendimiento por ahi viene de antes, desde el momento mismo de la especificación del requerimiento.
Cada minuto de trabajo es vital, y la optimizacin del tiempo es un tema que no deberia dejarse de lado. Entendiendo como distribuimos nuestro tiempo podemos observar que insumimos mucho tiempo en descansos o pausas, lo cual puede ser sintoma de problemas de concentracion, dispersion, etc. Para este tipo de situaciones, existen tecnicas como la de Pomodoro que nos servira apra ir ganando atencion en lo que hacemos.
Productivos y no productivos
Finalmente, nos quedarian algunas palabras respecto a la paga que recibe un programador, sobretodo la relación entre una de un buen programador en relacion a la de otro malo. El articulo de Brooks destacada ademas que existe una realidad que indica que los malos programadores cobran mejor que los mejores programadores.Aqui, mi opinión concuerda con la de muchos, en cuanto a que todo programador debe recibir una paga acorde a su productividad, no unicamente considerando que tantas horas estuvo frente a la maquina. Esta productividad, en su forma mas sencilla, es una relación directa entre cuantas actividades tomó o le asignaron para realizar y cuantas pudo cerrarlas sin errores (aprobadas por Pruebas y QA). En este punto juega un papel preponderante la estimación de esfuerzo que se haga de cada actividad que ejecuta un programador. La estimación no deberia ser de una unica persona ya que esto podria generar situaciones como ser una disputa sobre si se subestimo una actividad en relacion a lo que llevo realmente. Aqui, lo mejor son tecnicas agiles, como planning poker o delphi.
El pago por productividad, en contraste con el pago por horas al mes, evita que los programadores no tan eficientes puedan recibir pagas mejores que la de un buen programador, en relacion a lo que producen. No obstante, la medicion de la productividad es bastante dificil en la profesion de un programador, ya que intervienen muchas cuestiones que pueden atentar con la tarea, como ser especificaciones de funcionalidades muy vagas que retrasan el inicio del desarrollo, o la inclusion de cambios en lo ya codificado que hacen que se tenga que rehacer una funcionalidad ya concluida. Será tarea entonces de tomar medidas para evitar estas situaciones y que la labor de los programadores sea lo suficientemente “limpia” como para poder considerarla para evaluarlo. Algunos autores, como Martin Fowler directamente afirman que la productividad es algo que no puede medirse.
La productividad y el pago por la misma, es la punta de un iceberg que iremos descubriendo en otros posts ;-).
Conclusiones
Un programador es un rol fundamental en el desarrollo de software, cada vez mas solicitado, demandado por pequeñas y grandes empresas. Es la bala de plata que muchos lideres buscan para poder cerrar sus proyectos, hasta que cuando se encuentran ante alguno, lanzan un dilema muy viejo: éste…será bueno o malo programando?.La respuesta a esa pregunta dependerá de muchos elementos; los aspectos técnicos pueden ser los mas faciles de probar, via pruebas de codificación, examenes y demas, pero los que muchas veces mas imperan, el compromiso, la responsabilidad, la proactividad, si realmente le gusta lo que hace, son muy dificiles de descubrir de antemano. Se asoman luego semanas o meses de trabajo en un proyecto y su tratamiento no depende de meras capacitaciones (¿como se hace responsable a alguien? ¿cuanto tiempo lleva esto?).
Si somos programadores a esforzarse para ser un programador profesional e íntegro. Esto es lo que cuenta. Si somos de los que lideran o coordinan programadores, deberemos analizarlos desde perspectivas mas alla de cuestiones técnicas. Para ambos casos, deberemos buscar mecanismos que nos brinden indicadores para decidir que tan bueno o malo se és.
Saludos
No hay comentarios:
Publicar un comentario