jueves, octubre 25

El valor de un buen programador

Hacía mucho tiempo que no escribía ninguna entrada por aquí, y creo que la entrada que he encontrado va a resultar muy interesante para muchos.


10 Developers For The Price Of One


O lo que es lo mismo... '10 Desarrolladores por el precio de uno'. Os dejo aquí la traducción...

Traducción

En el 'Mítico Hombre Mensual', Fred Brooks destaca una llamativa disparidad entre los buenos y los malos programadores.

Los Directores (o Managers) de Desarrollo han reconocido que existe una gran variación de productividad entre los buenos programadores y los malos. Pero las actuales medidas de magnitud nos han dejado a todos pasmados. En uno de sus estudios, Sackman, Erickson y Grant estuvieron midiendo el rendimiento de un grupo de experimentados desarrolladores. Dentro del grupo, el ratio entre los mejores y los peores rendimientos medios estuvo sobre 10:1 en medidas de productividad y un sorprendente 5:1 en la velocidad de programación y la medida de espacio (tamaño del código).


Robert Glass cita la investigación que muestra esta disparidad aún mayor en su libro 'Hechos y Falacias de la Ingeniería del Software'.

Los mejores programadores son hasta 28 veces mejores que los peores programadores, de acuerdo a la investigación de 'diferencias individuales'. Dando esto que su paga nunca está en consonancia, ellos son la mejor gana en el campo del Software.


En otras palabras, los mejores desarrolladores están, generalmente, mal pagados y los peores demasiado bien pagados.

Pero no dejes todavía tu trabajo. Esto no significa que deba haber una correlación 1 a 1 entre productividad y paga. Que la gente fuese pagada en función de su aportación y productividad es solo una parte de su propuesta de tasación, aunque es una gran parte de ella. Incluso así, deberíamos esperar ver alguna clase de correlación entre la paga y la tan drástica diferencia de productividad. Pero en general, no la vemos. ¿Y por qué es así?


Pues es porque la mayoría de Directores (o Managers) no creen en esta disparidad de productividad, pese a los múltiples y repetidos estudios que lo verifican. ¿Por qué deberían de permitir que los hechos se interpongan en sus creencias? Eso solo significaría que los defensores de los hechos (factonistas en el original) han ganado.

Bromas aparte, ¿por qué es esta diferencia de productividad tan difícil de creer?... Permitirme que ponga palabras en la boca de un Director cualquiera (straw-man: hombre de paja, manager, en el original).

Bien... ¿cómo puede haber un desarrollador en el mundo capaz de escribir código 28 veces más rápido que otro desarrollador?

Esta clase de pensamiento, representa una falacia común cuando se viene a medir la productividad de un desarrollador. La productividad no son unas cuantas líneas de código. Un enorme montón humeante de código que no logra el trabajo hecho, no es productivo. 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.

TCO - Total Cost Of Ownership.

En general, siempre he intentado tener a los mejores desarrolladores que he podido encontrar. Pero he cometido errores con anterioridad. Sí, incluso yo.

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. Entregúe a este compañero un Proyecto para que lo llevase. Unos cuantos días después pasé por allí y no escuché nada del tío, 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.

Los buenos desarrolladores lo toman como propio, así que tú no tienes que hacerlo.

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.

Los buenos desarrolladores escriben código con menos errores.

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 cuanado 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 (speed en el original). Trata de velocidad media (velocity en el original). Tú puedes ir rápido, pero si vas en la dirección errónea, no estás ayudando a nadie.

Los buenos desarrolladores escriben código mantenible.

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.

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. Como un amigo siempre dice

¿Por qué construir cuando puedes comprar? ¿Por qué comprar lo que puedes tomar prestado? ¿Por qué tomar prestado lo que puedes robar?


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í, los buenos desarrolladores tienden a escribir menos (pero todavía legible) código 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).

De vuelta al TCO

Cada una de estas características que he listado, mantienen el coste total de propiedad de un buen desarrollador bajo. Por favor, no dejen que el término 'propiedad' les distraiga. A lo que me refiero aquí es al coste para la compañía de tener al desarrollador en nómina.

