WEBVTT

00:00.000 --> 00:08.880
All right, okay, let's go.

00:08.880 --> 00:18.120
So, I want to make the case for non-blocking code reviews as opposed to the classic commonly

00:18.120 --> 00:21.920
accepted pull request model.

00:21.920 --> 00:26.560
Just to be clear, I don't question the pull request model in the open source world.

00:26.560 --> 00:31.640
It has value for the open source world because it solves the trust issue.

00:31.640 --> 00:40.880
I do question it in the corporate environment where I think it has no value at all anyway.

00:40.880 --> 00:50.120
So, back in 2012 quite a long time ago, so it's only recently I've started speaking about

00:50.120 --> 00:51.120
this.

00:51.600 --> 01:01.200
I had the opportunity to start a coaching mission to upscale the engineering skills of a

01:01.200 --> 01:03.680
rather than of a steam.

01:03.680 --> 01:07.200
Luckily, I wasn't alone doing that.

01:07.200 --> 01:15.080
We were two coaches and was my friend, Martin Van Aiken and myself, which makes things

01:15.080 --> 01:17.040
more easy.

01:17.040 --> 01:24.680
So when we arrived with this COVID situation, we didn't expect to still discover in 2012.

01:24.680 --> 01:28.080
No version control wasn't in place.

01:28.080 --> 01:29.080
Yeah.

01:29.080 --> 01:34.320
So first thing we did was introduce certain control systems, and I thought like, yeah, well,

01:34.320 --> 01:40.840
get this maybe a better bridge too far for a team that never used any version control system

01:40.840 --> 01:44.920
while the whole idea of having a remote-reap or a local repo, when you commit it's not in the

01:44.920 --> 01:47.600
remote repo, it was like mind-blowing.

01:47.600 --> 01:50.920
So I suggested we'll go for a subscription.

01:50.920 --> 01:57.400
Because it was said that while branching and subversion is difficult, complicated, I also

01:57.400 --> 02:00.920
suggested we use no branches at all.

02:00.920 --> 02:08.200
Everyone is going to commit straight into the main line, well, strength for a subscription.

02:08.200 --> 02:13.600
And that went pretty well because while the second thing we introduced right from the start,

02:13.600 --> 02:20.800
and that was the practice of continuous integration together with team commitment that any

02:20.800 --> 02:25.280
change had to be covered by not made the best before the unit test.

02:25.280 --> 02:31.880
Now, because the team was nervous, well, we wanted to have some mentoring in place.

02:31.880 --> 02:35.600
And bare programming was difficult.

02:35.600 --> 02:42.560
The team was not particularly open to the idea, although we did some pairing from a coaching

02:42.560 --> 02:45.760
perspective, but it wasn't part of the team culture.

02:45.760 --> 02:49.320
So the next best thing was, well, good reviews.

02:49.320 --> 02:55.320
And back then, I was a fervent believer of good reviews, mainly influenced by books like

02:55.320 --> 03:01.320
good complete, facts and fantasies of software engineering and writing of Joel Spolsky.

03:01.320 --> 03:03.560
Anyone remembers Joel Spolsky?

03:04.240 --> 03:05.760
Yay!

03:06.760 --> 03:10.560
Well, it says something about our age, but anyway.

03:14.560 --> 03:20.160
And because the team was nervous, we also decided every single commit had to be reviewed.

03:20.160 --> 03:25.560
And so because there were no branches in place while we ended up doing non-blocking

03:25.560 --> 03:31.560
code reviews, which was, well, the realization of implementing lean principles and keeping things

03:32.560 --> 03:33.560
simple stupid.

03:33.560 --> 03:38.560
Not really realizing that what we were doing was actually a performant way of running

03:38.560 --> 03:39.560
code reviews.

03:39.560 --> 03:45.560
And in all honesty, I was quite embarrassed by our way of working compared to the rest of the industry.

03:45.560 --> 03:51.560
So we were nowhere close to what the rest of the industry was doing at that time, using branches

03:51.560 --> 03:54.560
and code reviews, and public has the platform.

03:56.560 --> 04:00.560
Now, there's non-blocking code reviews were based on two key ideas.

04:00.560 --> 04:06.560
The first key idea was to establish a continuous review process that consists of regular reviews

04:06.560 --> 04:08.560
as part of the development process.

04:08.560 --> 04:12.560
So the team used a command board to track work.

04:12.560 --> 04:17.560
And every ticket on the board was a feature, not a task.

