Comments on Blog de Julio César Pérez Arques: Cuanto vale un experto en programacion (ii)

@jmarranz tus puntos que empiezan con "Acepta con ...

2009-07-11T17:24:05.018+02:00

@jmarranz tus puntos que empiezan con "Acepta con resignación que ..." no considero que estén dentro de las características de un programador.

Un buen programador no se resigna, hace valer lo que hace y sabe hacer entender las complejidades de su trabajo.

@javi santana: en mi opinión el problema, como com...

2009-07-11T14:19:48.137+02:00

@javi santana: en mi opinión el problema, como comentas, es que nadie sabe la diferencia entre un programador bueno y uno malo.

Bueno te podría dar unas pocas ideas desde mi opinión personal:

Un buen programador

* Considera que la programación orientada a objetos es uno de las mejores inventos de la Historia del software.

* No repite código.

* Busca analogías entre partes del código similares e intenta generalizar en lo posible.

* Le encanta la simetría.

* Le encantan las jerarquías (de código).

* No atribuye demasiadas responsabilidades a una parte del código, cada parte es un servicio a otros.

* Le gusta particionar, divide para vencer, divide para controlar mejor.

* Es muy ordenado.

* Es muy cuidadoso.

* Es muy sistemático y coherente (aplica las mismas reglas, el mismo estilo).

* No se fía de sí mismo, siempre son posibles los errores, testea pensando no sólo en funcionalidad sino también en su código.

* La gestión de la complejidad no es un problema, el problema es la escasez del tiempo necesario para gestionarla, el problema son las prisas.

* Pone las herramientas y las librerías en su justo lugar, sabe que ninguna herramienta puede substituir un buen trabajo, desconfía de las herramientas/librerías que dejan poco espacio al programador.

* Considera el compilador uno de sus mejores amigos.

* Desmitifica el lenguaje concreto, valora más la riqueza y la calidad del ecosistema que lo rodea.

* No se le caen los anillos al admitir que su código no está preparado para asumir nuevas características y siempre está abierto a refactorizar cuando sea necesario. Detesta la chapuza cuando sabe que con algo más de trabajo el resultado sería mucho mejor.

* Acepta con resignación que le consideren como un peon y no como una de las "piezas" más críticas y valiosas de cualquier empresa moderna.

* Acepta con resignación que su trabajo (código, conocimiento, información) se valore a precio de saldo porque no tiene una manufactura, una fábrica detrás.

* Acepta con resignación que lo mejor y más difícil de su trabajo, la gestión de la complejidad y el modelado en software del conocimiento humano, no tiene colorines y nadie le dirá "qué bonito".

Etc, etc.

Dejando a un lado las métricas del código en mi op...

2009-07-11T10:23:23.263+02:00

Dejando a un lado las métricas del código en mi opinión el problema, como comentas, es que nadie sabe la diferencia entre un programador bueno y uno malo.

Sin embargo el resolverlo no está en que los demás se den cuenta si no en hacer que se den cuenta y bien sabido es que los programadores no son precisamente el ejemplo de comunicadores.

Intenta verlo del siguiente modo: tu pruebas tu có...

2009-07-10T19:37:53.906+02:00

Intenta verlo del siguiente modo: tu pruebas tu código, pero seguramente ahora lo que harás será desplegar la aplicación y hacer las pruebas sobre la aplicación de forma manual.
Suponiendo que pudiera hacer tests, el despliegue y los tests de integración se harían de forma automática, sobre esto tenía una charla propuesta la conferencia de Sun pero no fue aceptada. Aun así, entiendo el punto de vista de los tests unitarios pero en mi caso, no les veo tanta ganancia por que a lo que yo me dedico, tendría que hacer tanto "mock" que en realidad casi estaría probando lo fiable que son los mocks. Y para eso...

No puedo estar más de acuerdo contigo. http://gar...

2009-07-10T13:50:18.592+02:00

No puedo estar más de acuerdo contigo.

http://garciagonzalezdavid.wordpress.com/2009/04/18/7-razones-por-las-que-considero-que-un-buen-programador-es-mas-eficiente-que-10-no-tan-buenos/

Estoy contigo. Siempre hay que tener en mente la r...

2009-07-10T12:08:43.747+02:00

Estoy contigo. Siempre hay que tener en mente la regla del 80-20. Entonces un 60% de cobertura en realidad no dice mucho, porque no sabes la importancia de ese código.
Lo que si te da es que antes de modificar unas clases, puedes mirar la cobertura que tienen esas clases concretas y así saber el grado de fiabilidad que tendrá la regresión.