Por escribir menos código que hace más, y por escribir código mantenible que tiene menos errores, un buen desarrollador resta presión a la plantilla de QA, compañeros de trabajo y dirección, incrementando la productividad de todos. Esto es por lo que los números como 28 veces productivo son posibles y pueden incluso parecer poco cuando miras el total.

Espero que esta perspectiva convencerá a los directores de que los buenos desarrolladores realmente son tan productivos como los estudios muestra. Negociar un incremento del salario de 28x, es un ejercicio que dejo a los lectores.


Conclusión


Como podeis ver, el artículo da una buena visión de la importancia de tener buenos desarrolladores (que no programadores) en plantilla para afrontar un proyecto con garantías.
Y sobre todo, nos expone con claridad que la productividad no solo se debe medir por el número de líneas de un desarrollador, ni solo en el tiempo exclusivo de desarrollo.

Y si bien es cierto que a un buen programador no se le puede pagar 28 veces el salario de uno malo, sí que es importante saber reconocer a un buen desarrollador y pagarlo debidamente en función de lo que aporta en términos de productividad al proyecto, al equipo y a la dirección.

Y olvidarnos así, de una vez por todas, de esas falsas premisas de que todo el mundo desarrolla igual y por tanto a todos se les paga igual. Es decir, un desarrollador no es un operario de una máquina, que sabe cuándo pulsar los botones correctos... es más bien, como un pintor que crea con sus pinceles, y por tanto podemos tener a un pintor más... o a un Leonardo Da Vinci.

Etiquetas: ,

miércoles, julio 11

miércoles, noviembre 22

Creación de CENATIC

Leo en este artículo, que se acaba de aprobar la creación del CENATIC (Centro Nacional de Referencia de Aplicación de las Tecnologías de Información y Comunicación) constituido por el Ministerio de Industria y la Junta de Extremadura.

Entre sus objetivos, impulsar el uso del Software Open Source en el ámbito empresarial y la Administración Pública. Para ello, anuncia inversiones futuras por un total de 2,29 millones de euros para impulsar el desarrollo de Software Libre en España.

Sin duda una iniciativa interesante y una buena noticia en un país en el que el I+D tiene una presencia simbólica.

Pero me pregunto, si el Gobierno será el primero en dar ejemplo en el uso de Software Libre, o seguirá comprando equipos con SSOO propietarios, tal y como podemos leer en este otro artículo.

Si lo hiciera, si se decantase por el uso del Software Libre, sería mucho el dinero que se ahorraría en licencias al cabo del año, y que podría ser destinado, a través del CENATIC, a promover nuevos proyectos de Software Libre.

Pero mucho me temo, que aunque las intenciones sean buenas y el CENATIC realice una buena labor en cuanto a promover el uso del Software Open Source, el Gobierno y sus Administraciones seguirán 'atados' al Software de Microsoft.

Y además, está por ver qué tipo de iniciativas y facilidades llevará a cabo el CENATIC para conceder sus ayudas... porque si estas ayudas se van a dedicar únicamente a empresas ya consolidadas, puede que todo quede en un gesto para la galería.

Etiquetas: ,

martes, noviembre 14

La seguridad del acceso a FON.

Ayer tuve la ocasión de leer la opinión de una persona, en la que alertaba sobre un fallo en el acceso a FON.

Esta persona decía que si alguien, un alien, quisiera acceder a FON a través de alguno de los nodos, podría acceder a una página igual a la de FON sin saber si realmente es de FON o no... y claro, aquí tenemos un problema.
Cuando ese alien quiera comprar el acceso a FON, dará la información de su tarjeta de crédito a través de una página que podría ser falsa.

Esto, en principio podría resolverse con el uso de Certificados de Seguridad, que firmado por entidades como Verisign, asegurarían al posible usuario de que realmente nos encontramos ante un punto de acceso de FON.

Pero... dándole más vueltas al tema, enrevesando un poco más la cosa... me surge otro escenario.

Imaginemos que una persona se apunta a FON. Recibe su Fonera, y dado que se supone que el firmware de esta es abierto y actualizable, decide coger el firmware y añadir alguna modificación...
Imaginemos que cambia la página de acceso para aliens, donde recoge los datos del nombre y la tarjeta de crédito de esa persona, y se guarda, localmente, dichos datos para luego redirigir la petición a la página real.


