VisualVM OQL. Get size of objetcs between two size values

 select sum(map(heap.objects("[C"),function(heapString){
  if(sizeof(heapString) < 100 && sizeof(heapString) > 50){
    return sizeof(heapString);
  }
  else{   
    return 0;
  }
}));

Aprender las cosas como son

Cuando a alguien se le encarga gestionar el desarrollo de una aplicación (o parte de esa aplicación), su principal tarea es ver que falla de la tarea, como plantearla, como planificarla, etc.. y el gran problema es que el gestor esta obligado a hablar de asuntos tecnicos cuando se supone que un gestor "no debe saber nada" de tecnología.

Se debe abandonar los hábitos de poco esfuerzo (ser gestor y no querer saber nada técnico). No debe saber lo mismo que un técnico pero tiene que hablar el mismo idioma.

¿Como sabes que estas hablando el mismo idioma?
 - Si lo único que un gestor le dice a un técnico es "¿cuanto te queda?", "¿como vas?  y acto seguido le dice el gestor que le queda (se nota que no ha entendido la explicación de como va)". Esto es síntoma de que el gestor y el tecnico no hablan el mismo idioma.

Solución: Gastar tiempo del gestor y del tecnico y que el tecnico le explique al gestor como esta implementando la tarea. Ojo, el gestor nunca tiene que hacer "nada tecnico" pero debe ser capaz de entender lo que el tecnico le dice y ser capar de pedir cambios (en el idioma del tecnico).

Estimation by approach. Always usefull

Sometimes the project manager people think the agile methods cant be used in the projects developed by a traditional approach. The things are not always black or white, we can use agile methods for all kind of projects. For example, the estimation by approach, we can use it for estimating task in projects with a traditional way of work.

In addition, the estimation by approach is always the best way for estimating task if you want a real estimation. The one way for a real estimation is to know the time a developer have spent in some task. This is the great true and, in conclusion, the bes† way to estimate a task is to use the known duration of some task and use this duration for estimating other task.

The estimation by approach is very simple, if we know that a developer spend 3 days for completing a login screen and we suppose the list of costumer screen has four times the login screen size then a good estimation for a list of costumer screen is 12 days.

How you can see, we are using a estimation by approach without change the way of work. 

Desenredar los cables

Cuando has trabajado en varios proyectos de desarrollo de software de mediano-gran tamaño te das cuenta que la tendencia normal es que no exista documentación que te guíe por el código, los compañeros te ayudan pero como mejor saben (y cada uno a su manera), etc.. Esto hace que cuando se le pide a un programador que implemente sus primeras tareas este tenga la sensación de tener que "desenredar los cables" para poder empezar.

Al analizar esta situación en detenimiento, todo esto se traduce en muchos factores no deseados:

• Insatisfacción y frustración del programador.
• Costes de aprendizaje que se multiplican.
• Sensación de mala estructura del proyecto.

Siempre se debe tener un mecanismo de formación "automático" (quiero decir que no necesite de una tercera persona, es decir se le puede decir al miembro del equipo "toma esto" y con lo que se le de entonces puede formarse) para que un miembro del equipo pueda consultarlo y pueda usarlo como guia.

El procedimiento para tener un mecanismo de formación automático es tener una documentación técnica apropiada. Esta documentación tiene que tener las siguientes características:

• Estar escrita en un idioma de programadores. Lo cual garantiza que no se "hace larga de leer" y va directa al grano.
• Estar escrita en un formato cómodo de leer para un programador. Recomiendo una pagina web antes que un documento de texto.
• Que sea facil de mantener. Importante. Se debe mantener y que sea facil hacerlo ya que si no es facil de mantener entonces se abandonara.

Integración continua. Cuando lanzar las pruebas

¿Cuando se deben lanzar las pruebas automáticas? Existen muchas tendencias en función de un factor:

- Numero de cambios de código (Cada cuantos cambios de código se lanzan las pruebas):