04:17.560 --> 04:25.560
And so if you want to move tickets quickly from left to right, well, it puts pressure to keep those features small.

04:26.560 --> 04:33.560
So the feature was a unit of work on the can-man board, but the feature was not the unit of integration as it happens with feature branch.

04:33.560 --> 04:35.560
So the unit of integration was a commit.

04:35.560 --> 04:41.560
And the unit of release and deployment into production was a commit or a series of commits.

04:41.560 --> 04:45.560
Because the decision to deploy into production was still a manual decision.

04:45.560 --> 04:49.560
We practiced continuous delivery and not continuous deployed.

04:49.560 --> 04:57.560
Now, to ensure that code reviews happened and to track the code reviews, we introduced a review column,

04:57.560 --> 05:01.560
which indicates this feature is ready to be reviewed.

05:01.560 --> 05:04.560
So it's good complete, ready to be reviewed.

05:04.560 --> 05:08.560
Now, Dave Farley has seen this before.

05:08.560 --> 05:12.560
But it never really worked out for the teams that Dave worked with,

05:12.560 --> 05:15.560
because it was always seen as a gate.

05:15.560 --> 05:19.560
And research is clear about process gates.

05:19.560 --> 05:23.560
So going slow for safety is a bad idea.

05:23.560 --> 05:29.560
Because it introduces lots of disorders and distinctions and it drives down quality.

05:29.560 --> 05:31.560
But in other cases, it was different.

05:31.560 --> 05:33.560
This was not a gate.

05:33.560 --> 05:37.560
So the feature growth, commit by commit on mainline,

05:37.560 --> 05:43.560
but reviews were happening on the whole feature on mainline.

05:43.560 --> 05:46.560
Now, to avoid any context switching for the team,

05:46.560 --> 05:51.560
while we decided that whenever someone finished work before starting new work,

05:51.560 --> 05:55.560
or at the start of the day, or at the start of the afternoon,

05:55.560 --> 06:01.560
well, they would first check the review column to see if nothing was waiting to be reviewed.

06:01.560 --> 06:05.560
And if something was waiting to be reviewed, well, they would review it.

06:05.560 --> 06:09.560
There was only a single rule in place.

06:09.560 --> 06:16.560
That was, no one was allowed to review a feature they were involved in writing.

06:16.560 --> 06:20.560
It had always to be reviewed to buy another engineer.

06:20.560 --> 06:25.560
There were no rules in place regarding who could review the code of who.

06:25.560 --> 06:28.560
There was no hierarchy in place.

06:28.560 --> 06:30.560
There was true peer reviews.

06:30.560 --> 06:33.560
And so we had seniors reviewing the code of seniors,

06:33.560 --> 06:37.560
and reviewing the code of juniors as one would expect.

06:37.560 --> 06:43.560
But we also had juniors reviewing the code of other juniors, and of seniors.

06:43.560 --> 06:48.560
Now, I wasn't expecting that those juniors would provide many commands,

06:48.560 --> 06:53.560
but I was hoping that, well, by reading the code of more experience engineers,

06:53.560 --> 06:55.560
they would learn something.

06:55.560 --> 06:58.560
Although I have seen quite some interesting reviews coming from juniors,

06:58.560 --> 07:00.560
because they asked different questions.

07:00.560 --> 07:04.560
They asked more outside the questions, the wide questions.

07:04.560 --> 07:08.560
So the necessary triggers for improvement.

07:08.560 --> 07:12.560
Well, if we don't practice pool requests,

07:12.560 --> 07:14.560
or we don't practice bare programming,

07:14.560 --> 07:18.560
well, we end up in a situation where unreviewed code is going straight

07:18.560 --> 07:20.560
into the removed mainline.

07:20.560 --> 07:25.560
And so we end up with having reviewed code and unreviewed code,

07:25.560 --> 07:28.560
setting alongside each other on mainline.

07:28.560 --> 07:31.560
And so we have this piece of code is releaseable,

07:32.560 --> 07:35.560
at the same time.

07:35.560 --> 07:38.560
How do we keep them apart?

07:38.560 --> 07:42.560
And what this releaseable even mean in that situation?

07:42.560 --> 07:46.560
And that is the second key idea behind unblocking code reviews.

07:46.560 --> 07:50.560
Stop the code review to be definitive for the release.

07:50.560 --> 07:56.560
So the code review doesn't define if a code base is releaseable anymore.

07:56.560 --> 07:58.560
It is not a gate anymore.

07:58.560 --> 08:02.560
It is not a go-no-go decision anymore.

