Single responsibility principle (parte 1)

Este es el primer post para comentar a cerca de los principios SOLID, en esta ocasión nos enfocaremos en el principio de Single responsibility o Responsabilidad única (la S en SOLID), como ya comentamos en un post anterior los principios de son ciertas características (de diseño) que el desarrollo de software orientado a objetos debe de cumplir para que se diga que está bien estructurado y que ayuda a que el codigo sea entendible y por ende matenible, así que eso es lo que abordaremos en este post enfocandonos al principio de responsabilidad única.

Bien se dice por alli que el que mucho abarca poco aprieta, pues bien, esto llevado a la programación orientada a objetos es éste principio, en el que se describe que una clase debe de tener una única responsabilidad y no más que esa, como nos damos cuenta de que nuestra clase cumple con ella? pues esto es coo muchos dice, cumple con ella si es que tiene una única razon por la que tiene que cambiar, si es así entonces se dice que tiene una sola razón de ser y si esa razón de ser cambia por alguna razón entonces la clase debe de cambiar, pero sólo por eso deber de hacerlo.

Ahora este principio no solo se refleja en clases, sino en métodos, variables, paquetes, componentes y hasta sistemas, como es esto? pues bien, una variable debe de existir para solo una cosa, esto nos lleva a un buen nombramiento de la variable y esto es parte de clean code, esto es si se tiene una variable por ejemplo nombrada x que es de tipo Integer, en si el nombre no nos dice nada, por lo que estaremos tentados a usarla para lo que se nos antoje dentro de nuestro sistema, pudiendo usarla para almacenar la edad de un empleado, como índice para iterar el arreglo de percepciones del empleado (lo bueno es que ese arreglo no es muy grande jeje), etc. esto nos lleva a problemas muy graves de mantenimiento del código, lo que provoca que existan bugs, lo que provoca que nuestros clientes se quejen de lo que hacemos, lo que provoca que la empresa pierda dinero (o reputación), lo que provoca que se pierda la confianza en el desarrollador, lo que provoca que nos despidan, lo que provoca que nos atrasemos en el pago de nuestro lujoso carro (que sacamos a crédito augurando una buena carrera) lo que provoca... bueno, creo que ya di a entender el punto y todo esto por nombrar mal una variable, pero que pasa si a esa variable le nombramos employeeAge, pues ya sabemos que esa variable representa a la edad del empleado y estaremos menos tentados a usarla para almacenar algo distinto a la edad del empleado.

Si se dan cuenta, esta variable tiene una única responsabilidad que es almacenar la edad del empleado, ahora, esto aplica igual para métodos, éstos tambien deben de tener una única responsabilidad, por ejemplo el método que calcula los dias de vacaciones que tiene un empleado, esa es su responsabilidad, no la de ir a la base de datos por las reglas de vacaciones configuradas por el departamento de RH, ni ir a la base de datos para obtener la fecha de ingreso del empleado, este método sólo debe de hacer el cálculo y ya, no más que eso, en cuanto a una clase, pues como ya lo han de intuir, aplica igual ya que ésta solo se debe de encargar de algo en específico y delegar lo más que se pueda a otras clases que podrá usar o desde las que podrá ser usada para lograr un objetivo más general, en paqutes pasa lo mismo por ejemplo un paquete que tega las clases necesarias para la sección de nómina de los empleados que incluye clases para el cálculo, para extracción de datos, excepciones probables y demñas cosas que tienen que ver con la nómina, mas arriba, al sistema completo, que tiene que tener una resposabilidad única que es manejada por la gente de negocio de nuestra organización.

Últimamente se ha escuchado mucho sobre los microservicios, ellos son un ejemplo de responsabilidad única a nivel de deployable y de sistema pues de lo que se tratan es de que cada parte sea los mas independiente posible y tiene una responsabilidad muy específica llegando incluso a ser instalada de forma independiente a las demás características del sistema completo, teniendo su propia base de datos, su propio ambiente, tal vez hasta estar hecho en un lenguaje distinto a los demás y estar instalado en un servidor virtual en la india.