Esta persona, a medida que pasa el tiempo, sigue acumulando datos y más datos personales de clientes de FON. Hasta que llega un momento, en el que o bien vende esta información... o decide irse de compras por internet a costa de otros...




Efectivamente, puede parecer un escenario algo tremendista... pero dado que la Fonera no es un dispositivo cerrado, puesto que se vendió como algo abierto y comunitario, es factible.

Así pues... sabiendo que algo así podría ocurrir, ¿es FON una empresa confiable a la hora de dar este servicio?

Sinceramente, creo que no... y como posible usuario alien, me inspiraría poca confianza dar los datos de mi tarjeta de crédito a través de un router, montado en casa de no se muy bien quién, con un firmware que bien podrían no ser el original.




Por ello, para que FON pudiese dar un servicio así, los puntos de acceso deberían ser de su responsabilidad y cerrados, por lo menos en la parte de red pública, de forma que nadie pudiese modificar dicha parte.


La verdad, a estas alturas me sorprende que nadie en FON haya caido en la cuenta de algo tan extendido como el robo de identidad. Así que una de dos... o son demasiado confiados al estar demasiado centrados en el entorno linus y una comunidad basada en la confianza mutua, o tal vez no les interesa mucho lo que pueda ocurrir en estos casos...

Foto de Verisign, tomada de http://www.verisign.es/

Etiquetas: ,

Micros Dual Core y Quad Core

Hace un momento he terminado de leer este artículo en theInquirer.net, en el que se hace un análisis rápido sobre la evolución de los micros Dual Core, de AMD e Intel, y los futuros Quad Core.

Resumiendo, se explican las diferencias entre las primeras soluciones Dual Core de Intel, la solución de AMD y los planes de futuro de ambas compañías para empezar a ofrecer, en breve, micros Quad-Core (4 procesadores).

Por lo visto, la solución que Intel implementará se basará en encapsular dos nucleos Dual Core en un único microchip...
Mientras tanto, AMD trabaja en ofrecer placas donde el usuario pueda montar dos micros Dual Core (2x2=4 procesadores), en incluso en el futuro montar dos micros Quad Core (4x2= 8 procesadores).

La conclusión... a día de hoy ningún Software es capaz de aprovechar las ventajas de poder usar múltiples hilos, por lo que es preferible esperar a finales del año que viene antes de embarcarse en la compra de un procesador Quad Core.

Etiquetas: , , ,

jueves, noviembre 9

EL Fon Liberator

Acabo de ver este comentario en fon sobre el liberator.

Tiene buena pinta, pero hay que ver el precio y muchas consideraciones sobre el mismo, el acceso desde Internet al disco podría ser muy interesante a la vez que arriesgado, pero ya puestos, ¿porque no puede el liberator a través de la web de FON ser un modo de poner tu propio espacio en Internet, después de todo FON está metiendo un server Web en sus router y yo pongo el disco.

Evidentemente, no te vas a montar un medio ganar dinero, pero sí una web con mi propia información para compartir.

Ahora vendrá la SGAE, porque eso de los ficheros alojados en mi equipo mientras se descarga tiene pinta de que se lo estemos poniendo a huevo para localizarnos rápido.

miércoles, noviembre 8

Actualizar la fonera.

Vaya por dios, la fonera hackeada, la puerta trasera reventada y la gente por ahi con un modo de usarlo, resulta que Martin V. jura que esta arreglado y los de fon me dicen:

-------
Discussion Thread Response (Susana XXXXX) 08/11/2006 10.28 AM

Hola,

En cuánto a la actualización de la fonera, en cuanto haya una actualización de firmware se publicará en la página.
-------

Pues mal Fon, muy mal, porque ya que metéis una puerta trasera lo mínimo era que se actualice sola, porque para recuperar la configuración de la fonera valía con una consulta https (o similar, no me importa el medio concreto) y que se actualizara un fichero y lo que hacéis es meter ejecutables. Si montas un medio como el elegido no es para yo me actualice el SW de modo manual, y encima sin que se me notifique que tengo que hacerlo. ¿Me tendré que mirar el blog de martin p0r seguridad.