08:02.560 --> 08:07.560
So the team practiced true continuous integration

08:07.560 --> 08:09.560
with train-based development,

08:09.560 --> 08:12.560
that later evolved towards continuous delivery

08:12.560 --> 08:15.560
with a deployment pipeline.

08:15.560 --> 08:18.560
And every comment that went successfully

08:18.560 --> 08:21.560
through the whole deployment pipeline,

08:21.560 --> 08:24.560
through every stage of the deployment pipeline,

08:24.560 --> 08:26.560
that have been totally tested,

08:26.560 --> 08:30.560
had the potential to arrive into production.

08:30.560 --> 08:35.560
So the gunman board was working on the level of the feature,

08:35.560 --> 08:38.560
and reviews were working on the level of the features,

08:38.560 --> 08:41.560
but the software grew small commits by small commit

08:41.560 --> 08:47.560
on mainline and every commit could end in production.

08:47.560 --> 08:53.560
So this means that unreviewed code could end up in production,

08:53.560 --> 08:55.560
whether the feature was finished or not,

08:55.560 --> 08:58.560
whether the feature was reviewed or not.

08:58.560 --> 09:00.560
So we can argue,

09:00.560 --> 09:04.560
but we are running the risk of having bad code quality in production.

09:04.560 --> 09:06.560
And yes, that is true,

09:06.560 --> 09:09.560
and that happened many, many times.

09:09.560 --> 09:12.560
And that is not a problem.

09:12.560 --> 09:16.560
Because that quality is not a bug.

09:16.560 --> 09:19.560
Good reviews are not there to catch bugs.

09:19.560 --> 09:22.560
Anyone who thinks that a code review will catch a bug,

09:22.560 --> 09:24.560
well, beliefs and fair details.

09:24.560 --> 09:27.560
It doesn't work like that.

09:27.560 --> 09:29.560
For catching bugs, we have automated tests,

09:29.560 --> 09:32.560
and we have exploratory testing.

09:32.560 --> 09:36.560
So we had team commitment that any change had to be covered

09:36.560 --> 09:39.560
by an automated test, prefer a unit test.

09:39.560 --> 09:42.560
On top of that, we had a decent set of,

09:42.560 --> 09:45.560
what we call automated acceptance tests,

09:45.560 --> 09:48.560
but people usually call end-to-end tests.

09:48.560 --> 09:51.560
Although in our case, we are not end-to-end anyway.

09:51.560 --> 09:55.560
Then we also had the system in place that I would call peer testing.

09:55.560 --> 09:58.560
So we didn't have test engineers in the team,

09:58.560 --> 09:59.560
unfortunately.

09:59.560 --> 10:01.560
So the best thing we came up was that,

10:01.560 --> 10:04.560
well, any feature that was implemented had to be tested

10:04.560 --> 10:05.560
by another engineer,

10:05.560 --> 10:07.560
not involved in implementing the feature,

10:07.560 --> 10:10.560
like performing exploratory testing.

10:10.560 --> 10:11.560
On top of that,

10:11.560 --> 10:15.560
we had a decent set of static code analysis

10:15.560 --> 10:19.560
that would break the build on any rule violation.

10:20.560 --> 10:23.560
So the risk of working like that is not that,

10:23.560 --> 10:26.560
well, the code will be bigger or not,

10:26.560 --> 10:31.560
but that we might deliver lower quality code into production.

10:31.560 --> 10:35.560
But low quality code does not impact product delivery

10:35.560 --> 10:39.560
and even less functionality.

10:39.560 --> 10:44.560
On the other hand, low quality code does impact the speed of change.

10:44.560 --> 10:47.560
So it will impact how quickly we can implement

10:48.560 --> 10:51.560
new functionality and introduce new changes.

10:51.560 --> 10:54.560
And so it will impact our time to market.

10:54.560 --> 10:59.560
And that is the reason why we want to have high code quality.

10:59.560 --> 11:02.560
This is not working.

11:02.560 --> 11:06.560
So any end-to-siscoet that works,

11:06.560 --> 11:08.560
because the test says so.

11:08.560 --> 11:10.560
It passed all the tests.

11:10.560 --> 11:13.560
But that could be better.

11:13.560 --> 11:16.560
But that is somehow always true.

11:16.560 --> 11:21.560
The code reviews will only reduce the chances of low code quality,

11:21.560 --> 11:23.560
but it will not,

11:23.560 --> 11:26.560
and that will mostly depend on the quality of the code review,