• Ante cualquier cambio: Tiene la ventaja de que se detectan mejor los fallos pero tiene la desventaja de que puede relentizar el desarrollo ya que hace que el programador se centre demasiado en las pruebas.
• Ante cambios en una funcionalidad: Tiene la ventaja de favorecer el desarrollo pero si la funcionalidad es muy grande se corre el riesgo de no hacer las pruebas lo suficientemente buenas.
• ....

Como se ve a medida que se amplia el ratio se gana en velocidad de desarrollo y se pierde en calidad de pruebas.

- Tiempo (se establece un tiempo periodo de ejecución para lanzar las pruebas)

• Cada dia: Son pruebas bastante periódicas y pueden detectar un fallo antes. Lo malo es que es un tiempo fijo y corto y puede no tener en cuenta los ciclos de desarrollo (como un sprint de SCRUM)
• Cada fin de semana: al ser mas tiempo es mas facil que se alinien con los ciclos de desarrollo pero se tarda mas en detectar un fallo.
• ...

Como se ve a medida que se amplia el ratio se gana en alinear las pruebas con ciclos de desarrollo y se pierde en detección temprana de errores.

-...

Hay muchas tendencias y dentro de cada tendencia hay diversas opciones que pueden mejorar y empeorar un factor u otro. Es una locura entonces cual elegir. La mejor elección es no tener en cuenta los factores si no la que obtiene mejor resultado. Lo que sede hacer es elegir una tendencia y dentro de la tendencia elegir una opción, darle un tiempo y ver que resultados se obtienen. Si son malos resultados entonces probar con otra hasta que se de con la opción y la tendencia que mejor se ajuste al equipo y al tipo de producto.

Por que merece la pena arreglar las pruebas automaticas

Cuando se hacen pruebas automaticas sobre un software tiene el GRAN (e histórico) problema de que al modificar el software se debe modificar las pruebas automaticas y eso siembre se ha visto como una perdida de tiempo y un handicap para no hacer pruebas automaticas.

El problema es el enfoque, tener que adaptar la prueba automatica implica:

• Conocer como funciona la prueba (lo cual permite mejorar y ampliarla).
• Probar de una manera distinta a como lo hace el programador y tener mas exito en la busqueda de errores.
• Ya que se tiene que adaptar la prueba, se pueden crear nueva.

Se le debe dar este enfoque para que los programadores no tengan el problema de verlo inútil y aburrido. ¿Como se hace mas ameno una prueba? No haciéndola muy simple. Un ejemplo muy bueno es el siguiente:

1) Se cambia el parametro de la funciona suma de int suma (int a, int b) a int suma (int a, int b, int c).

2) Se le pide a un programador que lo cambie en 100 ficheros. 

Esto es aburrido y frustrante.

Sin embargo, si la prueba automatica tiene mas magnitud el programador lo vera de otra manera. Ejemplo,

1) Se cambia la interface web donde el usuario suma ahora 3 valores y no dos

2) Se pide al programador que cambie la petición html que prueba la pagina web que por debajo llama a la nueva funcion int suma (int a, int b, int c).

3) Ademas se le pide medir tiempos, aumentar las pruebas a 10000 iteranciones, etc..

Esto es mas desafiante y seguro que prueba mas el software que una simple prueba para llamar a un método.

El otro gran motivo es que al automatizar las pruebas siempre se descrubren errores de plantemaiento ya que te obliga a mirar el codigo desde otra perspectiva. Es decir, se pueden encontrar fallos despues de la famosa frase del programador: "yo he probado todo y funciona"

Problema con la filosofia Test Driven Development

Una de las mejores filosofías, al menos en teoria, para el desarrollo de software es la filosofia Test Driven Development (TDD). En resumen, la filosofia TDD consiste en que primero se crea el test y posteriormente se desarrolla el software que cumple dicho test. Esta filosofia tiene dos puntos muy fuertes:

•  Define los requisitos de forma mucho mas exacta que un documento de texto.
•  Una vez implementados el test y el software que cumple dicho test la automatización de las pruebas del software esta hecha también.

