jueves, 16 de octubre de 2014

La felicidad como pilar para lograr efectividad.

El ser humano no es feliz al obtener logros. Al contrario, logra grandes cosas cuando es feliz. De esto se trata esta presentación. De un conjunto de técnicas que te pueden ayudar a ser mas feliz y de como la felicidad beneficia increíblemente la efectividad de las organizaciones. 

Esta presentación se relaciona con una entrada que publiqué hace varios meses titulada "The happiness Advantage".

viernes, 10 de octubre de 2014

Desarrollador de software. Mucho mas que código fuente

Hace poco uno de mis estudiantes me pidió que le recomendara algunas cosas para convertirse en un mejor desarrollador. Esta entrada es mi respuesta para él y refleja mi posición respecto al conjunto de habilidades tanto técnicas como soft skills que conforman un buen profesional del desarrollo de software.

Considero que un desarrollador va mas allá de ser la persona que escribe el código fuente. Es la persona que materializa los deseos de sus clientes. 

Quien programa construye producto y un verdadero producto esta conformado por sus características funcionales, atributos de calidad y los elementos tecnológicos necesarios para construirlo entre ellos la infraestructura y el código fuente. 

Articular todos estos elementos es una tarea compleja que requiere conocimiento y habitualmente este se encuentra segregado en diferentes personas de modo que el trabajo en equipo, y las habilidades de comunicación se convierten en elementos indispensables para cumplir su labor social.

Hacer software es un trabajo de comunidad, de apoyo mutuo y de mejora continua. En torno a esto, construir software que entiendan otros seres humanos es de gran importancia para lograr cultura de colaboración. Las siguientes practicas y herramientas pueden apoyar la necesidad de construir software mantenible.

  • Code Smells: Una recopilación de malas practicas de programación.
  • Patrones de refactor: Un conjunto de soluciones a problemas comunes de mantenibilidad y que pueden ser aplicadas en determinados contextos. Martin Fowler es referente en este tema. Es recomendable visitar la pagina web http://refactoring.com/, leer el libro Refactoring. Improving the design of existing code y Refactoring databases. Evolutionary database design
  • Análisis estático de código: Herramientas que nos apoyan en la identificación de malas practicas de programación. Algunas de las mas comunes son: Sonar Qube, Check Style, PMD, Find Bugs.
  • TDD (Test Driven Design): Es una practica de programación cuya aplicabilidad garantiza código de mejor calidad (Pues todo el el tiempo el código se prueba) y un diseño mas simple.
  • Principios SOLID: Un conjunto de principios que apoyan la construcción de un mejor código fuente.
  • Patrones GRASP: La asignación de responsabilidades es uno de los factores que mas influencia la escritura de código fuente limpio.
  • Clean Code: Un muy buen libro de Robert C. Martin.
  • Coding Standards: Los estándares de codificación varían dependiendo del lenguaje de programación. Acá están los estándares de Java.

Por otro lado hacer código mantenible no garantiza el éxito del producto pues la mantenibilidad se centra en la forma como se estructura el código fuente mas no en los elementos de ejecución. Por esta razón es muy importante conocer conceptos como el manejo de Threads, Programación MultiThread, Agents, profiling, sincronización, Dead Locks, o cualquier otro elemento propio de cada lenguaje o estilo de programación.

También es absolutamente importante que quien escribe código fuente tenga un buen conocimiento en patrones de diseño de cualquier tipo (Siempre serán de gran ayuda) ya sean GOF, JEE, etc.

Hasta ahora tenemos un conjunto de elementos que nos pueden apoyar en la realización de código mantenible y que tenga un buen comportamiento en tiempo de ejecución pero falta algo mas. Aunque no sea su área de experiencia, todo desarrollador debe tener conocimientos aun siendo básicos sobre arquitectura de software, esto le permitirá tomar mejores decisiones y no limitarse a construir con base en la restricciones que otra persona define. En torno a este tema recomiendo un muy buen libro N-Layerd Domain Oriented Architecture Guide with .Net 4.0. Aunque esta basado en arquitectura Microsoft es un muy buen referente de estilos arquitectónicos Layer y puede ser bastante ilustrativo.

Pero aun no es suficiente. Para que todo esto se puede articular en producto construido son importantes dos cosas:
  1. Conocer el paradigma de programación. Ya sea programación procedimental, declarativa, orientada a objetos, funcional o cualquier otra. Es muy común ver programas hechos en scala (Con programación funcional) que en su construcción son orientados a objetos. Al hacer esto no solo se pierde todo el poder del paradigma sino que terminamos construyendo productos innecesariamente complejos.
  2. Conocer el lenguaje de programación: Lenguajes de programación hay muchos, cada uno tiene sus ventajas, desventajas y características especiales que al ser aplicadas de forma correcta nos permiten lograr grandes cosas.
Recomiendo los siguientes libros para quienes quieran profundizar en los conceptos que permiten garantizar software mantenible que promueva unos buenos niveles de servicio con el  paradigma de Programación orientada objetos y Java
Y algo que les permitirá conectarse con el software como producto: Libro Lean Mindset. Ask the rigth Questions

Espero que esta pequeña entrada le sea de utilidad a todos aquellos que quieren hacer del software un producto. Aquellos que quieren ir mucho mas allá del código fuente

viernes, 3 de octubre de 2014

Architectural Kata - Procesamiento de facturas

Kata

Una aseguradora de vehículos tiene un área dedicada a recibir las facturas de las entidades a las cuales acuden los usuarios para hacer uso de los servicios (Talleres, Proveedores de servicio de grúa, etc). En este momento reciben aproximadamente 10.000 facturas al mes las cuales deben ser digitadas en un sistema de información, auditadas y posteriormente pagadas. 

Un usuario puede hacer uso de los servicios solo si tiene una póliza vigente con la entidad aseguradora y dicha póliza cubre el servicio que le van a prestar.



La dirección del área desea que las facturas cuyo valor sea menor a $150.000 puedan ser pagadas de forma automática con el fin de reducir la cantidad de trabajo operativo. Para esto exigirán a las entidades prestadoras de servicio que envíen la información de las facturas a través de archivos de texto, de esta manera se podrán hacer cargas masivas de información, se aplicarán algunas reglas de negocio para determinar que las facturas se puedan pagar y finalmente se realizará el pago a la entidad. 

Resuelva

Diseñe la arquitectura mas apropiada para solucionar esta problemática de negocio. Especifique que asunciones se tomaron para realizar dicho diseño y especifique por que esta arquitectura apoya la estrategia de negocio.

miércoles, 1 de octubre de 2014

DevOps como habilitador de continous delivery

Les comparto una presentación que hice hace poco. Esta habla un sobre DevOps y su gran influencia para lograr procesos de continous delivery de software que dinamicen y apoyen la evolución de los negocios.

Este será el tema sobre el que estaré hablando en Barcamp Medellin 2014 y Agiles 2014


DevOps Rompiendo barreras

Les comparto la presentación de la charla que tuve la oportunidad de compartir en EAFIT en octubre de 2013