11:26.560 --> 11:31.560
but it will not eliminate that code quality altogether.

11:31.560 --> 11:33.560
Now this worked for the steam,

11:33.560 --> 11:36.560
because while the steam decided that every single commit

11:36.560 --> 11:39.560
had to be reviewed at some point in time.

11:39.560 --> 11:42.560
And whenever an issue was raised,

11:42.560 --> 11:45.560
it had to be handled with the highest priority.

11:45.560 --> 11:48.560
Like we dropped work to fix the issue,

11:48.560 --> 11:52.560
so that the issue was removed as quickly as possible.

11:52.560 --> 11:54.560
Now the benefits.

11:54.560 --> 11:56.560
Now in order to understand the benefits,

11:56.560 --> 11:59.560
we need to understand the concept of transaction cost,

11:59.560 --> 12:00.560
from lean manufacturing.

12:00.560 --> 12:03.560
So transaction cost is the cost of moving a batch of work

12:03.560 --> 12:05.560
from one stage to another stage.

12:05.560 --> 12:07.560
It's important to understand this,

12:07.560 --> 12:09.560
because for the higher the transaction cost is

12:09.560 --> 12:13.560
the more inventories created in front of the next stage.

12:13.560 --> 12:17.560
So let's say we want to order some goods online

12:17.560 --> 12:19.560
and the transaction cost,

12:19.560 --> 12:22.560
so the cost to deliver the goods is three euros.

12:22.560 --> 12:23.560
Well in that case,

12:23.560 --> 12:25.560
we will not order a single good of one euro.

12:25.560 --> 12:26.560
No.

12:26.560 --> 12:28.560
We are going to order a new people of goods,

12:28.560 --> 12:30.560
so that we end up with a total cost

12:30.560 --> 12:32.560
that is a new people of the transaction cost

12:32.560 --> 12:35.560
to compensate the transaction cost.

12:35.560 --> 12:40.560
So if it takes 10 minutes to create a change

12:41.560 --> 12:44.560
and a changes waiting for a good review,

12:44.560 --> 12:46.560
and it takes two hours

12:46.560 --> 12:49.560
to receive a good review,

12:49.560 --> 12:53.560
it means that the change was waiting for 92%

12:53.560 --> 12:55.560
of the total lead time.

12:55.560 --> 12:57.560
Now,

12:57.560 --> 13:01.560
this is a pretty expensive process, isn't it?

13:01.560 --> 13:06.560
So it signals us that good reviews are costly.

13:07.560 --> 13:12.560
And so in order to compensate the transaction cost

13:12.560 --> 13:13.560
of the good review,

13:13.560 --> 13:18.560
well we are incentivized to ask less often for good reviews.

13:18.560 --> 13:21.560
And so what happens when we ask less often for good reviews,

13:21.560 --> 13:25.560
well we are going to create more changes

13:25.560 --> 13:28.560
people asking for the good review.

13:28.560 --> 13:29.560
And so,

13:29.560 --> 13:33.560
it discourages us to work in small incremental steps

13:33.560 --> 13:37.560
and it discourages us to perform refactoring.

13:37.560 --> 13:38.560
And if we don't refactor,

13:38.560 --> 13:39.560
we are not paying back that.

13:39.560 --> 13:41.560
And if we are not paying back that,

13:41.560 --> 13:42.560
we are not paying back that,

13:42.560 --> 13:44.560
we are going to end back the speed of change.

13:44.560 --> 13:48.560
And so introducing new functionality will take longer.

13:48.560 --> 13:49.560
Now,

13:49.560 --> 13:53.560
because we are waiting for someone to be available

13:53.560 --> 13:55.560
in order to do the good review,

13:55.560 --> 13:59.560
we are also incentivized to create more work and progress,

13:59.560 --> 14:01.560
because while people want to feel productive,

14:01.560 --> 14:04.560
they are not just going to wait there,

14:04.560 --> 14:08.560
until someone is available for a good review and do nothing.

14:08.560 --> 14:10.560
So what will they do?

14:10.560 --> 14:11.560
Right.

14:11.560 --> 14:14.560
They will start new work.

14:14.560 --> 14:17.560
And there we have the start of contact stretching

14:17.560 --> 14:18.560
and multitasking,

14:18.560 --> 14:20.560
and we know where this goes,

14:20.560 --> 14:22.560
and it's not pretty.

14:22.560 --> 14:24.560
Now because of little slow,

14:24.560 --> 14:26.560
the more work in progress we have,