Yo es que los tests unitarios lo veo como parte del desarrollo y no como una fase de pruebas independiente. Intenta verlo del siguiente modo: tu pruebas tu código, pero seguramente ahora lo que harás será desplegar la aplicación y hacer las pruebas sobre la aplicación de forma manual. Con tests unitarios lo pruebas sin perder el tiempo en despliegues y con las ventajas que te ofrece la automatización.

El código podrá ser igual de bueno, pero la cobert...

2009-07-10T08:37:47.579+02:00

El código podrá ser igual de bueno, pero la cobertura te garantiza un % de regresión y eso no tiene precio.
Eso mismo, no es tanto lo que dice sobre el código como el valor que te dan los tests. Por eso el objetivo es hacer tests que te den valor, no "cubrir al máximo el código" en si mismo, ya que no mejora o empeora el propio código.

En cuanto a predicar con el ejemplo... claro, y luego le explico amablemente a mi jefe que en vez de desarrollar "mas funcionalidad", para la que ya nos falta tiempo, hago esto "extra"... de momento mejor me guardo la munición para cuando tenga una batalla que pueda ganar :).

@Ibon: estoy contigo 100%. Ni los mejores discurso...

2009-07-09T23:28:46.454+02:00

@Ibon: estoy contigo 100%. Ni los mejores discursos habrían hecho tanto bien como las estadisticas diarias de análisis de código. No sólo ha mejorado el código de cada programador, también su actitud, ganas de ser mejor y el sentimiento de equipo.

@Daniel: Tu mismo has dado en la tecla. El código podrá ser igual de bueno, pero la cobertura te garantiza un % de regresión y eso no tiene precio. Te recomiendo que prediques con el ejemplo a la hora de usar testing. Antes o después te copiarán y reconocerán su valor.

Leí una vez a alguién que decía que si no podías convencer a alguien del valor del testing, simplemente le obligaras a usarlo y ya se daría cuenta él sólo. En tu caso parece que no estás en esa posición, pero tampoco creo que te prohiban subir tests a CVS.

Respecto a lo de Santa Barbara, tienes razón en parte, pero debes pensar que desgraciadamente una aplicación falla mucho más que un coche. Como tu bien dices al final se aprende quién hace aplicaciones más estables. El objetivo (IMHO) es acelerar ese aprendizaje o predecir mediante números (métricas y testing).

Lo importante no es el número de tests sino la cob...

2009-07-09T20:44:31.283+02:00

Lo importante no es el número de tests sino la cobertura de los mismos.
"Pal" caso, lo mismo :). La idea es que el mismo codigo, con un 100% de cobertura o con un 0% es igual de bueno. El código.
A mi personalmente me gusta el FindBugs para encontrar los WTF! que dice Ibon y las pruebas funcionales y tests de regresion que correspondan a los requerimientos y permitan no tener que retestear todo cada vez desde cero. Si además de gustarme me dejaran usarlos, ya sería la caña de España!! :D

En cuanto a valoración de la profesión... pues no es nada nuevo bajo el sol. Desde fuera, igual valoramos nosotros como clientes finales a los que montan/diseñan las piezas internas de los coches, interior de las casas etc. Si no se rompe, ni nos acordamos que existen.
Internamente en las empresas, como en muchas cosas uno "sólo se acuerda de Santa Barbara cuando truena".
Yo para no darle vueltas empiezo por el amor propio, es decir lo intento hacer bien por satisfacción personal, y luego intento disfrutar los pequeños detalles indirectos, como que en caso de problemas acudan a tí por que eres de fiar, jejeje. En mi caso, como funcionario, económicamente no me lo valorarán nunca. Eso si, cuando hago de consultor independiente me lo cobro y al que le parezca caro, a mi me parece bien, que busque otro ;).

@jcesarperez En nuestro caso somos 11 y un único p...

2009-07-09T17:56:01.172+02:00

@jcesarperez
En nuestro caso somos 11 y un único proyecto, es verdad, pero quería recalcar el efecto PSICOLÓGICO en los programadores (aparte del cuantitativo de métricas): empiezan con reticencia, incluso con sonrisillas de sabelotodos ;-), pero cuando tienen un árbitro "objetivo" del nivel de "ñapismo" del código del que antes estaban tan orgullosos, ceden y aprenden buenas prácticas. Y cuando ven que se mide TODOS los días, no hay día que no se preocupen de que sus commits no sean los causantes de que la curva de sonar decrezca.