Por si era poco, no me descarga el firmware en FireFox...

martes, noviembre 7

Mi fonera y algunos consejos a FON

Ya soy fonero, de verdad, porque después de cargarme mi primer router linksys actualizando el firmware me llegó mi fonera, todo chula ella y como no la toque pues va de maravilla.

Hay mucha gente quejándose de que la fonera tiene una puerta trasera, y por ejemplo de que se use el DNS de FON en lugar del propio. Bueno, quejarse está bien, y todo es mejorable, pero tener FON es opcional y gratis. La puerta trasera me parece discutible pero a cambio no me cargo el router actualizándola, los proveedores ISP hacen lo mismo así que admitamos que es una solución posible.

El tema de cambiar el DNS, como creo que no era imprescindible es más discutible, pero posiblemente es para evitar problemas en la conexión debidos al DNS de los demás proveedores. No me gusta nada que se juegue con quien registra mis accesos a internet, pero bueno... como alguien los va a registrar... para que preocuparme.

Sobre el funcionamiento de FON.

Con el portátil no he tenido un solo problema, aunque parece que hay dependencias entre el tipo de cifrado y la tarjeta y eso puede dar la lata, porque no está bien documentado el tema.

Debido a que mi PDA no admite el cifrado de la red privada me he conectado a través de la red FON de mi casa con ella, y da ciertos problemas (que entiendo que cualquier fonero que pase por mi calle sufrirá y yo en otro punto FON) ya que me da continuamente avisos sobre errores en la firma del certificado de seguridad (no coincide el dominio por lo visto), estos problemas dan además en cada objeto por lo que para conectar es preciso realizar un elevado número de confirmaciones.

Si bien en mi casa y con mi PDA eso no es un problema grave, si lo es para alguien que quiere una conexión rápida desde la calle por ejemplo, más de cinco minutos confirmando para entrar a la red desesperan a cualquiera.

Además creo que el portal de conexión es excesivamente pesado, entiendo el objetivo comercial, pero desde luego un fonero ya conoce FON y lo que queremos es un acceso más rápido a la red y no esperar la carga de un montón de información no deseada y conocida.

Mi fonera y algunos consejos a FON

Ya soy fonero, de verdad, porque después de cargarme mi primer router linksys actualizando el firmware me llegó mi fonera, todo chula ella y como no la toque pues va de maravilla.

Hay mucha gente quejándose de que la fonera tiene una puerta trasera, y por ejemplo de que se use el DNS de FON en lugar del propio. Bueno, quejarse está bien, y todo es mejorable, pero tener FON es opcional y gratis. La puerta trasera me parece discutible pero a cambio no me cargo el router actualizándola, los proveedores ISP hacen lo mismo así que admitamos que es una solución posible.

El tema de cambiar el DNS, como creo que no era imprescindible es más discutible, pero posiblemente es para evitar problemas en la conexión debidos al DNS de los demás proveedores. No me gusta nada que se juegue con quien registra mis accesos a internet, pero bueno... como alguien los va a registrar... para que preocuparme.

Sobre el funcionamiento de FON.

Con el portátil no he tenido un solo problema, aunque parece que hay dependencias entre el tipo de cifrado y la tarjeta y eso puede dar la lata, porque no está bien documentado el tema.

Debido a que mi PDA no admite el cifrado de la red privada me he conectado a través de la red FON de mi casa con ella, y da ciertos problemas (que entiendo que cualquier fonero que pase por mi calle sufrirá y yo en otro punto FON) ya que me da continuamente avisos sobre errores en la firma del certificado de seguridad (no coincide el dominio por lo visto), estos problemas dan además en cada objeto por lo que para conectar es preciso realizar un elevado número de confirmaciones.

Si bien en mi casa y con mi PDA eso no es un problema grave, si lo es para alguien que quiere una conexión rápida desde la calle por ejemplo, más de cinco minutos confirmando para entrar a la red desesperan a cualquiera.

Además creo que el portal de conexión es excesivamente pesado, entiendo el objetivo comercial, pero desde luego un fonero ya conoce FON y lo que queremos es un acceso más rápido a la red y no esperar la carga de un montón de información no deseada y conocida.