14:26.560 --> 14:28.560
while the longer the lead times become,

14:28.560 --> 14:30.560
and so the more time it takes

14:30.560 --> 14:33.560
to get something onto the market.

14:33.560 --> 14:34.560
And so we end up with delay,

14:34.560 --> 14:36.560
delay, delay feedback.

14:36.560 --> 14:38.560
Learning will decelerate,

14:38.560 --> 14:39.560
we become risk adverse,

14:39.560 --> 14:41.560
innovation falls flat,

14:41.560 --> 14:44.560
and we go back to conserve the solutions.

14:44.560 --> 14:46.560
And this is what happens with organizations

14:46.560 --> 14:48.560
that practice pull requests.

14:48.560 --> 14:52.560
They go back to conservative ways of working.

14:52.560 --> 14:55.560
So to get things out sooner,

14:55.560 --> 14:57.560
while we need to reduce the transaction cost.

14:57.560 --> 15:01.560
And so we need to reduce the cost of the code review.

15:01.560 --> 15:06.560
So the benefits, second time.

15:06.560 --> 15:07.560
So in our case,

15:07.560 --> 15:10.560
the transaction cost was nearly zero.

15:10.560 --> 15:15.560
It had no impact at all on the total lead time.

15:15.560 --> 15:19.560
Comments already went through the deployment pipeline,

15:19.560 --> 15:21.560
and when it was successful,

15:21.560 --> 15:24.560
it could already be in production

15:24.560 --> 15:27.560
before a code review happened.

15:27.560 --> 15:30.560
And so there was no reason for us

15:30.560 --> 15:35.560
to create more changes before asking for a code review.

15:35.560 --> 15:38.560
So we could work in small incremental steps,

15:38.560 --> 15:40.560
and refactoring happened naturally,

15:40.560 --> 15:44.560
and so we ended up with better code quality.

15:44.560 --> 15:47.560
Now the fact that unreviewed code

15:47.560 --> 15:50.560
could already be tested,

15:50.560 --> 15:52.560
and could already be in production,

15:52.560 --> 15:54.560
before a code review even happened,

15:54.560 --> 15:57.560
was surprisingly a significant benefit.

15:57.560 --> 16:00.560
Because now we already received feedback from testing,

16:00.560 --> 16:03.560
and we already received feedback from production,

16:03.560 --> 16:05.560
from how they used the feature,

16:05.560 --> 16:08.560
or does not use the feature,

16:08.560 --> 16:10.560
before we started the code review.

16:10.560 --> 16:12.560
Eventually we didn't even have to start the code review,

16:12.560 --> 16:14.560
if the feature was not used in production.

16:14.560 --> 16:18.560
We should have reallicated the feature.

16:19.560 --> 16:22.560
Now because we never have to wait for someone to be available,

16:22.560 --> 16:24.560
we can work on functionality,

16:24.560 --> 16:26.560
and one go from start to end,

16:26.560 --> 16:29.560
so we can focus on one single thing.

16:29.560 --> 16:32.560
We never start new work before finishing

16:32.560 --> 16:34.560
and ongoing work,

16:34.560 --> 16:36.560
and so we have no multitasking anymore.

16:36.560 --> 16:40.560
And therefore we also have way less work in progress,

16:40.560 --> 16:41.560
and because of little flaw,

16:41.560 --> 16:43.560
while we have a reduce lead time,

16:43.560 --> 16:45.560
we reduce time to market.

16:46.560 --> 16:49.560
Now sometimes it happened that during a code review,

16:49.560 --> 16:53.560
while we discovered that this design was completely off,

16:53.560 --> 16:56.560
like completely wrong.

16:56.560 --> 16:58.560
These were the times where I was like,

16:58.560 --> 17:02.560
I wish we did some pair programming to avoid the situation.

17:02.560 --> 17:03.560
But then again,

17:03.560 --> 17:05.560
it wasn't a big deal,

17:05.560 --> 17:08.560
because while the test set functionality worked,

17:08.560 --> 17:10.560
it was already in production,

17:10.560 --> 17:12.560
delivering value to our users,

17:12.560 --> 17:14.560
the users were already using it.

17:14.560 --> 17:18.560
So we had all the time to redo the design,

17:18.560 --> 17:20.560
and do a total of rewrite,

17:20.560 --> 17:23.560
and we could even use a feedback from production

17:23.560 --> 17:25.560
to incorporate it in the rewrite.

17:25.560 --> 17:28.560
Something that is very difficult with pull requests.