Parece ideal¿no? entonces ¿por que no se usa en todos los desarrollos? El gran problema es que un test automático (me refiero a un test que merezca la pena hacer) necesita que este muy "maduro" el desarrollo. 

Pongamos, por ejemplo, una web de gestión de usuarios. Un test muy obvio es "alta de usuario" pero para dar de alta un usuario seguramente se necesite:

• Base de datos
• Validaciones
• Autorizaciones
• Etc..

Estos conceptos se deben definir desde el principio pero a alto nivel, si se intenta definir hasta el ultimo campo de la base de datos, hasta el ultimo método del fichero de codigo que implementa la validación, etc.. solo se conseguirá gasta mucho tiempo (y dinero) en una definicion que se va a cambiar seguro.

Entonces, debemos olvidarnos del TDD? La respuesta es no. Lo que se debe hacer es adoptar esta filosofia en una fase mas madura del desarrollo y tener en cuenta que se debe facilitar la adopción de esta filosofia en la filosofia que se use para empezar.

what is wrong?

When a member of your develop team say to you: "we are developing in a wrong way. we have to change the develop strategy, but how? how do we have to develop? what is wrong in our develop strategy now?"

The unknow over the what are we doing wrong developing is the most common problem the develop team have to face. what should we change? the team? the technology? the whole app?!?!? when we know nothing about the develop problem but all the team know the develop strategy is wrong the most common solution is "to try to develop anything".

Marcar las reglas del juego

Las reglas de como se va a acometer el desarrollo es muy importante ya que pueden suponer la diferencia entre conseguir el objetivo (implementar el software a tiempo) o fallar completamente (no solo no implementar el software, ademas dar la sensación de que se ha perdido el tiempo y el dinero).

Hay que tener en cuenta siempre el objetivo principal, conseguir implementar un software que alcance el valor mínimo para el cliente en un tiempo determinado.

Los pasos normales para establecer las como se va acometer el desarrollo, como se va a estructurar los recursos del proyecto y que tiene que hacer cada individuo, es establecer una estructura y luego pedirle a los individuos (programadores, analistas, funcionales, responsables, etc...) que se adapten a ella. Este método parece lo mas lógico pero muestra algunos fallos:

• El método no tiene en cuenta las características individuales de cada miembro del equipo. El método puede parecer bueno sobre el papel pero ser lo peor si se analiza a los miembros del equipo individualmente.
• El método no tiene en cuenta la consecución del objetivo principal. El método puede parecer bueno sobre el papel pero no estar en nada alineado con el objetivo principal.

El gran problema es que sobre el papel algo parezca bueno ( pero no funcionar en la realidad) y los responsables no querer cambiarlo nunca. Si algo no funciona, va a seguir sin funcionar por mucho que nos empeñemos en hacer siempre lo mismo.

Si las reglas del juego no tienen en cuenta a los miembros del proyecto ni el objetivo principal del proyecto entonces los fracasos puntuales seran constantes. Cuando se suman muchos fracasos puntuales se obtiene un proyecto con dinamicas incorrectas y ambiente toxico.

La formas mas correcta es ver cual es el objetivo principal del proyecto y quienes tienen que acometerlos y establecer una estructura de proyecto acorde a estas características. 

Esto no significa que no se pueden incluir características formales para hacer una mejor estructura de proyecto pero aposteriori. Es decir, primero una estructura de proyecto que se ajuste a los miembros del equipo y al objetivo del proyecto y cuando este establecida y funcionando entonces se pueden incluir aspectos de mejora y los pasos necesarios para incluir esas mejoras. Por ejemplo, si quieres que todos los miembros del proyecto utilicen el ingles como lenguaje de documentación cuando los miembros del equipo no saben ingles lo mas incorrecto que se puede hacer es poner a los miembros del equipo a documentar en ingles y que "salga lo quesea". Es mas lógico que:

1. Que documenten correctamente en castellano.
2. Que aprendan ingles.
3. Que analicen la forma comun de documentar.
4. Que documenten en ingles.  

Son varios pasos, cualquiera puede fallar y dar a entender que la mejora no es posible.

Estos son los pasos correctos.

