Optimise for Happiness
Following is a story, a real incident, that Peter Drucker mentions in his book Concept of the Corporation.
During the World War II, workers in an aircraft plant were displaying “bad morale” and doing “slipshod work”, as workers had never seen any of the planes they were producing, had never found out where the part they worked on fitted, and had never been told how important this part was to the total functioning of the place.”
So a big bomber got brought in for employees to see. The workers were invited to inspect it, to sit in it and to bring their wives and children along. When finally they were shown the part they were making in the bomber, and its importance was explained to them by a crew member, the bad morale and unrest disappeared at once.
In other words, these workers suddenly got the benefits of clarity, concreteness and purpose — all of which are essential to provide if you want something from someone.
Chad Dickenson, CEO of Etsy, talks about how they Optimise for Developer Happiness by “making it easier to ship”. In the same talk, he mentions how Continuous Deployment helps them to achieve the same.
The biggest puzzle — Connecting the dots
In our excitement of using the latest, cool frameworks or technologies, we sometimes forget our poor users. By creating a system for the team to connect to the end users, this trap can be avoided.
The following questions help us to connect the dots:
- How do our users feel when they use the product or feature we built? What emotions do they go through?
- How can we make them happy by making it easier to use?
- How can we continually make the users happier?
By making it easier to ship, the software developers should be able to concentrate on the above questions and improve the product further. In the end, the only thing that matters is the value we deliver to our customers.
Deployment Pipeline
So how do you optimise for developer happiness? We need a system for the smooth flow of code from development to production. You can visualise it as a pipeline.
Deployment Pipeline kicks in when someone commits to the repository. The stages in the pipeline changes depending upon the team. For example, some teams might have staging environments. Others may have automated security or performance tests.
It should be optimised for flow to avoid the code getting stuck every once in a while. The bottlenecks for this free flow are:
- Code Branching — merging of multiple branches for deployment
- Lack of automated tests
- Lack of automation for deployments
The right Continuous Integration setup with Mainline development takes care of the first. The rest is simple enough to understand, i.e. test and deployment automation.
For a greenfield project, it might be easier to get started in this way. But implementing this for a brownfield is not easy. So the question is where to start?
The first thing is to have a visualisation of the pipeline even before implementing it. Lookout areas where the flow gets interrupted. It usually gets stuck where there is no automation.
You cannot automate everything on day 1. And don’t expect to fix all the problems overnight. It takes time and needs to be balanced with the product delivery too. It is not easy, but take small steps, and eventually, it will reach a much more automated pipeline. If it brings in happiness, why not invest in the same?
Start with automating critical paths. For e.g., use tools like Diffy while parallelly adding unit tests for the newly added code.
Boy Scout Rule helps to bring in improvements resulting in significant improvements over a period.
Having a deployment pipeline gives the team enough time as the releases/deployments are painless. It also creates enough base for a team to have an environment to interact with the end users.
Extending this pipeline to connect to the end users through monitoring and alerting, brings in the happiness to the cycle.
Further References
Originally published at www.multunus.com on April 25, 2017.
