It was just another normal day at work for Roger.
Roger was working on a new side menu for the mobile web version of the company’s website. This was the 3rd overhaul in 3 months. Someone in the product team was really into side menus.
But Roger didn’t mind. He liked working on his side menu. He knew every line of code in it since he built it from scratch.
It was his baby.
The End of the World
Roger was about to take his coffee break as Jessica, his team leader, approached him.
“Roger would you mind taking a look at Ron’s open tickets? He apparently left a few issues open before going on vacation.”
“Sure thing Jessica, no problem.” Roger replied.
Roger lied. It was a huge problem.
You see the programmers in Jessica’s front end dev team had an informal agreement: “You don’t touch my code, I don’t touch your code, and everyone is happy.” This agreement held surprisingly well most of the time.
Jessica’s team seldom took vacations. They were all married with children and a holiday to them was much more stressful than coming to work. At work there was no crying, shouting and no one pooped themselves.
Those things only happened at work once when Barney the Jr. developer tried to configure webpack for the first time.
But that didn’t matter now. Because Ron messed things up. He took two weeks off just before a major release.
A two-week vacation with the whole family?! Ron and his wife lost their minds. They have three kids for god’s sake.
It was time for Roger to face the cold hard truth. He will have to debug Ron’s code.
Down the Rabbit Hole
Roger glanced for just a few moments at Ron’s open tickets. They didn’t matter right now.
The only thing that mattered was looking at Ron’s source code. Who knows what evil things lay lurking there.
Does Ron neglect semicolons on occasion? How many ternary expressions am I going to find? What is the max indentation level Ron’s callbacks reach?
These were the burning questions in Roger’s head. And he had to the get answers immediately.
“Always code as if the person who ends up maintaining your code is a violent psychopath who knows where you live” – Ward Cunningham
Roger started going over the source files. He tried to concentrate. But his thoughts kept racing.
Roger’s mind started looping. Like a broken record. “I didn’t write this code. This is not my code. What am I doing here?”
Roger’s forehead now dripping with sweat. He was a nomad in a foreign land.
There was no going back.
An Unhealthy Situation
I don’t know which type of code Roger would’ve encountered.
It could have been horrifying code that would have given you nightmares so bad that Freddie Krueger would feel the need to step in and say “Enough, this is too much.”
On the other hand, it might have been code so beautiful and elegant it read more smoothly than a J.R.R Tolkien novel.
Or anything in between.
But the truth is Roger had no idea what he was about to encounter. And that’s not a good thing.
Does it have to be this way?
The Good, the Bad and the Ugly of Implicit Ownership
When we develop a new feature, the rest of the company and ourselves tend to regard it as ours. Almost like it’s our property.
Open issues are assigned to us. Incremental feature updates are assigned to us. And if anyone has a question regarding functionality or technical details, they’ll naturally come to us.
This behavior doesn’t stop with the developers of a feature either. Implicit ownership is assigned to a QA and Product Manager of a feature if they’re involved as well.
Amy created something. Therefore, Amy is the owner of her creation. And Amy is the number one authority about anything that has to do with it.
This is human nature.
There are a lot of advantages to this natural approach. Every feature has its owner. An address.
But as we’ve seen with Roger’s dramatic adventure, there are dark sides to implicit code ownership as well.
The 4 Different Types of Code Ownership
What usually ends up happening is that every team ends up with their own culture regarding dealing with someone else’s code.
Individual team members have different “hospitality” preferences as well. Usually, it’s the senior developers who end setting the tone for the entire team.
Over the past few years, I’ve noticed 4 different types of code ownership attitudes. Some are extremely protective while others are very welcoming.
1. Trespassers will be Shot
This is the most extreme and rare forms of code ownership. But it does happen on occasion.
A programmer who creates who creates their own little kingdom and doesn’t let anyone get near it. This usually happens for one of several reasons:
- Job Safety Illusion – Feeling that if no one touches or understands their code, their job safety is guaranteed.
- Important Framework Illusion – They feel their precious code is so important and sensitive that if anyone else touches it, everything will collapse. This is of course wrong on so many levels. And if you unit test everything, it doesn’t even make much sense.
- Poor Social Skills – No one wants to talk to Aharon. Aharon is scary and mean. Everyone knows that if you touch Aharon’s code, he will make a big fuss about it.
I used to work with a guy who got an email notification every time someone would make a change in one of the several source files he actively monitored. Enough said.
2. Keep Off The Grass
This is probably the most common approach I’ve seen. Team members each have their own small kingdoms. But they do perform some fixes and enhancements in each other’s territory.
Left uncoordinated and unchecked, every developer has their own coding style. They’re consistent with themselves, but not with other team members.
That’s why when Marsha changes code in someone else’s territory, she makes sure she keeps the “laws of the land”. Her code resembles what she sees in the foreign source file.
Marsha will make as few changes as possible before returning to the safety of her own kingdom.
3. Mi Casa Su Casa
The approach where everyone feels at home throughout the entire project. It doesn’t matter who created what.
Everyone knows more or less what to expect every time they open a new source file. After a new feature is added, every team member assumes some level of ownership over it.
The benefits of this approach are clear. Any team member can take tasks related to almost any feature without significant overhead. Developers or QA outside the team can ask any team member a question about any feature and get an informed answer.
But this level of flexibility doesn’t come without a price.
The good news is that this cost is not that high and consists of following good ideas we should all be doing anyway:
- Unit Tests – Lot’s of unit tests. Preferably 80% or more coverage. When you know everything is tested it’s much easier to play around with someone else’s code.
- Linting – This helps to coordinate developer coding styles. A clear style guide is also important
- Editor Config – Helps to coordinate styles between different IDEs and operating systems.
- Design reviews – Letting everyone know what’s going to happen and how you plan on doing it.
- Code Reviews – Have at least one person aimlessly nod their head in approval while you show them your code.
- Attitude – The right attitude and the willingness to cooperate.
I like to think about this approach as the code ownership equivalent of working out 3 times a week.
It doesn’t sound too hard. It requires some dedication. And it needs a surprising amount of willpower to follow through.
4. The Junkyard
This is where we keep the trash. The entire set of source files consists of horrible code.
No one takes ownership or responsibility for this post-apocalyptic disaster of code.
This usually happens when a feature was poorly designed, or more commonly wasn’t designed at all. Or Maybe it happened because the original developer left the company without explaining to anyone what they did.
Regardless of the reason, there are some files everyone knows are the most shameful in the entire project.
Every time you introduce a new developer to them, you start a 2-minute monologue about why it’s all due to historical reasons. No one expected it turn out this way. And “please don’t judge us, we’re a good team who usually does things much better.”
United We Stand
We’re all human after all. That means we all have strong concepts of “mine”, “his” and “hers”.
And no one likes it when someone walks into their home with dirty feet and makes a mess.
Software is the most complex hand made construct humans have ever made. And one wrong move in the wrong place still brings down the websites of giants like Google, Facebook and Amazon on occasion.
But in spite of that, throughout history we as human beings did our best work and created the most amazing things by doing this one thing.
Work together in harmony.