17:28.560 --> 17:29.560
With pull requests,

17:29.560 --> 17:31.560
we have two options when the design is off.

17:31.560 --> 17:33.560
Either we impose a fix,

17:33.560 --> 17:35.560
and during the time we fix it,

17:35.560 --> 17:37.560
while the feature is still blocked.

17:37.560 --> 17:39.560
We still have no feedback on whether this thing

17:39.560 --> 17:41.560
that we just implemented is the right thing.

17:41.560 --> 17:44.560
We could even be wrong, but we don't know it.

17:44.560 --> 17:47.560
Or, well, there is delivery pressure,

17:47.560 --> 17:49.560
and so we get corners,

17:49.560 --> 17:51.560
and we let it go,

17:51.560 --> 17:53.560
and we say, we'll fix it later,

17:53.560 --> 17:55.560
and later, never happens.

17:55.560 --> 17:56.560
Right.

17:56.560 --> 17:57.560
So in our case,

17:57.560 --> 18:01.560
no pressure, no stress, no fatigue, no burnout.

18:01.560 --> 18:03.560
Now because,

18:03.560 --> 18:05.560
and reviewed commits,

18:05.560 --> 18:08.560
goes straight into the remote mainline,

18:08.560 --> 18:10.560
and eventually arrive into production,

18:10.560 --> 18:13.560
so a lot of trust on the team.

18:13.560 --> 18:16.560
So we are expecting the team to do the writing,

18:16.560 --> 18:18.560
instead of thinking that the team is stupid,

18:18.560 --> 18:20.560
and we need a process to fix for that.

18:20.560 --> 18:21.560
No.

18:21.560 --> 18:24.560
We were expecting the team to write automated tests,

18:24.560 --> 18:27.560
that they were going to write the right automated test,

18:27.560 --> 18:30.560
and that they would write high quality automated test,

18:30.560 --> 18:33.560
and an off automated test.

18:33.560 --> 18:36.560
So this is applying management theory,

18:36.560 --> 18:39.560
why over management theory x.

18:39.560 --> 18:41.560
And then again,

18:41.560 --> 18:45.560
well, if something wrong happens in production,

18:45.560 --> 18:47.560
that's also not the end of the world,

18:47.560 --> 18:51.560
as long as we have a process that allows us to fix it quickly,

18:51.560 --> 18:55.560
and in our case, we could release it in less than an hour.

18:55.560 --> 18:58.560
Now to be honest,

18:58.560 --> 19:02.560
well, there is a caveat with non-blocking code reviews.

19:02.560 --> 19:07.560
It might be difficult to introduce and regulate it in industries,

19:07.560 --> 19:09.560
especially healthcare,

19:09.560 --> 19:13.560
where they require a gate in the form of a code review

19:13.560 --> 19:15.560
before going to production.

19:15.560 --> 19:18.560
Although, I can imagine ways of introducing it,

19:18.560 --> 19:20.560
but I never worked in healthcare,

19:20.560 --> 19:24.560
so I never tested the ideas, so I won't share it right now.

19:24.560 --> 19:25.560
On the other hand,

19:25.560 --> 19:27.560
there are better ways to achieve the same,

19:27.560 --> 19:30.560
and this is bare programming and team programming.

19:30.560 --> 19:32.560
So with bare programming,

19:32.560 --> 19:35.560
the bare can sign over the commit,

19:35.560 --> 19:37.560
and this is the review,

19:37.560 --> 19:39.560
at the moment of committing,

19:39.560 --> 19:43.560
and they can tag the change with the identified of the engineers

19:43.560 --> 19:45.560
involved in the bare,

19:45.560 --> 19:49.560
and this is your evidence that a code review happens.

19:51.560 --> 19:53.560
Now,

19:53.560 --> 19:55.560
I still think that bare programming and team programming

19:55.560 --> 19:59.560
are a superior delivery option,

19:59.560 --> 20:01.560
but in many organizations,

20:01.560 --> 20:04.560
this is a cultural stretch to introduce.

20:04.560 --> 20:07.560
It's just difficult, it's people are not open to the idea,

20:07.560 --> 20:10.560
the whole social aspect that is involved.

20:10.560 --> 20:13.560
So in those cases,

20:13.560 --> 20:16.560
non-blocking reviews strategies are

20:16.560 --> 20:19.560
significantly better than any of the alternatives,

20:19.560 --> 20:23.560
because we have no gates in place,

20:23.560 --> 20:26.560
because we have no gates, we have no delays.

