What my father taught me about Jenkins
My father worked as an industrial mechanic. For more than fifty years, he practiced his craft with the passion of those moved by things other than the check at the end of the month. Wherever he was emploted at, the machines worked, the production improved and the team morale risen. I have learned a lot from my father.
Besides his pride of workmanship, two things have been constantly present along his career: the profound knowledge about how the system worked and applying inventiveness to address problems affecting the organizations he worked for. Even though he has never got formal education on them, his instinct made his day to day being governed by the engineering and lean principles.
At first sight, we might thing that the industrial mechanics and computing have nothing in common. I do not see it this way. The problems, frequently, are quite similar.
I recall a day when my father had a recurring issue at work. Sometimes, when a broken metallic part was being fixed, scrap metal went to the conveyor driving raw plastic to a mill system to be processed before it could be melt. As a result, the mills collected some significant damages and the whole plant needed stopping. For some time, the management approach to this problem was instructing the employees to be more careful. My father, I can imagine his facial expression, took a metal detector and some actuators and assembled a system that, put in a precise place above the plastic conveyor, stopped the pipeline before any piece of metal reached the mills (andon cord anyone?). Also, it activated acoustic and light signals to notify the team in charge what was going on. Obviously, it worked.
My father did not need a quick and easy tool that addressed all his problems. My father needed something that addressed the precise issue he was having in a very specific context, his context. A context that he was understanding perfectly and that, very likely, was not familiar to a lot of people outside the organization he worked for. These days, at work, we are deploying a new Jenkins-based, CI system. Like my father’s detector, it appears after there is an understanding of the system it will sit in (pursing profound knowledge); like my father’s detector, it is not trivial and it needs time and effort; like my father’s detector, once it is in place, it can be precisely adapted to the needs of the organization instead of making it move to match what an external supplier had in mind when addressing a similar problem.
Like my father’s detector, it has been a good decision.
From my point of view, only the profound knowledge about the system will enable you to decide on the tools you need. Sometimes, you will be able to use some existing ones; other times, you will need to adapt them and, every now and them, you will need to build your own tools. Some advice on this:
- Do not optimize early. If a solution states that it is quick and easy, it addresses a trivial problem or someone is lying or it was designed by Steve Jobs. CI systems solve inherently complex problems, I would try to be sure about what I am doing before I put something in place that may affect the whole organization.
- Do not limit your options. Delay your decisions until the last responsible moment, when you are more knowledgeable about the problem at hand.
- Identify your value stream and run away from those products or
solutions that hide it from you. Changes that create competitive
advantage lie in there.
In a nutshell, try to balance the perceived gains from avoiding non-core tasks, such as learning how to use a powerful tool, and the system understanding you get in return for being fully in charge your value stream.
Dad, thank you for that.