In my role at Redgate, which I’m really still growing into , I tend to only get small pockets of time to do some hands-on development.
A lot of my time has been taken up with both Leadership and Management as well as training on both and what I’d describe as contributing to discussions on the team and technical culture of Redgate (Psychological Safety, the four Accelerate metrics, DDD, mobbing and indeed TBD). I’m expecting this balance to change with time as the newer bits become business as usual. And this is happening already.
What this has meant is that I have often got to the point of creating, or needing to create, a Pull Request (PR) before I need to go to a meeting or get pulled on to something else.
This has meant that by the time I return to the code the change I was attempting is so outdated that the rebase (think merge if it’s easier) required to get the changes onto master (also referred to as Trunk, hence TBD) is now so painful I may as well start again.
This has meant I haven’t done as much coding as I would have liked, and this has been self-reinforcing; I haven’t built up any momentum of making changes, which means I then have to start again from scratch when I next get the chance.
Change of Circumstance
In the last month the team’s focus has changed and rather than working in a large established codebase (alongside two other teams) with a mature (and mandatory) PR process, we have switched to spiking and developing from scratch.
Whilst we were working on the large codebase, it wasn’t really in our remit to decide NOT to do PRs.
Last week I found some time to make some changes and started to orient myself with the new code. I diligently put together a PR, but then thought: Hang on, we’re not in the shared codebase anymore, in fact in a repo made for spikes and experiments, perhaps we can move towards TBD.
Making small changes
As I said, we’re building from scratch and doing a fair amount of spikes, so the code had been put together to get something working, but not really ‘designed’.
We had a number of command-line based programs which were all in single files, but with multiple classes, and in one case many classes. There were clearly multiple concerns going on, so both as exercise in getting my hands dirty, but also to start to introduce some design I started pulling some different classes out.
As was recently said on a Domain Driven Design course, design doesn’t happen by accident — entropy doesn’t make a great designer.
Rather than doing a large set of changes and created a PR, I just started pushing smaller ones to Trunk; I should also say, we had some discussions as I went.
An evolving design
At one point it became obvious that the interface could be improved by a change I’d missed. So we tweaked that and pushed that too. No drama.
Improving the code over time has always been my modus operandi over the years of developing my own personal brand as @TheCodeCleaner. Slowing improving the design is the only way to do it, especially whilst also keeping it deliverable.
Thus the software can be evolved over time, rather than be be a series of larger, more violent, changes. There is a fluidity rather than abruptness to the changes. The feedback loops can be smaller.
Minimise Batch Sizes
Working in the small reduces the risk of each change. As one of my favourite quotes says:
“Software has diseconomies of scale — Allan Kelly
This echoes the mantra in Lean of reducing batch size; work on the smallest indivisible task possible, finish it and then do the next one. Unmerged work on a branch is Work In Progress and therefore Work At Risk.
Because of the overhead of getting changes approved, it’s natural to tend to batch them up. It may not even be conscious, but the changes tend to aggregate until you have quite a large PR.
As someone observed, if you ask for a 10-line change to be reviewed, you may get 10 comments. If you ask for a 1000- line change, you’ll get a “Yer, s’ok. Whatev’s”.
Time and Energy
Progress is measured in Working Software
Pull Requests, as with comments, can be a massive distraction.
Personally, I’d prefer the time and effort expended in the mechanics of performing Code Reviews, to be focused on improving the code in the first place. Like Comments, there probably is a place for them, but more as the exception than the rule; in the case of comments, very occasionally to explain Why, not the how. In the case of Pull Requests, for some operation that can’t be done as an Evolution, there may be no way round a larger change.
In this sense, the working software is the Essential Complexity, the heat and light generated by the PR Process is Accidental Complexity.
Not seeking perfection
There is also a sense that each change does not have to seek perfection, but be a coherent self-contained change. I have seen the fear of changes not being perfect paralyse a team from making virtually any changes at all. No one wants to make a change in case it is criticised or found to be the cause of an issue later. The team lacked Psychological Safety which I’ll return to in the next section.
This is a version of the Gold-Plating which tends to just delay and delay, with the scope of a change continually ballooning.
Rather than seeking perfection each time, I encourage teams to chip away and focus on moving in the right direction with each small commit. To reduce the size of commits, it can mean you have to retrace steps sometimes, but this reduces the risk of it going horribly wrong when trying to do it all in one big commit. And it can mean you have less work in progress at anyone time.
Safe to Fail
Psychological Safety is where team members being able to fail in front of each other with no recriminations, so they don’t feel they have to try to hide it; it goes hand in hand with a No Blame culture.
Having a team feel Safe to Fail means that they can be more innovative, take calculated risks instead of being risk-averse; often they’ll have systems in place to catch any problems that do get made, but equally if something does escape the teams energy goes into fixing it rather than wasted on apportioning blame.
The best teams I’ve worked in over the years have had such a Can Do attitude that nothing seemed impossible, compared with the worst, where everything seemed impossible.
Last week my colleague Alasdair Parker published a blog on how moving to Trunk Based Development (TBD) had upped the level of trust in his team. I think this is a great advertisement for moving to TBD.
I always liken this to the advice on an Advanced Driving Course of not using your indicators — when you do this you start taking full responsibility for making sure you’re aware of your surroundings. There are similar discussions around cycle helmets and indeed car airbags.
This is also akin to a story James Lewis told when he was here of a 2-Person Rule for dispensing ‘Dangerous’ drugs in A&E. When they removed the rule, they found the rate of mistakes went down. Responsibility couldn’t be ‘offloaded’ to someone else, so more care was taken.
Whilst Continuous Integration servers have undoubtedly improved over time, allowing builds based on all branches as if they were master/trunk, the term Continuous Integration refers to Integration happening in both directions, continously; not just occasionally, or even frequently. If work isn’t integrated on to trunk or master every day it’s not Continuous Integration, it’s just a Build Machine.
Whilst there may be exceptions, I just don’t think you can consistently do this with branches and PRs.
Continuous Delivery demands even more. Having mentioned the Accelerate book and it’s metrics already, high performing teams push a commit and have that change in Live/Production in timeframes measured in minutes; you just can’t do that with a PR process is place.
In Open Source projects there is often (rightly or wrongly) one or more people with elevated status — who give the yay or nay on what changes are accepted; the owners of the codebase. This is an enforced type of heirarchy.
In a full time team this can be very unhealthy. One of the principles of EXtreme Programming (XP) is Shared Code Ownership. Everyone is responsible for every bit of code, there are no separate individual kingdoms here. Only one person being allowed to change a certain bit of code is a heavy smell of dysfunction. Where is the Trust in the others — where is the knowledge sharing?
It’s the same with having only certain pointy hats being allowed to accept changes. It’s an unhealthy team dynamic. It encourages Cliques and Chosen Ones.
Don’t use Technology to make up for the lack of Trust in a Team.
Build the Trust instead.