Beware of 'Cobra Effects'

I recently read Primed to Perform and it got me thinking about 'cobra effects' in software teams.

Cobra effect is a term that refers to unintended, negative consequences of certain policies or incentives that were originally designed to improve things. This post explains the story that lead to the coining of this term.

Cobra effects are often hidden. When found, we tend to blame the people for bad behaviour instead of questioning our incentives or policies. Teams may even start to establish added controls and police the cobra effects. But this does not solve the root of the problem. Paying attention to how the systems, policies and incentives could create cobra effects could be beneficial.

Here are a few examples of cobra effects I've seen in some software teams:

Focus on bug count

Sometimes, teams may be tempted to incentivise testers for number of bugs found in the products. Though on the surface it sounds like a good plan to improve the product quality, it might lead to a few different problems like:

• not taking effort to prevent the bug from occurring
• focusing on reporting bugs and not on getting them fixed and improving the product
• creating different bug tickets for similar things that would have made more logical sense if grouped together

Focus on end-to-end UI test count

Testers check many for different scenarios while testing features. Test automation could be helpful to detect some regression bugs when the code changes. On the teams where testers are primarily involved in writing the end-to-end UI tests, they could be incentivised for writing more of those. On the surface, having more tests sounds like a great plan since having more tests is probably good. However, it could lead to a few different problems like:

• adding many different tests to the end-to-end test suite even though they could be better suited as a unit or integration test
• having duplicate tests at different levels due to focus on increasing test count
• having long test run times and debugging the test failures becoming difficult

Focus on number of lines of code changed

To promote building new features fast, some team could be tempted to incentivise developers on the basis on number of lines of code they add. On the surface, it could look like a good plan to motivate developers to build and release new features soon, but, it could lead to some issues like:

• effort spent in increasing lines of code instead of making the code more readable and maintainable
• prioritizing tasks that would change more lines of code over the tasks that could add more value to stakeholders with just a few smaller changes

Information hiding

On a few teams, there could be folks who have a lot of experience and information about the products they're building. The teams may celebrate them as "go-to people". It does seem like the appreciation is deserved, but, at times, it could lead to some problems like:

• people not conveying complete information to others so that they can continue having the "go-to person" status
• high dependency on a few people leading to lower team performance, and dissatisfaction among others

These are just some examples. Systems and processes may be the driving factor for such behaviour. Let's keep an eye out for such cobra-effects and create better systems and processes for our teams.