20:26.560 --> 20:28.560
So deliveries are never blocked,

20:28.560 --> 20:30.560
we have shorter time to market.

20:34.560 --> 20:36.560
Because we have no waiting times,

20:36.560 --> 20:38.560
while people are not incentivized

20:38.560 --> 20:41.560
to start new work before finishing on going work,

20:41.560 --> 20:43.560
and so we have way less work in progress,

20:43.560 --> 20:45.560
and because of little slow,

20:45.560 --> 20:47.560
our really times are reduced,

20:47.560 --> 20:49.560
and our times to market are reduced.

20:49.560 --> 20:53.560
Because we are not starting new work

20:53.560 --> 20:55.560
before finishing on going work,

20:55.560 --> 20:57.560
while we have less context switching,

20:57.560 --> 21:00.560
so we have no productivity curves,

21:00.560 --> 21:02.560
no multitasking anymore.

21:02.560 --> 21:06.560
We have way less stress and fatigue and burnout.

21:06.560 --> 21:14.560
Also, when we find issues in good reviews,

21:14.560 --> 21:16.560
while we have all the time to fix them,

21:16.560 --> 21:18.560
there is no pressure to fix,

21:18.560 --> 21:20.560
because there is no delivery pressure.

21:20.560 --> 21:22.560
It's already delivered.

21:22.560 --> 21:25.560
It's already in production, delivering value.

21:25.560 --> 21:26.560
And lastly,

21:26.560 --> 21:31.560
well, we are not incentivized to work in bigger batches,

21:31.560 --> 21:34.560
so we can work in small incremental steps,

21:34.560 --> 21:36.560
and we factoring happens naturally,

21:36.560 --> 21:39.560
it's so leading to way better code quality,

21:39.560 --> 21:42.560
which allows us to improve the speed of change,

21:42.560 --> 21:46.560
and again reduce lead time and time to market.

21:46.560 --> 21:48.560
Thank you.

21:49.560 --> 21:50.560
Thank you.

21:58.560 --> 21:59.560
Yeah.

21:59.560 --> 22:01.560
Probably you see from this one,

22:01.560 --> 22:04.560
we have an agent, agent with the code.

22:06.560 --> 22:07.560
Can you repeat?

22:07.560 --> 22:08.560
I don't know.

22:08.560 --> 22:09.560
I don't know.

22:09.560 --> 22:10.560
I don't know.

22:10.560 --> 22:12.560
But probably you see from this.

22:12.560 --> 22:13.560
Ha ha.

22:13.560 --> 22:16.560
But if you change dramatically.

22:16.560 --> 22:17.560
Yeah.

22:17.560 --> 22:19.560
Well, I still think you need to review the code,

22:19.560 --> 22:23.560
because you need to understand what the AI agent generated.

22:23.560 --> 22:25.560
I have no idea that.

22:25.560 --> 22:26.560
Well, people.

22:28.560 --> 22:29.560
Yeah.

22:29.560 --> 22:31.560
Otherwise, you have an asset,

22:31.560 --> 22:33.560
where you don't understand what happened,

22:33.560 --> 22:35.560
and this is a huge risk.

22:35.560 --> 22:38.560
Question here on the left.

22:38.560 --> 22:40.560
Thank you for the presentation.

22:40.560 --> 22:42.560
As you mentioned,

22:42.560 --> 22:45.560
there are a few million high trust for this to work,

22:45.560 --> 22:48.560
but what are the conditions that you see this on?

22:48.560 --> 22:50.560
What sort of teams that this is going to work with?

22:50.560 --> 22:53.560
Because not every code is just something that's like,

22:53.560 --> 22:56.560
or code is late and not every code is,

22:56.560 --> 22:58.560
that's not going to do it.

22:58.560 --> 22:59.560
Not in the nature of things,

22:59.560 --> 23:01.560
but sometimes that's done.

23:01.560 --> 23:02.560
Yeah.

23:02.560 --> 23:05.560
So, good point.

23:05.560 --> 23:07.560
So, what is,

23:08.560 --> 23:10.560
So, I mentioned,

23:10.560 --> 23:13.560
it requires trust and the team,

23:13.560 --> 23:15.560
and if I understood the question right,

23:15.560 --> 23:20.560
you are asking what all the things are needed for this to work,

23:20.560 --> 23:22.560
and can this work in any team.

23:25.560 --> 23:27.560
Now, we were lucky with this team.

23:27.560 --> 23:29.560
They were really demanding,