No dejes que la tarea se muera

Cuando le asignas una tarea a un programador el programador debe tener claro en que consiste, cuando debe empezar y cuando debe acabar. Esto lo tenemos todos bastante claro pero ¿realmente se cumple? En la mayoría de los casos no debido a factores como la perdida de motivación, a las prisas por terminar o al estar demasiado ocupado.

Al principio de una tarea es fácil planificar y determinar en que consiste una tarea pero una vez hecho esto el seguimiento se reduce a dos preguntas ¿como vas? y ¿cuanto te queda?.

El gran problema (ademas que la correcta definición y seguimiento de una tarea lleva su gasto en tiempo) es que el tiempo corre y al final hay muchas cosas que hacer antes del plazo por lo que hay que priorizar tareas y eso siempre deja en ultimo lugar al seguimiento y la retroalimentación de la documentación de la tarea.

Esto hace que el final de una tarea sea un acuerdo verbal entre el programador y el responsable. No se ha indicado como se ha terminado cada punto de la tarea que se estableció al principio, si ha habido cambios, problemas que han generado retrasos, riesgos, puntos que han quedado sin terminar, etc. En conclusión, se ha desarrollado código pero la tarea ha muerto.

No existe tarea sin todo lo que implica: definición, seguimiento, rediseño, etc. Mantén siempre el seguimiento, retroalimenta el diseño y la tarea en general con lo que va pasando, identica riesgos, deja anotado lo que alta por hacer, etc.

Es cierto, hay épocas de prisas y esto implica poner el foco en lo mas importante "picar" pero ten siempre presente que dejar que las tareas se mueran es una metrica de que el proyecto esta mal.

Ten piezas en el tablero

Hay veces en el ciclo de vida del desarrollo de un proyecto donde la situación parece que supera a todo el equipo (o no es por superación pero no esta claro que camino coger). Solo un par de ramas de trabajo parecen importantes y parece que sobra gente. En ese momento, al responsable del proyecto le entra la necesidad de quedarse solo con lo justo. En todo, tanto en lineas de trabajo como en personas. Sobre todo en personas.

No hace falta una situación critica, puede ser simplemente que parece que las personas encargadas del desarrollo de proyecto no están progresando nada por cualquier razón y el responsable tiene la necesidad de "reducir el problema".

Sea cual sea el motivo que lleve al responsable a reducir el equipo, hay que cambiar de idea y buscar otro planteamiento:

• Puede que el problema sea una liena de trabajo erronea
• Puede que se necesiten nuevas divisiones dentro del grupo
• Puede que los miembros del equipo necesiten formacion
• ...  

Hay que mantener el equipo de desarrollo. Ampliarlo si cabe. 

Como en una partida de ajedrez, puede que el intercambio de piezas te de la sensación de seguridad pero sin piezas te limitas el numero de jugadas, de opciones, de posibilidades... Puede que cueste coordinar mas a un grupo mas numeroso pero es el talento del conjunto lo que hace grande a un grupo no "el brillo se su parte mas reluciente".

El símil del cuadrado

Este símil viene muy bien para explicar de manera sencilla y rápida porque es necesario mas definición inicial (funcionales, requisitos, historias de usuario, etc..) para conceptos como:

•           Empezar un desarrollo software.
•           Empezar una definición de maquetación.
•           Empezar una definición de usabilidad.
•           Etc…

Opción A: Si se define claramente que se quiere un cuadrado (en el símil es el software, maquetación, etc…)

Las personas que tienen que hacer el cuadrado pueden dividirlo como mejor les venga para poder implementarlo

Implementar las partes por separado

Así al juntar lo implementado se tiene más posibilidades de que se parezca al cuadrado original

Opción B: Si lo que se hace es definir las partes suponiendo que al final se conseguirá un cuadrado

Cuando se junten hay muy pocas posibilidades de que parezca a un cuadrado

Prepara el Sprint