Pues bien, hasta acá le dejamos en la primer parte del Single responsibility principle, espero que se haya entendido de que se trata y que se puede extender mas allá a sólo clases.

En el siguiente post hablaremos de forma mas puntual de este principio con código de ejemplo y toda la cosa.

La meta

Hace tres semanas tenía pensado escribir acerca de La meta (el libro que acababa de leer) pero al empezar a escribir vi necesario decir cómo es que ese libro llegó a mi y eso me llevó a escribir sobre el reto que me había puesto de 1 libro por mes, así que borré lo poco que tenía y empecé a escribir acerca del reto, luego pensé que era difícil que entendieran ese reto si no hay un contexto, así que decidí empezar dando ese contexto y borré lo poco que tenía del reto y así fue que salió el post de la lectura, luego, la siguiente semana no escribí debido a que anduve algo enfermo de la garganta y luego la semana pasada acabó mi ciclo en Tralix, por lo que decidí escribir un poco sobre unos pensamientos que me llegaban mientras me alejaba del lugar que fue como mi hogar por poco mas de 8 años. Así que ahora si... hablaremos de "la meta".

La meta es un libro que llegó a mí por que Ana me lo recomendó, en ese momento dije "va, solo acabo el que tengo ahorita leyendo, luego el que tengo ya formado y ya luego lo empiezo, pero va..." así fue, terminé el libro 1 de caballo de Troya, luego the pragmatic project automation y empecé con la meta, cabe mencionar que tengo la mala maña de que cuando empiezo un libro lo leo desde la portada hasta la contraportada y me llamó la atención el tipo de comentarios que ponían en las primeras secciones, eso me dio curiosidad y ánimo para leerlo.

Solo haré un pequeño resumen del contenido, los que están en Tralix pueden ver con Ana si lo tiene disponible para préstamo, los que no, lo pueden conseguir en Amazon el el título de "LA META" o "THE GOAL" (para la versión en inglés). Este libro cuenta una "novela", donde se narran 3 meses de la vida del encargado de una planta manufacturera que a su vez es esposo, padre e hijo, que como muchos de nosotros tiene problemas por todos lados, es decir, ya no ve lo duro, sino lo tupido, Alex es en cargado de una planta desahuciada a desaparecer dados los malos resultados que da a la compañía, estos problemas acarrean a Alex a problemas con su pareja, de la que se separa por un tiempo, al inicio no sabe que hacer para salvar la planta hasta que recuerda una plática con su ex profesor de física de la universidad acerca de "la meta", luego él junto con algunos compañeros de trabajo y con ayuda de Noha (su ex profesor) van viendo cuales son los problemas de la planta y van viendo como solucionarlos llegando al final a ser una planta exitosa y Alex a ser ascendido, pero lo interesante no es esa parte de la novela, sino los conceptos que se describen y como llegan al éxito, así como el cambio de paradigma que proponen y es de esto de lo que me gustaría hablar en este post.

Primero, al leerlo me vi reflejado en Alex por que su vida personal reflejaba la mía de hace unos años y que creo que la mayoría de nosotros tenemos cuando tenemos que dedicarle tiempo al trabajo que debería de ser dedicado a nuestras familias y que llegas a la casa y en tu mente están los problemas del trabajo, buscando soluciones y no dejando disfrutar la vida fuera.