23:29.560 --> 23:31.560
and they saw us like,

23:31.560 --> 23:35.560
oh, they are going to tell us of the right thing to do.

23:35.560 --> 23:36.560
So, this is helpful.

23:36.560 --> 23:39.560
It's a bit more difficult when you have,

23:39.560 --> 23:42.560
like, in very senior environments,

23:42.560 --> 23:44.560
that always worked with full request,

23:44.560 --> 23:45.560
to just introduce that.

23:45.560 --> 23:48.560
Because a lot of us in the minds of,

23:48.560 --> 23:51.560
well, first we have always worked like that,

23:51.560 --> 23:54.560
and second we have a trust that's all good,

23:54.560 --> 23:57.560
but in the end.

23:57.560 --> 24:02.560
I think it's a long work process.

24:02.560 --> 24:05.560
It's a lot of massage, I think.

24:05.560 --> 24:09.560
Thank you.

24:09.560 --> 24:10.560
Very quick.

24:10.560 --> 24:12.560
Did you have that question?

24:12.560 --> 24:14.560
You make a change,

24:14.560 --> 24:16.560
but it turns out that needs to make quite a lot of changes,

24:16.560 --> 24:17.560
all over the code.

24:17.560 --> 24:19.560
So, your permit isn't really very small,

24:19.560 --> 24:21.560
and it stops becoming big.

24:21.560 --> 24:22.560
And then most of the tests pass,

24:22.560 --> 24:24.560
but you'll have to support 10 different platforms,

24:24.560 --> 24:26.560
lots of hardware configuration,

24:26.560 --> 24:27.560
lots of support libraries,

24:27.560 --> 24:28.560
and not all the tests pass,

24:28.560 --> 24:30.560
all the platforms are there.

24:30.560 --> 24:33.560
Is there any way you can still move forward,

24:34.560 --> 24:37.560
if you come guarantee that you can fix

24:37.560 --> 24:40.560
every platform every single thing full of time.

24:40.560 --> 24:43.560
Maybe you can still use this workflow.

24:43.560 --> 24:45.560
Oh, yes. So, yeah.

24:45.560 --> 24:49.560
So, repeat the question.

24:49.560 --> 24:52.560
It's allowed for release on these platforms,

24:52.560 --> 24:53.560
but not on these platforms,

24:53.560 --> 24:56.560
maybe because the testing says that.

24:56.560 --> 24:57.560
So,

24:57.560 --> 24:58.560
We have fixed everything right now,

24:58.560 --> 25:00.560
because I want to look forward

25:00.560 --> 25:01.560
on the other side,

25:01.560 --> 25:03.560
which is so amazing.

25:03.560 --> 25:04.560
So, yeah.

25:04.560 --> 25:06.560
So, what?

25:06.560 --> 25:09.560
So, what if we don't have a single comment

25:09.560 --> 25:10.560
that no people comments,

25:10.560 --> 25:11.560
and we need to load,

25:11.560 --> 25:14.560
do loads of changes everywhere in the code base,

25:14.560 --> 25:16.560
but we are deploying in many platforms,

25:16.560 --> 25:18.560
on many different platforms,

25:18.560 --> 25:19.560
target platforms.

25:19.560 --> 25:21.560
So, I would suspect,

25:21.560 --> 25:23.560
yeah, I don't know, actually.

25:23.560 --> 25:25.560
Well, the thing is,

25:25.560 --> 25:26.560
what work?

25:26.560 --> 25:28.560
So, this requires a deployment pipeline

25:29.560 --> 25:30.560
that acts as a gate.

25:30.560 --> 25:32.560
So, if tests are failing,

25:32.560 --> 25:34.560
it just don't go to production.

25:34.560 --> 25:36.560
Period.

25:36.560 --> 25:38.560
And, and, and, and,

25:38.560 --> 25:40.560
the, so, the team implements,

25:40.560 --> 25:42.560
stop the line.

25:42.560 --> 25:43.560
And that means they,

25:43.560 --> 25:46.560
they drop work and fix the deployment pipeline,

25:46.560 --> 25:47.560
because, well,

25:47.560 --> 25:49.560
it means we are not delivering value.

25:49.560 --> 25:50.560
Yeah.

25:51.560 --> 25:52.560
Thank you very much.

25:52.560 --> 25:53.560
Thank you.

25:53.560 --> 25:54.560
Thank you.

25:54.560 --> 25:56.560
Thank you.

25:56.560 --> 25:57.560
Thank you.