Reclaiming ownership in the development team

My previous post (How to fix it being the bottleneck) explained how we started a small transformation of a development team using Trunk based development. The post triggered some people around me to explain more about how they can apply that on their own team.

A bit of my history with software development

I remember my first days as a developer building a website/application in a team with 6, with no sort of version control system, just changing the files directly into the production server via Dreamweaver. There were no tests or any quality control. What a time :D

Because of that, we introduced a lot of problems which disrupted the daily work of many people that depended on that software to do their work.

Our manager grew worried about all that, his job was on the line and he did what a lot of us would do. At least considered doing it.

1. Hired a tester to make sure this problem would not happen again.
2. All the code needed approval by Quality Assurance before going live.

That is a logical decision for that kind of problem. The wrong one, though.

Why might that be the wrong approach?

It is very hard to foresee the meaningful impact of this change. As our environment has changed, our behavior changed slowly which also shaped our mindset.

The positive side of it. Fewer bugs were reaching production. That is a big win that nobody can deny.

The negative side of it? Glad you asked.

Even though fewer bugs were reaching production, more bugs were reaching the QA. Now we also had a list of bugs (some refer now to a backlog of bugs). Our tester was becoming the bottleneck to bring code to production.

Now think for a second. How would you solve this additional problem? The way we solved, we hired another tester. Because that makes sense!

With a second tester, the “bug backlog” never got cleared, and the input never slowed down. Very much the opposite. As an addition, we started having endless discussions about how many QA people we need compared to the numbers of developers.

Another way of solving this problem?

Fast forward a bit, I moved to a new employer that had the development process more mature and based on “best practices”.

Those guys used Git (a version control system) with GitFlow (is a branching model for Git,) and did code review in every commit. When the team explained to me all the benefits of this approach, they sold me. The way to Valhalla.

But then, I started noticing several other problems that started irritating me.

1. For very unimportant changes that I was 100% sure that could not affect production, I still needed review and approval from someone. I had to bother people to review often. What resulted in three outcomes.

• People were accepting my changes without looking at them, so they could go back to do what they were doing.
• I was packing a lot of changes in one request.
• It was still not preventing bugs

2. Another problem I saw was merge conflicts. The developers were spending a lot of time fixing those conflicts. I am sure you know a few “solutions” for this problem. You might think:

• Did you try committing in smaller batches?
• Did you try organizing work so developers would not touch the same part of the system?

We haven’t touched the biggest problem that hides in all of those solutions. The delay to bring any solution to production. But that will be another post.

How you should solve the problem

Trunk Based Development is a simple concept. The project has only one branch. All the developers commit to that single branch.

I started doing TBD when I was working on my startup, and my Co-founder was constantly asked me to test his functionalities. I no longer wanted to be checking his code, and we did not have money for a tester. I suggested TBD for him and we gave it a shot.

The first two weeks were horrible. We did not have a magnificent set of automated tests and many bugs were going through.

But then the magic happened, our behaviour changed.

• We read our code more often and try to test it more before committing.
• We got more interested in automated testing.
• We checked the production environment ourselves after every change
• We got more interested in different ways to monitor the application

Excuses I hear for not doing Trunk Based Development

• We don’t have automated tests
• We don’t have a good coverage of tests
• Our developers are not in the level to do that
• Our team is not ready for that
• No four eyes principle/code reviews

Trunk Based Development will force you to improve in those areas, it is the environmental change that your team needs.

How do you start?

1. Keep only your master/trunk/main (whatever you called it) branch
2. Commit/Push smaller changes.
3. Commit/Push often

It’s that simple

Last thoughts

With the QA, code-reviews and pull request to protect bugs to reach production, we created a much bigger issue. We shifted the responsibility and accountability of the developer that was building the code to someone else.

We made it harder to experiment with functionalities and shifted the conversation to less important things that only made the system more rigid.

If you are a developer invite your team to try (over 2 weeks please :)), take back the control and own your craft.

If you are a manager, give them the chance to own their own responsibilities.