Luego habla sobre la meta de una compañía que es muy difícil de captar pero que al final de cuentas es ganar dinero, bajo eso como meta cada compañía tiene una forma distinta de llegar a ganar dinero, es allí donde se ve la dirección, las estrategias de cada sección, todo enfocado hacia eso, por lo que lo que sea que se haga debe de estar encaminado a esa meta, pero el problema es que muchas veces la forma de esa estrategia no es la adecuada, en el caso de la compañía de Alex, miden la productividad por sección, lo cual como se ve allí no es lo mejor, lo mismo pasa en muchas otras empresas, incluidas las de desarrollo de software donde a leguas se ve que no es la mejor forma de medir, ya muchos en ésta área han escrito de esto, llegando a estar de acuerdo en que la productividad de un desarrollador no se basa en las líneas de código que genera, o el tiempo que pasa sentado frente a su monitor, o la cantidad de bugs que resuelve, ni siquiera en la cantidad de features que genera... se debería de basar en la cantidad de dinero que ese nuevo feature le entrega a la compañía o en la cantidad de dinero que al solucionar el bug le está ahorrando a la compañía, es decir, en el valor de negocio EFECTIVO. Es aquí donde el concepto de contabilidad de costos tuerce el rabo, ya que no mide de esa forma, sino (en el caso de desarrollo de software) a cuanto tiempo le dedicas a solucionar un bug o a que hay mas? bugs o features? y eso  al final no es una métrica que ayude a "la meta".

Otro concepto interesante que mencionan en el libro es la fluctuación estadística, que es la variación que hay en hacer una tarea, por ejemplo el empleado A tarda 5 minutos en hacer una tarea, mientras que el empleado B tarda sólo 3 y el empleado C tarda 6, la fluctuación estadística es esa variación, que en manufactura puede llegar a ser algo estándar y controlable de alguna manera, pero en desarrollo de software es enorme debido a que es un proceso mas artesanal, intelectual, de feeling que un proceso mecánico, acá otro problema en el manejo de las empresas de software donde para hacer una tarea se piden tiempos fijos, escritos en piedra y firmados con sangre y que la gente administrativa, los vendedores, los directores no entienden y no ven como es posible que esas fechas nunca se cumplan teniendo que jugar con el triángulo de alcance, calidad y recursos, hay una corriente dentro del desarrollo de software que precisamente trata de atacar esto, que es no estimation.

Por último quiero mencionar otra idea interesante que se trata en el libro, que es que en términos de la meta, no necesariamente todos los recursos deben de estar produciendo todo el tiempo, de hecho esto es contraproducente... en términos de la meta, esto es, a veces (la mayoría de las veces) para llegar a la meta es muy recomendable que hayan recursos (materiales, maquinaria, equipo) y personas sin hacer nada, holgazaneando, echando la hueva, yendo a fumar, viendo los partidos de la euro, etc. esto por qué? por que de no ser así se causa un sobre inventario o una sobre carga inmanejable en ciertas secciones; esto, de nuevo, es algo que los managers no entienden y es uno de los cambios culturales más difíciles de hacer, ya que estamos acostumbrados a siempre tener a la gente ocupada (aunque no sea beneficioso en términos de la meta), haciendo algo, por que?, pues por que les pago por 8 horas de trabajo y no quiero obtener menos que eso, a esto le llamamos horas nalga, es decir, lo importante es que estés sentado frente a tu escritorio, pero como lo dice el libro y el sentido común, esto no es lo mejor, ya que si no ayudas a la meta, no tiene caso que lo hagas, por lo que lo mejor es que las cosas que se hagan estén bien pensadas y hay que aprovecharlas al máximo en términos de la meta. Acá en desarrollo de software esto se acrecienta aún más por que no sólo es que a veces es necesario que la gente no produzca, sino que como ya comentamos antes, es una actividad más parecida al arte que a otra cosa y esto implica que se debe de tener un ambiente adecuado para que fluyan las ideas y que el estado de ánimo sea el mejor para poder logra este fin, esto es, si es necesario que vean un partido de la euro para que el estado de ánimo sea el adecuado... hay que poner el partido de la euro y permitirles que lo vean sin problemas, pero esto, de nuevo, es un cambio cultural en el manager muy difícil de tener.

Ahora sí, por último, me llamó la atención cómo fue que Alex y su equipo se ganaron a un cliente muy importante, ofreciéndole entregas en partes de su pedido, con lo que pudieron cumplirle al cliente, ganaron dinero, se ganaron al cliente y le ahorraron dinero al cliente en inventarios, si, así es, hicieron sprints y entregas continuas, tenían reuniones de mejoras continuas, se enfocaban en darle valor al cliente ¿les suena?, así es, era algo muy similar a ágil, por lo que en la industria también funciona ( de hecho también existe esa corriente como "lean manufacturing").