Os lo prometo, está superando mis expectativas, y estamos logrando más de lo que pensaba: de gente que no había usado junit en su vida (viva las empresas de software de españa!) a tener una cobertura media de teses unitarios de código del 15% en dos meses, sin contar las decenas de teses de integración; de tener unos beta testers a mano y papel, a pedirnos que les enseñemos a usar selenium; de código infumable, a leer TODOS los días "Effective Java" y "Clean Code" antes de cagarla.

Y creo que haber puesto Sonar en un lugar tan eminente, privilegiado e importante en nuestra metodología, ha ayudado mucho: aunque me importen una mierda los números exactos que nos de cada día, lo alucinante es que TODAS las tendencias son positivas, y hemos empezado por el caso de uso MÁS complejo de nuestra herramienta!.

Pues nada, simplemente deciros que creo que se puede hacer... me ha costado muchas horas, paciencia y mano derecha, pero los resultados me parece que van a ser muy buenos.

Salu2

PD: efectivamente, es una putada que Sonar sólo tire con ant... pero tal vez sea una señal para pasarse a maven ;-)

Me alegro de reencontrarme con algunos por estos l...

2009-07-09T17:43:59.322+02:00

Me alegro de reencontrarme con algunos por estos lares ;-)
Aunque disiento, porque parece que ya empieza a haber algún estudio estadístico sobre el tema. Personalmente me encantó esta charla: http://www.infoq.com/presentations/measure-for-measure

y viene a decir algo que estoy comprobando día a día en mi proyecto actual: a mayor complejidad ciclomática y menor cobertura de tests, la probabilidad de que aparezca un bug en determinado código tiende a uno.

Como toda buena estadística, una probabilidad del 99% NO quiere decir que el bug exista o que aparezca, pero a la hora de entregar el proyecto, uno como que se queda más tranquilo.

De la misma forma, he encontrado en el libro "Clean Code" un montón de medidas cualitativas que comprobadas en el día a día, me demuestran que es el "buen" código. Y alguna de ellas era contraria a lo que yo pensaba que era bueno ;-)

Creo que estamos viviendo un buen momento: después de tantos y tantos fracasos, empezamos a vislumbrar que funciona y que no funciona a la hora de tirar líneas de código. Como bien dice Daniel, las indicaciones positivas son difíciles, pero chicos, que bien detectan los "WTF!" ;-)

Salu2

Lo primero muchas gracias a todos por vuestros com...

2009-07-09T16:52:27.988+02:00

Lo primero muchas gracias a todos por vuestros comentarios.

Es evidente que medir la calidad de nuestro trabajo no es fácil ni inmediato.
El análisis estático de código no lo cubre todo. Tu código puede ser mantenible (bajo acoplamiento, métodos pequeños, comentado, etc.) pero eso no quiere decir que cumpla los requisitos del cliente, ni que sea estable, ni que sea escalable. Además el resultado del análisis tiene un fuerte componente subjetivo. Aún así, es mejor que nada.

Las pruebas (IMHO) sí vienen a medir las características que solicita el cliente para sus aplicaciones (eficacia, estabilidad y escalabilidad). Pero claro, deben ser unas pruebas funcionales y de stress completas. Y eso tiene un coste. Las pruebas unitarias son un instrumento más propio del programador para probar su código sin necesidad de estar desplegando la aplicación.

Las empresas de software deberían tener sus procesos de pruebas y QA para las aplicaciones que desarrollan.
Pero aún más importante es que lo tengan las empresas cliente para conocer sus aplicaciones y comparar a sus proveedores. Por fin tendrian datos y pruebas para saber por qué los proyectos que hace la empresa X dan menos problemas que los que hace la empresa Y!

En este último sentido sí estoy preparando una presentación sobre un sistema para medir la calidad de proyectos (@jm: aunque no sé si lo publicaré en jh, al menos con el nuevo sistema de remuneración es imposible) y SONAR es su componente principal (@Ibon: os tuve mucho en cuenta a Martín y a tí, pero para un equipo pequeño como el mio (4-5) y todos los proyectos con ANT, nos valía con los plugins de Hudson, pero SONAR es una herramienta impresionante que gana a todos cuando quieres medir la calidad a un nivel mayor de un único equipo o proyecto).

crap4j tiene en cuenta la cobertura para dar una m...

2009-07-09T15:31:19.659+02:00

crap4j tiene en cuenta la cobertura para dar una medida de calidad de l código.

Estas herramientas están muy bien, yo las uso a diario (checkstyle, findbugs, cobertura...) pero no van a servir para que nuestro trabajo se respete más o menos, lo único que va a contar al final son los resultados, y esto es lo que tenemos que demostrar: "cuando mejora la calidad del desarrollo los resultados son mejores", y esto es lo dificil realmente...

