Dos miradas sobre cómo presentarle a los clientes en qué se estuvo trabajando. Random Google Image Antes de comenzar quiero aclarar que en este artículo no estoy hablando puntualmente de una “Review meeting” tal cual plantean frameworks como SCRUM. Simplemente son dos formas de llevar a cabo una demostración del trabajo realizado a un tercero. Es razonable que cada tanto nuestros clientes quieran ver el progreso, así como también lo es, que nosotros, orgullosos desarrolladores, queramos mostrar en lo que hemos estado trabajando. No importa la metodología utilizada: si es ágil o no; si es por iteraciones cortas o largas; en algún momento debemos interactuar con el cliente para que éste…
-
-
Lo que quiero vs Lo que obtengo
¿Cuántas veces recibiste algo y te diste cuenta que no es lo que pediste?, o tal vez debería decir ¿… y te diste cuenta que no es lo que esperabas? Random Google Image Cuando uno avanza en su carrera es normal que le den la responsabilidad de coordinar o revisar el trabajo de otros. Este trabajo por hacer son los requerimientos del sistema en el que estamos trabajando y dependiendo de cómo sea el entorno de cada equipo, estos requerimientos pueden estar mejor o peor definidos, o más bien, mejor o peor documentados. Últimamente me suele pasar que lo que yo esperaba ver en el momento de la revisión no era…
-
Ser ágil es …
Si hay algo que aprendí en el último año es que la frase con la que titulé esta entrada es una de las cosas más difíciles de explicar que me encontré en el último tiempo. Estas semanas estuvimos hablando mucho en el trabajo sobre agilidad, equipos, ser ágiles, Scrum, etc; y algo que he notado es que cada uno interpreta diferentes cosas sobre el qué y el cómo. Y en general me es muy difícil explicar la “particular” mirada que tengo actualmente de lo que entiendo por “ser ágil”. Sacada de http://pragmaticprojectleadership.com/agile-mindset-deciding-work/ Hasta hace poco mi definición más corta para responder a esta pregunta era “ser ágil es responder rápido al…
-
¡No experimentes!
http://www.picserver.org/images/highway/phrases/experiment.jpg En las empresas de sistemas nos caracterizamos por ser mayormente gente analítica, matemática (por no decir “cuadrada”) y que tenemos muy presente el método científico. Sin embargo cuando vamos creciendo y teniendo más responsabilidades nos vamos encontrando un cierto rechazo o miedo a la palabra “experimento”. Hace unas semanas luego de volver del Agile Open Camp 2017 decidí que era hora de hacer algunas cambios en un proyecto en el cual colaboro más desde lo organizacional que desde lo técnico. Volví con un montón de ideas para mejorar la forma de trabajar del equipo, pagar la deuda técnica acumulada, ser más robustos a futuro y muchas otras cosas. ¡Es…
-
No dejes que tu código decida
O al menos no lo dejes decidir todo el tiempo 🙂 Una de las cosas más difícil de la Programación Orientada a Objetos es mantener el foco en generar un buen código y no perderse en la tentación de generar un mar de condicionales (a.k.a. if’s). Es este artículo la idea es mostrar al lector que es posible generar código que no contenga condicionales, o sea al menos que sean pocos. El problema con tener condicionales es que nos genera caminos alternos; cada camino puede tener su propia consecuencia; por lo que cada vez que queremos probar, debemos hacerlo por todos los caminos posibles. Si tenemos condicionales anidados la cantidad de…
-
Métricas para mejorar nuestro código
Unas de las tareas divertidas que me toca hacer durante el día es el Code Review de varios proyectos. Es una práctica que utilizamos a diario en Patagonian Tech porque nos permite ayudar a los más nuevos a crecer como programadores y a su vez a mantener los productos que desarrollamos para nuestros clientes con un nivel bajo de errores. Humor: posible métrica para evaluar el buen código. El otro día estaba haciendo un review a uno de mis compañeros, el código no tenía falencias en su lógica, tampoco en su sintaxis. Luego de mirarlo una y otra vez me puse a pensar que “sonaba complicado”. El fragmento de código en…
-
Minimizando dependencias en Android
Es común que cuando nos encontramos frente a un problema lo primero que atinamos es a buscar una biblioteca que ya provea una solución. Si bien es una buena práctica (Don’t repeat yourself) muchas veces esta solución trae más problemas a futuro que soluciones. Un caso particular que se suele ver mucho en Android es la necesidad de hacer la experiencia del usuario más rica, de darle más información en pantalla. Para ellos agregamos toda clase de detalles a nuestras UIs, y como escribir vistas desde cero suele ser complejo, terminamos incluyendo una biblioteca como dependencia seleccionada de alguna de las opciones populares. En general estoy de acuerdo con esa…
-
Pokemon Go — A Developer Review
No hay duda que Pokemon Go esta dando que hablar. Batiendo records. Haciendo a Nintendo super rentable etc. Pero no vamos a hablar de eso si no de la parte técnica. ¿Tan bueno es? Lo bueno Empecemos hablando por las bondades del juego. Es entretenido! :), apela a la nostalgia de una generación que jugó a los viejos juegos o veía los dibujos animados mientras merendaba. A nivel técnico el juego no me ha dado mayores problemas. La interfaz es bastante intuitiva y simple. Vamos, no hay mucho que hacer más que caminar y tirar unas pelotitas (a.k.a Pokebolas :). Lo malo Para mi que venía jugando Ingress, otro juego similar de la…
-
“Funciona” no es suficiente.
No es raro en esta profesión, al revisar el trabajo de otro encontrarse con algo que no es del todo semánticamente correcto o que puede escribirse de mejor manera. Tampoco es raro que nos digan “pero así funciona”. Funciona no es, o no debería al menos, ser suficiente. En el desarrollo de software existen muchos otros factures a considerar a futuro que no siempre tienen que ver con el funcionamiento actual de la aplicación : ¿el código se entiende?, ¿es eficiente?, ¿es fácil de extender si debemos agregar funcionalidades?. Quizás el aspecto más importante desde el punto comercial es que tanto cuesta corregir un error detectado, ya que en códigos escritos…
-
Hacer Aplicaciones Android Mantenibles
Una de las cosas más complicadas a lo largo del tiempo es poder mantener el código fuente de una aplicación Android en un nivel de simplicidad que nos permita a futuro introducir nuevas mejoras, arreglar errores de manera más simple o solamente poder leer el código y decir “ah, si, esto es lo que hace acá”. No siempre lo logramos, ya sea por impericia (todavía no sabemos hacerlo mejor) o por tiempo (nos apuran y en lugar de pensar la mejor manera simplemente escribimos el primer código que se nos ocurre para lograr sacar en tiempo la aplicación). En general los problemas de impericia se solucionan con capacitación, lectura y…