Dr. Neil's Notes
Software > Development
Don't Gamify My Craft
Introduction
There is a behaviour happening in the business world, and that includes the software industry, that I am not convinced drives a good outcome for customers.
The software product experience
Software is a product that, when created well, delivers a beautiful experience for the people that work with it. I am sure you can think of a digital experience you have had that felt magical the first time, and still leaves a feeling of satisfaction when you use that product again. At the same time I imagine you have had many more average experiences with products, that leave you wondering what the people who built that software were thinking.
One thing I can say with certainty, great experiences in a software product do not happen by chance. Great software is designed that way. The people building that software have an experience they want to deliver, and they work hard to ensure the customer gets the desired experience. There is a sense of craftsmanship that the developers and designers put into the product with the aim of delivery of a product they can be proud of. Telling people 'I worked on that' when someone enjoys the product is highly satisfying.
I have a theory that I want to share here, the gamification of a craft acts in opposition to pride in the work you do. The type of person that wants their work to be gamified, is the type of person that is less likely to have pride in their work. How can I say that ?
Someone that has pride in the deliverable they are creating, is not doing it for points, they are doing it for their own satisfaction, and the experience of their customers. The output from a person is directly represented by the motivations that drive the deliverable. The output from a team, directly reflects the motivations of the team.
A product delivered by a person, or team, motivated to get points in a game system, will reflect that motivation in the experience delivered.
It is entirely possible for a product to deliver a great experience, while the people building it also can get points in the game they are playing. However, there will always be circumstances where a decision is going to be made to either focus on getting points, or delivery of an experience.
Collecting Treasure or Cleaning the Kitchen
One of the challenges with gamifying a system is that you have to account for all the things people do not want to do. In order to encourage people to do something they might not otherwise do, a points system is created that will reward a person for doing that task. If the system does not cater for a scenario, then in the game world, there is no benefit to performing a task in that scenario. On the other hand, when a person is motivated by doing something that leads to a good outcome for the product they are more likely to tackle the tasks that are uncomfortable, or less desirable. Let's look at a simple example situation. For the sake of this thought experiment consider this approach is taken from the start of a new project, so there is not debt to pay (in the real world there is always outstanding debt in terms of software already delivered needing to be supported).
Each developer gets measured by how many features they complete (+10 points each), and how many defects get attributed to code they create (-1 point for each defect).
There is a strong incentive to finish features, and make sure they have a low number of defects found. This sounds like a great setup initially, and I can imagine managers signing off on this system to measure the developers. Some managers would get excited enough to set up a leader-board and start driving competitive behaviour to be delivering the most features and the least defects. What could go wrong ?
What is the incentive to make the code more maintainable over time ? As a developer you would have no motivation to do a large refactoring of the code in order to reduce the complexity. In fact, as long as you are one of the few developers that understand the complex code, you are going to want to make the code more complicated over time. More complicated code will slow down the other developers from getting feature points, and if you feel confident you can work with it, then you can get more points by delivery of more features and less defects.
What happens all too often is that people who should be on the same team start competing with each other. This is not good, as sabotage is often a great strategy to ensure a competitor fails. If you want to stay near the top of a leader-board then it is smart to make it harder for the people lower on the board to succeed. If you are near the bottom of the board then a great strategy might be to spend time each day looking for defects in the code of those that have the highest scores. Even better would be to build something that causes a defect to start appearing in their code and not yours.
Something to consider at this point is what is the objective of each developer in the team? They have stopped caring about the product and instead now care about the points they are getting. The product produced will reflect this.
Building Great Products is a Team Activity
If your objective is to deliver a great product, then you need a great team. Great teams, deliver great products. Attributes of a great team include an alignment of goals within the team that match the goal of the product. If team members are competing with each other, then they cannot work well with each other to deliver the best product, as a combined force. The output of a group should be greater than the output possible from any single individual, in that group. Solutions generated by a group should bring the combined intelligence of the group to solve problems. A great team consists of individuals that work together to build great products.
Created: November 9, 2020 08:56:01