Hero culture and curling

Filed under: Culture, — Tags: Configuration management, Curling, Merge, Scaling — Thomas Sundberg — 2013-06-30

What is the problem with one hero that always solves any problem? One answer is that those who get problems solved never learn how to deal with the problem and solve them. What is the problem with this? One answer is that you build an organization where the bus count is one. One person always solves any issues and the organization doesn’t know how to do it. When this person steps out in front of a bus and doesn’t show up at work, then there is a real problem.

A concrete situation I recently have experienced is an organization where some development is done in branches. All changes need to be merged to the main development line when the development is done. The question is, who should do the merging? There are two different answers to this question. You might think that the obvious answer is: those who did the development. Another answer may be a configuration manager, CM, who feels a responsibility to always know if there are any merges not done. What is correct depends on who is assumed to be responsible. My opinion is that the person who did the change is responsible for making sure that the change survives a deployment from the main line. In other words, the person who did the change is also responsible for doing the merge to the main line.

The situation gets weird if the person who did the change isn’t responsible for merging to the main line. If a CM is responsible for performing the merge, is he also responsible for all changes? If that is the case, why do we have developers that write code and commit it to the version control system? The CM was responsible for merging all the changes. Any change that is created may create a merge situation.

The CM should perhaps look at branches and notice that there are unmerged changes. The reaction to this should be to inform those responsible that they have missed to do their job. I have heard an argument that is easier and faster to do the merge in this situation instead of informing those who yet have work to do. That may very well be the case, but what signal do you send if you do the job? You send the signal that somebody else will pick up your trash and clean up after you. This is not the signal you want to send if you don’t enjoy being the cleaner.

The signal you want to send is that the one who did the change is responsible for finishing the job. Finishing the job means making sure that any changes survives the future.

I think this situation is similar to how you should raise your kids. Parents can either always clean after the kids or they can teach them that they have to clean after themselves. A kid who never learned to clean after playing with some toys will grow up and become an adult that cant´ cope alone. So being a nice parent and always curle (as in curling) for the kids will not do the kids any favours, it will do them harm.

Not allowing your developers to be in charge and do their own merges will do the same thing for a project. It will create single point of failure in the hero that always does the merging and it will not scale. One person can only cope with so many branches and after that, they will start to slip and become the bottleneck.

Make sure that you do all you can to avoid a hero culture with one hero that always solves the problems. A concrete example is to expect the developers to do their job, possible verify it from time to time, but always expect them to do their job. That will remove a part of a hero culture and it will be possible to scale.

Resources



(less...)

Pages

About
Events
Why

Categories

Agile
Automation
BDD
Clean code
Continuous delivery
Continuous deployment
Continuous integration
Cucumber
Culture
Design
DevOps
Executable specification
Git
Gradle
Guice
J2EE
JUnit
Java
Javascript
Kubernetes
Linux
Load testing
Maven
Mockito
New developers
Pair programming
PicoContainer
Presentation
Programming
Public speaking
Quality
React
Recruiting
Requirements
Scala
Selenium
Software craftsmanship
Software development
Spring
TDD
Teaching
Technical debt
Test automation
Tools
Web
Windows
eXtreme Programming

Authors

Thomas Sundberg
Adrian Bolboaca

Archives

Meta

rss RSS