En mi opinión el problema radica en la dificultad de medir el dinero que se ahorra por los problemas que no se producen. Un buen programador hara código con muy bajo porcentaje de errores y mantenible, es decir, un buen programador esta ahorrando costos para el futuro tanto en mantenimiento como cuando se tengan que añadir nuevas funcionalidades, pero es muy dificil cuantificar este ahorro porque los problemas nunca se han producido...

Esta es en mi opinión la principal causa por la que no se valora al buen programador como se debería, proque lo que ese programador te esta ahorrando no aparece las estadisticas de los que luego pagan.

Lo importante no es el número de tests sino la cob...

2009-07-09T14:06:30.000+02:00

Lo importante no es el número de tests sino la cobertura de los mismos.

Yo es que lo de medir atributos siempre me deja......

2009-07-09T14:03:56.730+02:00

Yo es que lo de medir atributos siempre me deja... es como medir la calidad de un futbolista por sus medidas biométricas... te pueden dar indicaciónes claras negativas, pero las positivas es difícil.

Y en cuanto a los tests... el mismo código, exáctamente el mismo, tendría una valoración diferente si en el proyecto hay muchos tests o si tiene pocos... lo cual dice claramente que el número de tests no dice nada directamente aplicable al código.

Ojo, no digo que no sirvan para nada, pero creo que tampoco hay que dejarse llevar por el entusiasmo y confundir los medios con los fines.

S!

Vamos con un poquito de matemáticas. Todo según tú...

2009-07-09T13:54:18.516+02:00

Vamos con un poquito de matemáticas. Todo según tú articulo.

Vende servicio 2h por 300€.
300/2=150.
150 * 8h = 1200€ al día... ¡más que cristiano ronaldo! ¿Y TE QUEJAS? No sé, pero yo no llego a los 6€/h.

Yo he llegado a usar ésta: http://www.alphaworks....

2009-07-09T12:42:50.871+02:00

Yo he llegado a usar ésta:

http://www.alphaworks.ibm.com/tech/sa4j

Es muy sencilla de usar y te da un índice único de calidad. El problema es que está anticuada y lo mismo no reconoce código Java moderno y respecto al índice de calidad pues es muy discutible.

De nuevo tengo que aconsejarte Sonar: lo llevamos ...

2009-07-09T12:27:30.814+02:00

De nuevo tengo que aconsejarte Sonar: lo llevamos usando desde el inicio del proyecto, y aunque Hudson también da esas métricas, las ventajas de usar Sonar son mayores:

- Se sigue la evolución desde el inicio del proyecto (no de los últimos x builds)

- La información se muestra de forma MUY intuitiva (desde nubes de tags hasta gráficos de complejidad por módulo,clase y método)

- Sólo se ejecuta una vez al día. Nadie mira la calidad de su código después de cada uno de sus commits, pero me estoy encontrando que los programadores lo miran al día siguiente mientras se toman el cafecito de la mañana (más interesante que el Marca! ;-))

- Psicológicamente es brutal: la gente se PICA con lo que dice sonar de sus clases, y el que hace dos meses no sabía lo que era complejidad ciclomática, ahora evita los mega-métodos ;-). Además, tener una aplicación web que SOLO mide la calidad, demuestra al entorno la importancia que se le da en el equipo a hacer bien las cosas.

Si tu proyecto usa maven y hudson es "semi-gratis". De verdad, merece la pena, al principio pensaba que sólo externamente al grupo, ahora me doy cuenta que también internamente.

Salu2

Muy interesante comentario. A medida que las tarea...

2009-07-09T11:18:00.178+02:00

Muy interesante comentario. A medida que las tareas son más complejas se valoran menos. (Excepto cuando tu negocio depende de ello y no te funciona nada).

Yo alguna vez he visto en los clientes la siguiente actitud (cuando no son tecnicos):
- Comercial. (El amigo - se le puede pedir de todo que luego el hablará con los técnicos - muy bién valorado).
- Diseñador gráfico. (Un artista - bien valorado).
- Programador. (Esa persona que hace cosas raras y habla raro cuando le pido cosas y no me las quiere hacer - poco valorado)

Pero en otros campos ocurre parecido. (Telefonía, bancos, etc). Muchas veces le damos más importancia a como nos trata el comercial o como lo venden en la publicidad que como es el producto.

Conclusión, debes saber de todo de esta empresa y no solamente conocer sus comerciales, también sus productos y técnicos.

Saludos,
Jorge Rubira

Podrías publicar un artículo en javahispano sobre ...

2009-07-09T10:42:31.983+02:00

Podrías publicar un artículo en javahispano sobre todo sobre la parte final :)