En verdad les recomiendo ese libro, vale mucho la pena, como novela, como proceso de producción (introduciendo la teoría de las restricciones) y para los que estamos dentro del desarrollo de software, como marco conceptual del desarrollo ágil.

PD: Anita, muchas gracias por prestarme el libro, espero que cuando leas management 3.0 te sigan haciendo clic las ideas de la meta.

El titulo que importa

Ayer fue mi ultimo día en mi empleo anterior y mientras iba  caminando hacia la casa de mi  mamá para recoger mi moto iba pensando en lo que dejé ahí, una de las cosas que dejé es un producto estable el cual considero como mi hijo ya que estuve yo involucrado desde la concepción, pasando por su salida a producción, tuvo (como cualquier otro hijo) su tiempo de rebeldía en que no nos aguantó la carga gracias a la cantidad de usuarios que tenía, menosprecio de algunas personas hasta llegarlo a ver como un producto muy estable y que deja una buena cantidad de dinero a la organización, pero bueno esa es otra historia que contaré luego; otra de las cosas que iba pensando es en ¿qué le dejé a las personas?, en particular a mi tribu, a mi equipo de desarrollo, mis chavos... al final es muy difícil que yo lo diga pues eso es algo que ellos dirán o al menos lo pensarán (si algo les dejé o no) y de allí salió este post.

Hay que hacernos la pregunta ¿los títulos importan?, socialmente, me queda claro que importan, algunas veces me tocó que por que visto de tenis, pantalones rotos, cabello largo "despeinado" y barbudo como rey mago la gente no me tomaba tan enserio, hasta que por alguna razón llegan a preguntar mi puesto en donde trabajo y decía (con pena) "gerente de desarrollo" y en ese momento el  trato cambiaba, eso nunca me gustó ya que soy creyente en la igualdad y en el  valor de las personas sin importar como vistan, como se vean, donde trabajen o que puesto tienen pero algo me quedó claro, socialmente los títulos importan, lo  bueno de ser yo es que eso a mi no me importa.

Bueno pasando al tema real del post hay títulos que uno tiene solo "por que si" o por que un "tercero" te dio o por que las circunstancias así fueron como el título de jefe, el de padre, el  de marido, el de responsable del equipo de fut, cuñado, primo, hermano, etc, pero esos títulos realmente de algo sirven? o que peso tienen en nosotros y en la otra persona?. Bien pues en lo que yo creo que es mejor un título que alguien te "da" y que no tienes solo "por que si" en vez de ser jefe yo prefiero ser líder, en vez de padre yo prefiero ser ejemplo, en vez de marido yo prefiero ser su amor, en vez de el responsable del equipo de fut yo prefiero ser el líder,  en vez de ser el cuñado, primo o hermano yo prefiero ser el amigo; pero por que? por que creo que un título que te da "el segundo en cuestión" (como el título de líder) por convicción es muchísimo mas importante que el que te da un "tercero" (como el título de jefe) o el que se da solo por que así es como  se le conoce "socialmente" (como cuñado).

Por último, que peso tiene esto? bien pues lo que hace es que genera un compromiso mucho mayor y un apego  mucho mayor de las dos partes, por  ejemplo el titulo de líder hace que la gente te siga, que hagan las cosas no por que tienen que hacerla, sino por que están comprometidos moralmente contigo, porque saben que ese sentimiento de respeto y de confianza es mutua, por que lo hacen por ti y de esta forma se llega a una sinergia impresionante en que las dos partes hacen hasta donde pueden por la otra parte, por el "segundo en cuestión".

Bien pues espero que esto nos haga pensar en los títulos que tenemos en todos los ambientes en que nos desenvolvemos y queramos tener los títulos que en verdad importan.

Por cierto y ahora si ya por último, déjenme decirles que para mi el  título que mas vale, el que es muy difícil de ganarse,  pero que cuando lo tienes es lo  máximo es el título de amigo. Y a mis amigos... gracias por ello.


saludos.