How collaborating early helps you deliver early

The finnish word ‘virta’ can mean at least two things. First, as we’re dealing with energy, it can be translated to ‘current’. It also can be translated to ‘flow’. This post connects with the latter, enjoy!

Image source: Virta Ltd.

What amount of testing is enough to ensure quality? How many testers per team would Assure Quality of our product?

It does not matter. Testing can only expose quality issues. Testing is inspection. Inspection cannot make the product better. If it did, then most of our efforts should be directed on inspection instead of actually doing quality work.

Code review is also inspection. It’s also kind of an industry standard nowadays to adopt a pull request-based integration model. In that model code review is done asynchronously. Reviewers review when they can, authors author when they ‘re on the task. This is a workflow that can simply cause us to spend more time creating products of inferior quality

The pull request model

After creating the pull request, the author has a decision to make. Will they take on another development task or should they just engage in the ping-pong of responding to comments in the pull request page. It’s a tricky decision. Lose the productivity on context switching or lose it by reacting to the reviewer’s questions and comments. Can’t win!

It’s not a good situation for the reviewer either. If we ignore the tiniest pull requests, there’s always work in getting an understanding of the context of the change. Why is this change done? Why is it done like this? What decisions do I need to understand to be able to help the author progress? And that’s the goal! We want to enable the author to make progress with their work.

So, there’s something to consider. In order to help the author of the PR to progress, we have to be available to complete the review quickly. This also means that the author must be available to work on the PR. If we fail to do this, we will destroy the productivity of both for potentially many days!

But, now we’re here, so what can we do? What things can we focus on the code review?

• Style issues? No, we’ve automated enforcing those things already.
• Syntactical correctness? No, we have static analysis and expect unit tests to exercise the code thoroughly.
• Logical correctness? Yes, but is it a reasonable ask to learn the context to be able to review the change?
• Share knowledge? Do you want to know? I don’t. There’s a mountain of more relevant details a knowledge worker has to deal with every day.
• Discuss solutions? Well, potential rework is cheapest when the work is not released yet, but it’s still rework. Back to square one, starting from the analysis. So it’s a no from me.
• Improve design? Yes, why not. If that doesn’t cause excessive delay and the reviewer is willing to join in on making the changes. Up until the point of merging the PR.

What does this leave us with?

• We can verify that appropriate tests have been created if we have expertise to do that.
• We can try our best at spotting logical bugs if we’re able to get a grip of the context in a reasonable time frame.
• We can try improve design if we’re ready to commit to pair programming with the author.

Yeah, it’s iffy even when we’re really trying our best.

Let’s do better with early collaboration

Here’s a workflow I’ll be happy to endorse:

1. Analyze the problem, together
2. Brainstorm solutions, together
3. Pick a solution with the most acceptable trade offs, together
4. Implement the solution, aggressively challenging the design at every turn to produce the best work you can, together
5. Test the implementation, together

Analyze the problem

How quickly do we have to react? How much effort does solving the problem potentially take? What’s the impact on our team? Do we depend on expertise of other teams to complete this? Do we really have to deploy code to have a positive impact?

Based on our observations we make decisions. Should we try to solve the problem or not? When do we contact the experts we depend on solving this?

Brainstorm solutions

One person can usually solve a problem in one or two ways. More people will find more ways to solve a problem. When there’s more than one person solving the problem, we get better solutions faster. Here, we rely on the fact that this group who is solving the problem, will be able to consistently come up with the best solution they’re collectively capable of.

Choose a solution

We pick the solution. We document the assumptions that go into our solution. We plan, what tasks go into making the solution complete. We also plan, how are going to integrate the change. What are the smallest pieces we can integrate while making steady progress, safely. What parts do we integrate first? How should we deploy the changes to deliver in a reasonable time frame while making the change as safe as possible.

Implement the solution

We implement the solution on top of solid foundations of our previous thinking. Here we actively look to write down our assumptions in to tests that will indicate to us when we’re ready to move to the next step. Test-first of course, because we want to make sure that we write the minimum required amount of production code.

Why is it important to write the minimum amount required? Because we need to be able to move in steps that we’re truly able to comprehend. We need to understand the impact of our change the whole time.

We practice ensemble programming, test-driven development, refactoring and continuous integration. We appreciate safety and speed. That’s why we use those practices. This is the way we build the quality in.

Testing the solution

Here again developers, QA engineers and business experts verify the expectations we have set on the functionality. We don’t always want to do this stage. Because we do continuous testing. We believe in building the quality in over inspection.

But once we’re here. We make sure that the QA engineer doesn’t have to figure out alone how to test the functionality. We do this together, because we want to learn together and make meaningful, steady progress all the time.

—

Now, we arrive to a situation where we all understand why we made the decisions we made. We have a shared understanding of the assumptions put in to the work. We have built the quality in. How would a code review from someone ignorant to the context, our analysis and design decisions help us in any way?

—

We have multiple development teams at Virta. The teams consist of all the different specialists required to deliver a quality product. Our teams organize the work in a way that serves them best. Our observations lead us to conclude that we get better results by working together. Maximizing the amount of feedback each step of the way. From an idea to release.