Tras el uso de la metodología Scrum en varios proyectos te das cuenta de que el equipo de desarrollo nunca va a ser responsable del desarrollo. El equipo, por lo general, esta formado por personas que solo quieren programar. No quieren tener una visión global del proyecto y no quieren hacerse responsable del trabajo de los demas.

Esto implica que al final se tenga un jefe de proyecto o un Scrum master o product owner mas parecido a un jefe de proyecto que al puesto que Scrum indica que debe tener. Si al final te decantas por usar Scrum pero con responsables entonces ten en cuenta varias cosas:

- Antes de la reunion de cierre de Sprint recuerda a la gente que lleven el estado de las tareas y el estado de lo que le quede sin finalizar preparado.

- Ve con el Sprint preparado a la reunión de definición del Sprint. Es decir, ya ten preparadas las tareas que tiene asignado cada miembro del equipo para el siguiente Sprint. En la reunión habla con los miembros del equipo de las tareas. En función de lo que se diga entonces se puede modificar. Pero llevalo preparado. 

Si estas ocioso propon un proyecto.

A todas las personas que hemos programado nos ha pasado que en algún momento de nuestra carrera hemos pasado periodos de estar ociosos completamente o casi completamente. Y estos periodos pueden durar meses.

Por lo general, el motivo es coyuntural: el proyecto entra en un periodo en el que se decide el rumbo que debe tomar, la empresa no tiene muy claro donde encaja mas tu perfil, el proyecto esta sobredimensionado, etc.. Pero sea cual sea el motivo, el animo del programador empieza a descender ya que aparecen sentimientos deprimentes: quieren que me vaya de la empresa, estoy perdiendo el tiempo, etc..

Puedes empezar a estudiar y a hacer cursos como loco de cualquier cosa y/o tecnología. No es mala solución pero si la situación se alarga entonces las energias que tenias para estudiar desaparecerán.

La mejor solución es que enfoques la situación como si tu jefe te hubiese mandado hacer una propuesta de una mejora completa del proyecto en el que estes. Por ejemplo, si trabajas en un proyecto que esta implementado en Java Structs entonces propon implementarlo con Spring Boot. Y no te quedes en un documento, implementa código.

Como abordar un problema concreto

Cuando se tiene se tiene que abordar un problema concreto (por ejemplo te piden que hagas una aplicación en Java o uses Docker para desplegar tu aplicación), se tiene que afrontar como una serie de tareas no ordenadas. Estas tareas se pueden dividir en dos:


- Tareas informativas: Son las tareas en las que adquieres conocimientos para formarte pero no da una productividad directa.

- Tareas creativas: Son las tareas que van a dar como fruto la solución al problemas que se esta abordando. Son las tareas que dan una productividad directa.

Por nuestra naturaleza humana, las tareas informativas son mas divertidas y enriquecedoras que las tareas creativas por lo que estamos mas predispuestos a abordar tareas informativas. Para que te estresen las tareas te recomiendo:

1º Haz la división del problema en tareas.
2º Identifica cuales son las creativas y cuales son las informativas.
3º A por las tareas:
3.a Un las horas de trabajo que estes en mejor forma o estes mas predispuesto aborda las tareas creativas.
3.b Cuando te sientas mas bloqueado o con menos ganas aborda las tareas informativas.

Casos:

1º El problema no tiene tareas informativas porque ya soy un experto: Es dificil de creer que no te quede nada por aprender (y mas en el mundo del software) pero lo que si que puedes hacer es (en la hora de las tareas informativas) abordar tareas informativas de otros problemas.


2º No tengo suficiente con mi horario laboral y sigo en la oficina despues de la hora o trabajo desde casa: Este tiempo debe ser completamente de tareas informativas.

3º Me quiero especializar en tareas informativas. No quiero hacer tareas creativas: Esta bien especializarse pero hay que ser franco, si solo te mueven las tareas informativas y no quieres hacer nada de creativas (o un numero muy bajo de tareas creativas) entonces existe un problema porque ninguna empresa te va a pagar para que solo te formes. La formación tiene siempre un fin productivo. Lo mejor que puedes hacer es buscar otras orientaciones como ser formador de otros profesionales.