My Sonder Camino Ti arrived in November 2020 with the FSA Non-Series off-road wheelset. After 9 months of mixed British riding, including a long, gritty winter in the Peak District, both wheels developed a bit of play and looked like they needed new bearings.

FSA/Vision have technical documents with lists of service parts for the wheels, but these use non-standard part names, and mapping these to the international standard was only possible once I stripped the wheels down and read them off the bearings themselves.

Front wheel

• Vision/FSA code: MR199
• Actual size: 15x26x7mm
• Quantity: 2
• Bearing code: 15267–2RS (2RS just means there are 2 rubber seals, which helps protect the bearing from grime)

These can be removed with a bearing puller, and refitted with a standard bearing press with 15x26x7mm drifts, such as this one.

Rear wheel

• Vision/FSA code: MR200
• Actual size: 17x28x7mm
• Quantity: 2
• Bearing code: 17287–2RS (2RS just means there are 2 rubber seals, which helps protect the bearing from grime)
• The freehub contains a couple of the same bearings, but I couldn’t remove them, and ended up ordering a full replacement freehub (EL298).

As these have different dimensions, they need a slightly different-sized bearing puller.

To fit/refit the bearings, you’ll need a press with over-axle drifts because the captive axle gets in the way of a standard press once you have the first bearing in. There’s also a cheaper alternative approach if you have a socket set — Youtube is your friend there.

I’ve found Henderson Bearings to ship quickly and last a decent time, though I don’t know enough to say whether their “Enduro” branding is just marketing or a lot better for bikes.

It’s been a long time since my last multi-day adventure ride back in 2013. I’d almost forgotten what it was like to get into the trance. Spinning the pedals, taking in the scenery, thinking about the next milestone, and yet still feeling a long way from the end. This time I was riding along with audiobooks and music instead of friends and family (thanks jobs and pandemic 🙄), but as soon as I set off I felt that calm focus of knowing there was only one thing to do today, and it would take all day.

I should mention that I didn’t bivy or ride self-supported, which is a bit against the spirit of the Racing Collective events. With my dad just round the corner and eager for a road trip, we had a great excuse for a family adventure even though he can’t cycle. I was quite grateful for this in the end — not just because I get on well with my parents, but also it was nice to have someone to chat to. Riding solo suits many people, but I found myself itching for someone to share my highs and lows with as the trip unfolded.

The route

The Racing Collective’s EnglanDURO event is the first weekend of August. I had other commitments, so rode it a week or so early. The route starts at the Liverpool seafront, and snakes its way northeast to the sandy beaches of Scarborough. Despite passing through Liverpool, Warrington, Stockport, Wakefield, Castleford and York, the towpaths, bridleways and cycle routes never felt too built-up or busy.

Before leaving I was a bit nervous about the trails being busy with walkers. There’s a lot of distance to cover, but it’s not cool to shoot past people at 25km/h just because you’ve got a goal. Thankfully this wasn’t a problem at all. Other than a slow canal-side section in York where many were enjoying the sun, paths were often wide enough to ride at a reasonable speed, and elsewhere it was pretty quiet.

My parents live in Castleford, so it made a perfect break in the trip, breaking it into a longer 170km first day with 1500m height gain. That left day two with 130km and 500m less height gain (in theory).

We set off early to drive to Liverpool, and I was cycling along the waterfront by 8am, passing a steady stream of commuters, runners and dog walkers. The cycleway is wide, flat, and has great views to shipyards and the wrecks of old piers across the water. It felt great to build up some momentum right at the start, even though there wasn’t time to stop and look at the myriad statues and memorials along the front. I soon joined the Trans-Pennine Trail around Hale, which I’d be following for most of the day, and the first hike-a-bike section, carrying the bike up a switchback of stairs by Ditton Marsh. After the fast, open start, the slow trudge up the steps felt like a bit of a setback, but don’t fear: there are only a handful of these on the entire route.

The first 80 kilometres wind peacefully along the Mersey with the terrain and views changing frequently. I’d been expecting more “industrial heartland”, but the cycle route manages to hide it away behind trees and inclines. Blips of business like John Lennon Airport were short-lived and soon forgotten. Despite the gentle gradients, I wasn’t fooled. The climb over Woodhead Pass loomed in the distance, waiting to see if I had enough energy left for the last big push. Thankfully that climb ramps up slowly, at least until you cross the A628 when you wonder when you’ll need to push. The reward is continuously amazing views (e.g. the photo at the top of this page), and friendly exchanges with other cyclists and walkers. No-one is finding that climb easy!

With the biggest climb behind me, I had a big grin on my face down to Penistone. The official route turns off Windle Edge to touch Winscar Reservoir before descending off-road to Townhead. This path is now private land with no access, so I retraced my steps back to the main road. From Townhead the route jumps back off-road to follow the River Don down into Penistone, where the last significant climb of the day awaited.

After spending so long climbing, the long undulating descent was a playground for the energy I somehow managed to conjour in my legs. The area around Bretton Country Park and Yorkshire Sculpture Park was absolutely beautiful, with fast, flowy, open trails. A short glance at the lake at Pugneys Park was next, before joining the canal towpath that I knew would take me all the way into Castleford. There was a tiny hitch joining the canal — the last 100m of the path that joins Pugneys to the canal was closed. A bit of back-tracking (and some helpful people who’d just come the other way) led me out, and then it was just glorious, flat towpath that led to food, stretching and sleep after eleven and a half hours on the bike.

A route of two halves

I’d been quite nervous about the second day, and cautious about how much my pace would drop with tired legs, so I set off before 7:30am. I don’t know where this fear came from — we didn’t have a deadline to arrive in Scarborough other than “before the fish & chip shops close”, but when you’ve not done the distance in a while it’s easy to assume you’ll be crawling along at a snails pace.

Thankfully for said tired legs, I started with a gentle stretch along the towpath with cool, clear skies and a little dew on the ground. I had a crisis of confidence when the route turned off onto a walkers-only footpath through Fairburn Ings. Normally I’d figure out a cycle-friendly alternative, but being a bit tired and wanting to make progress, I decided there probably wouldn’t be anyone there so it’d be okay. My guess was correct, and I popped out the other side to start the first climb of the day over to Ledsham, which was a nice quiet path through the woods.

The following 30km on road and paved towpaths felt fast, and set the tone for the day. Where the first day had been 60% dirt, day two was 70% paved, which had the unexpected benefit of increasing my pace even though I was a bit more tired. Slowing down in York to carefully pass walkers and other cyclists enjoying the sun, I was reminded that today was supposed to be overcast with rain. Lucky!

After York things returned to what I’d expect from a ride in Yorkshire. Hills. Up and down. Short, sharp efforts. And great views. Passing Kirkham Priory brought back childhood memories, and I was more than happy to wait for the trains to pass in the valley before the crossing reopened. There’s a significant climb that reaches 17%, which was a really convenient point to lose signal and have my audiobook cut out. Again, it’s hard to complain because the road was quiet, and the surface pretty good.

I’d studied the elevation profile for day two, so I knew that after this climb there was a good rest before the final significant hill of the day. The big one, albeit a lot smaller than Woodhead Pass of yesterday. I realised I could make it to Scarborough. One more big hill wouldn’t stop me, and my legs felt pretty good. I passed the Cayley Arms, crossing the main road to start the climb. Fortunately it’s closed on Tuesdays, otherwise I can’t say for sure that I wouldn’t have succumbed to the lure of a cold drink and a rest. At the base of a steep climb it would have been a bad call.

The climb up into North Riding Forest Park was actually pretty pleasant. The road had no traffic and only the occasional walker. It’s gruellingly steep in places, but gets its steepness out of the way in the first half before trading road for track and easing off the closer you get to the top. The last gentle climb followed tracks through fields. On any other day these would have been a joy to ride, but after several days of warm sun the track was rock hard and pitted with footsteps and hoofprints. This left a knobbly trail that juddered the gravel bike and shook me to my core as I tried to build up speed after the slow climb. Things just got better and better as field led to smooth, wide forest track, and I chased a motorbike as we both sprinted down the long straight trail with tall trees either side. What a feeling. This was the last big climb of the trip, and I knew Dad was parked up at the end of the trail with snacks and cool drinks. It was only when I met Dad that I heard the bad news…

They really don’t want anyone in there. I’d already used my “I’m normally good so it’s okay if I break the rules” card back at Fairburn Ings this morning. Fair cop. A quick look at the map showed this is the only track north. My only option seemed to be to head south to Ebberston and suck up a stretch on the busy A170 before turning north again to get back to the route. I was a bit demoralised at the thought of going in precisely the wrong direction, and doing a 15km round-trip to bypass 1km of closed path, and my mood didn’t improve as I realised the descent to Ebberston wiped out all my height gain. In Snainton I turned and re-climbed the hill, grumpy until I remembered how fortunate I was to be out there in the first place. Sure it was an unexpected hill, but it just meant I got to spend more time on the bike. I was still well on track to arrive in Scarborough in time for dinner. It was worth climbing back up for the stretch across Wykeham Forest and a steep descent on road towards Hackness.

Update: Thanks to North York Moors NP, it looks like I just missed a bridleway to the right of this photo.

The route left the road for one last hurrah, climbing up gently in woodland on established trails. Eager to drop into Scarborough, of course it was here that I met a walker who just needed someone to talk to. What started as a request for directions took a surprising turn into a life story about divorce, moving to Birmingham, and disdain for their neighbours. I felt quite uncomfortable when he started sharing his views about people on benefits, but chose escaping over setting him straight. They were so reluctant to let me go, striking up new lines of conversation. I hope they find someone to talk to.

Thankfully the last stretch into Scarborough was uneventful. A surge of “almost there” energy had me racing to the seafront, where a huge number of people were making the most of what had turned out to be a warm, sunny day.

The only thing left to do was hide the bike in the car, meet some friends on the beach, and fight off seagulls while we devoured fish and chips.

Would I recommend the route? Absolutely.

Route alterations & roadblocks

If you’re riding EnglanDURO21, or just following the route sometime soon, here’s a summary of the alterations I had to make. You can see my full tracks on Strava for day one and day two.

1. Windle Edge/Pennine Sailing Club (Google maps). The track is now private land, so stay on Windle Edge (don’t turn into the sailing club) into Townhead to rejoin the route.
2. Pugneys Park near the end of the lake (Google maps) has fenced off the track, but if take the north fork at the point on the map (rather than north-east following the route) you can join it a little further on.
3. The Fairburn Ings entrance from the Aire & Calder Navigation towpath (Google maps) is footpath-only. If you’re early in the morning or late in the evening this is probably fine, but the path is quite narrow in places so best avoided when it’s busier. To avoid it completely, stay on the A656 and follow it into Allerton Bywater before turning right onto Newton Lane to rejoin the route (see diversion on OpenStreetMap). This diversion only adds a couple of hundred metres to the day.

Links

• Huge thanks to the Racing Collective for putting the route together: https://www.theracingcollective.com/englanduro.html
• Day one track: https://www.strava.com/activities/5691283829
• Day two track: https://www.strava.com/activities/5695664642
• #EnglanDURO21 Spotify playlist: https://open.spotify.com/playlist/0BgDygP557YMg5KMSsflAO?si=55af91d8c27044e6
• The Twilight of Democracy on Audible: https://www.audible.co.uk/pd/Twilight-of-Democracy-Audiobook/0241481821

The bike came out of things pretty well, and just needed the mech hanger bending out, a new GRX shifter and some bar tape. The hardest part of getting that back on the road was sourcing the shifter, with both Shimano and SRAM components being in short supply this year. My clothing was another story…

Suprisingly enough, most road cycling clothing isn’t built to be bounced along the tarmac, and I managed to damage everything I was wearing except my shoes (thankfully my ready-to-be-replaced overshoes took the brunt of that damage). I’d picked a terrible time to do this, as a few things were really new. My 3-week-old Castelli bib tights had a big hole in them, and my month-old POC helmet had a big dent too. For some context on how pleased I was with Rapha, I’ve been comparing them with these two brands:

• POC ignored tweets and a couple of emails. They mention a crash replacement programme in North America, but not Europe, but I never got an answer about whether they do or not. The helmet was amazing, but the service less so.
• Castelli’s UK replacement policy is oddly complex, with extra discount if you’ve bought directly from Saddleback. This one was the most frustrating — the almost-new bib tights needed a replacement panel, and it felt very wasteful having them destroyed for 40% discount on a full-RRP set. In the end I picked up a brand new set from Sigma Sports with a reasonable discount (though not 40%), and am waiting for Alpkit’s repair stations to open up as lockdown lifts. Hopefully I’ll end up with a slightly scrappy pair for mountain biking 🤷‍♂️.

The thinnest, lightest thing I was wearing was my Rapha Brevet high-visibility jacket, which came off peppered with holes and a couple of tears. I love this jacket. It’s reflective stripes are perfect for winter riding when you end up in the dark more often, and it still packed down small and breathes really well. Maybe a little too well after the fall…

Here’s a few “before” photos

Of all the damaged clothing, this was the one I assumed was destined for the bin. It’s a couple of years old, and a very fine material.

I knew Rapha had a free repairs service, but couldn’t find anything on the internet other than a forum post that said they’d got a free replacement and it had taken 5 weeks. With nothing to lose, I took the photos above, sent them to Rapha and had it in the post the next day.

Three and a half weeks later a package turned up, and in a nice little “first aid” tote bag was my repaired jacket. Here are a few photos of their handiwork:

I’m more than satisfied with the repair. Sure, it’s no longer as-new, and the back panel adds a little more bulk to the jacket, but when there’s all the other expenses of replacing clothing and components I couldn’t be happier that I’ve not had to shell out (excuse the pun) on a new jacket.

Five stars, but I hope I don’t need to use the service again anytime soon!

Then one day, something happened to restore peace. Swanky editors with soft-wrap, style guides, and EditorConfig united developers around one principle: consistency. Consistency was hard to argue against, and as tooling made it easier to promote/enforce we started to realise that the actual choice didn’t matter that much really.

So our armies retreated to our caves, ushering in an age of peace and productivity. But with that peace came complacency, and murmurings started again, this time around code collaboration. The Git Flow Wars of the 2010s saw the resurgence of trunk-based development and a return of the endless debate, this time around whether git rebase was a silver bullet or a corrupting force of evil.

Now we’re well into the age of the Pull Request, and the questions are coming back. Who should merge them? How big should they be? What should they contain? How should we review them? Disciples of the many “One True Way”s are out in force, but we already know the answer: it probably doesn’t matter what you pick as long as you’re consistent. Consistency within a team or organisation is what we’re after, not consistency across a career.

As a technical lead, delivery manager, or just someone hoping for a quiet life, here’s a checklist of the subjective debates that risk bikeshedding and becoming a time-sink. When they crop up in reviews it’s a “smell”, a signal that the team has a diverging understanding of concepts that we need to be able to rally around. It’s tempting to set up a session to talk about how you should be doing things, but that’s a red herring. The first thing you need to do is get agreement on how you are doing things, and write that down. We can call it a Team Charter, a Ways of Working document, or anything meaningful to your team. The important thing is to document the decision. For an extra point capture a simple “why”.

Once we’ve captured our baseline, we can apply some agile goodness and iteratively improve the way we work. Retrospectives are a great place to reflect on how your ways of working help or hinder you, agree experiments to try, and evaluate their effectiveness.

The list

There’s nuance to many things on this list, and there may be objectively “better” options, but often they’re marginal gains rather than the only way to avoid catastrophe.

The list is grouped into three areas: commit etiquette, pull request scope, and how we merge.

Commit etiquette:

• Step-by-step commits.
• Merge main into the branch or rebase?
• The perfect commit history.
• All commits pass CI (e.g. enforced git precommit hooks)
• Commit messages. Is there a format? Do we use semantic commit messages? Should every message contain Gitmoji?
• Should lint fixes be a separate commit?

Pull request scope:

• “Scouting” and refactoring as a separate commit or different PR?
• Coverage & quality creep. Is it okay for a single PR to leave the codebase slightly worse?
• PR size. This is the big one! Should there be one PR per card/issue, or many tiny increments?
• Do you use/how do you use “draft” PRs? Are they for presenting ideas, or work in progress. What’s their lifespan?
• PR descriptions. Do you have a a standard template? What do you expect to see in a description?
• Do we use labels? If so, how?
• Are chained PRs allowed?
• “Fix in this PR” vs “I’ll add that in another PR”.

Merging:

• Squash, merge, or rebase into main?
• Request changes vs comment vs approve. What are the implications of each type of response?
• How do we request review (ask on Slack, auto-post, email notifications…)? Is a review open to all, or do you invite specific reviewers? What if you’re not invited but care?
• What’s the review process? What’s in scope? Do you value high level or low level comments, and when is each type appropriate?
• Minimum reviewers
• Does it need to be up-to-date with main before merge?
• Who decides if it can be merged? The author or the reviewer?
• Who merges the PR (again: author or reviewer)?

Record your ways of working

Now you’ve figured out how you work, you’ll want to write it down. Without wanting to open another can of worms, there are a couple of qualities common to team charters which are actually read, honoured and evolved by teams I’ve worked with:

1. They’re short and concise. It feels good to write 2000 words on the primacy of meaningful commit messages, but think about your reader. A new team member doesn’t want to lose two weeks trawling a book on how they should collaborate. Brevity is key. Short documents are easier to scan, and brief (1 paragraph) points are more easily pointed to. If you really need to write more to explain your decision, capture this elsewhere (Decision Records are great for this).
2. Each point is linkable. Being able to point at a specific rule in a pull request comment or chat makes conversations more concrete, and lowers the barrier to entry for reading and following. Most wikis and markdown renderers add IDs to headings so you can link to a point in the document, for example this rule in the Ruby Style Guide on GitHub.

Conclusion

Create a style guide for your ways of working, and encourage slow, thoughtful evolution over time. And don’t assume that what works well for your team is inherently the One True Way.

Bad names, on the other hand, slyly make our lives harder. They hide ambiguity, and introduce tension into discussions. They make agreement harder, with different parties taking the name to mean different things. Sometimes none of these match the original intent, or even what the thing does.

The worst of it is that bad names are crafty. They sneak into conversations, documentation and code. Often, they look like good names, until it’s too late.

One reason for this is that software development exists in an abstract world, where we strive for generality. We hope that by solving the general case we can promote reuse, or maximise the use-cases our system satisfies.

These intentions are noble, but I think this leads us to prematurely over-generalise. When we do it too soon, it’s all too easy to make poor design decisions because the ambiguity is hidden behind names which mean little to us.

Whose backend are we talking about?

This is most obvious when we’re talking about architectural components. I want to single out “Backend” and “Frontend” as pervasive examples of overly generic names. If you see these in the wild, beware! If they come up in conversation, there’s a high likelihood that what people think these terms mean will differ within the group.

As an example, a recent Hacker News article talked about making “your backend as thin as possible”. The article has a number of other problems, but biggest of all is that “frontend” is completely meaningless. In one organisation it might mean a single-page JavaScript application, in another it’s a Node process serving a website. “Backend” doesn’t help much either. Maybe it means a single Django app on a server that does all of your organisation’s business logic. Maybe it’s a backend-for-a-frontend (that’s a bit meta), with a load of micro-services in the background.

I know what you’re thinking: “frontend” isn’t ambiguous, and it doesn’t mean what you just wrote. But this is a real example. I know real live people, good engineers, who refer to a Node app as a “frontend” and at the same time have React components in the browser making API calls to that app. This might sound crazy, but it’s a simple and straightforward evolution, where the names “backend” and “frontend” were used on day one, and stuck.

Great, but what does “better” look like?

Figuring out what’s better is hard. Naming is one of the hardest problems in software engineering. Rather than offering a prescription for naming that can’t fit everyone’s needs, instead there’s two questions I ask when I see any name:

1. Does this name help me understand what problem it solves, and how it works?
2. Do these names mean something else (more generic, specific, or just different) in another context?

With these two tests, we can validate potential names. Sometimes all our options will fail one or both of these tests, so we’ve got the option to pick the least-bad one, or rethink the problem entirely. If we can’t find names that pass these tests I treat that as a smell. Are we trying to wedge something into an abstraction that doesn’t fit? As with all smells, it’s not definitive proof that you’re doing something wrong. It’s just a hint, a thread to pull.

A practical example

Let’s assume we have a headless content management system (CMS), with a lightweight application which uses the CMS content (among other things) to serve HTML, CSS, etc. to the browser. We could call the lightweight application the “frontend”, and the CMS the “backend”, but this doesn’t convey any meaning to a new engineer. These names fail the first test. At first glance it looks like the names convey some standard meaning, but as we’ve already covered, they don’t even tell us how it works or where it might live in our stack — a backend could be an API or a something serving HTML. So, these names fail the second test as well.

To name these better, we need more information. Let’s say the CMS serves a wide range of content for people in a care home. We know that the CMS is the only source of internally curated content, but we’ll aggregate content from third parties later on. The lightweight application serving content to the browser is only for residents, but has additional features such as chat.

A few options come to mind for the CMS component (there are myriad more, and that bike shed is left as an exercise for the reader):

1. “CMS”. Pretty basic, but short is good, right? This passes the first test of helping me understand what the service does, but doesn’t help me understand how it works.
2. “Headless CMS”. Okay, now we have a bit of information about how I might interact with it, and what it does. This looks like it passes the first test, but our noses tell us to hang on — it helps us understand the technology, but not the problem it’s solving for our users. It also fails the second test of being too generic. Our CMS solves a specific problem, so we can use the name to reflect that.
3. “Residents local content API”, flips things around a bit. This looks like it passes the first test. I can tell from the name what I’d expect the CMS to contain, and how I’d interact with it. It’s also clear it has something to do with residents, though it’s not obvious whether it’s authored by them, served to them, or both. It also passes the second test — the name feels about the right level of specificity. Another CMS could be added without confusion, and we could introduce an external content API without needing to rename anything.
4. “Residents local video series API” makes our name even more specific, but maybe we’ve gone too far. Are we confident that we’ll only ever add series of videos? Does the one audiobook on the CMS invalidate that name?

Even in this simple example, a whole bunch of questions come up. You know you’re on the right path when those questions are specific to your teams, organisation, and users.

Summing up

Next time you’re naming a service, application, or component in your code, validate them against these two tests.

1. Does this name help me understand what problem it solves, and how it works?
2. Do these names mean something else (more generic, specific, or just different) in another context?

If they pass first time then great! You’ve increased your confidence.

If you’ve tried this approach, or tackle this another way, I’d love to hear about it in the comments or [on Twitter](https://twitter.com/spikeheap).

Planning the day

To get things moving we set up a Slack organisation, a GitHub repository with a static site using GitHub Pages, and bought the remotehack.space domain name. We wanted to keep organisation and attendance lightweight, so after starting with a GitHub PR approach like SusHack we opted to open signups for the remote-hack Slack group and use chat/signups to gauge interest. We shared details on local Slack groups (Digital Oxford, Sheffield Digital) and Twitter.

We already had access to a paid Zoom account (to work around the 40 minute limit on free accounts), so created a link and shared it in the Slack. The barrier of Slack signup worked well for preventing random Zoom trolls from finding the link on Google, and made sure we had a common place to come together, kick off the day, and talk.

That’s it. We were conscious that a smaller group would likely be more sociable and reduce the challenges for the organisers, so didn’t push too hard on social media.

On the day

The start of an in-person hack day often revolves around a whiteboard to collect ideas (and a load of free pastries and coffee). To make this work for a distributed event we used the GitHub issue tracker and asked people to add ideas in the lead-up to the event.

We opened up the Zoom call 30 minutes early, and as people trickled in we had a great, informal chat before getting into things, setting the scene and then going through the ideas on the issue tracker and picking groups.

People worked in different ways. Ben and Gabor were keen to try out Visual Studio Code’s remote collaboration feature , while Mike and I paired most of the day using Screen. Adam and Ed hacked alone. Most of us ducked out of the Zoom call, but continued to chat on Slack.

When we’ve run in-person hack days like Summer of Hacks (the domain is dead, but the yellow lives on) lunch has been a pretty big deal. We’ve been fortunate to have sponsors cover custom Mexican food for lunch and use that as a lever to get everyone back together to chat and be sociable.

We really love burritos:

JSOxford on Twitter

Thanks so much to @HaybrookIT for a fantastic lunch today at #RTHack

How do you translate that into a remote hack day? We had the great idea of doing a distributed lunch, and just all ordering our burritos (or whatever took our fancy) to be delivered at the same time.

Around 1pm we rejoined the Zoom call and hung out for half an hour, chatting away as Ben and Sarah ate burritos (I’d failed to make an order in time, so just had FOMO instead), before splitting back out into our groups and cracking on.

We’d planned to close up around 5pm, and came back together at 4:30 to show, tell and chat a bit more. Mike and I were so close to adding machine learning to the sentiment-bot (well, except for me having a .dev domain problem preventing any dependencies from downloading, and Mike not having ngrok set up). By 5:30 we’d been around the groups, chatted a bit more, and closed up to go our separate ways. I headed straight downstairs for a cocktail and a call with the family.

What worked?

• A communal group call worked well for a small number of people, but could quickly become unwieldy with larger numbers. We managed to avoid the webinar-style call with everyone except the presenter muted, and really wanted to highlight the social aspect of the event.

• Starting small. Running a day with 5–6 people I knew pretty well was a pleasure, and created a great atmosphere.

• Keeping the chat going on Slack. At work I find this quite distracting, but it was great to have light-hearted interruptions during the day. It probably helped that Mike and I were building a Slack sentiment analysis bot…

• Screen for remote multiplayer/pairing. It felt like the good old days of ScreenHero, and Mike and I took turns sharing screens.

• It didn’t feel like work. Even though we were coding, it felt fun, sociable, and there was no pressure to deliver anything.

What didn’t work so well?

• Distributed lunch orders. I forgot! It’s also quite nice to jump back into home life — I went to catch up with Nev and have a quick lunch, but felt I should be back to be part of the day. When you’re all on-site there isn’t that contention, but I’m not sure which way I’d want it to go.

What would I try next time?

• Shorten the round-table ideas session first thing. We ended up talking about each idea fairly extensively, so I’d like to try keeping it to a 1–2 sentence summary of the idea, and then flesh the idea out in breakout groups so we can get started sooner.

We’ll be running the next event on Saturday the 25th of April. You should join us: https://remotehack.space.

Earlier this year I had the pleasure of working with the Department for Education, Nimble and Paper on the Alpha and Beta phases of a Find & Explore tool for the National Pupil Database. Having reflected on that experience, here’s a few lessons I hope I can apply to future projects, in no particular order.

You can’t just waltz in at full speed

Complex organisations have complex processes. Take the time early on to map out these processes through the lenses of the different departments. As an example, in addition to the GDS process (Discovery → Alpha → Beta → Live) we had Architecture Review Board and Technical Design Authority gates for technical architecture, as well as the Agile Security Framework, and Data Protection Impact Assessment. These disparate processes were entirely necessary for each groups’ governance, and once we knew about them we were able to reuse documentation across each piece.

Don’t leave assumptions unchecked

I felt fairly relaxed when we found out we’d be given a subscription on Azure to deploy our environments using ARM templates, but this feeling was based on a bunch of assumptions. We were caught out a bit when restrictive policies and naming conventions were introduced later on. Talking more with the Ops/Infra teams would have eased this pain, and would have surfaced some key information about the platform and its state of development which only came to light later on.

Being an outsider can be a real boundary

We experienced a couple of instances where we had to work hard to gain trust and alleviate suspicion because we weren’t full-time employees within the organisation, and a couple of times it was assumed we didn’t understand the nuances because we weren’t really part of government. This skepticism can be really valuable to make sure the right decisions are being made, but it made it much harder to get buy-in for some of the changes we were proposing. Other members of the team were exceptional at prioritising building relationships to overcome this barrier, and in at least one case this paid off with a key ally pushing to overcome some internal bureaucratic hurdles so we could deliver quicker.

Nev summed this up better than I could:

The lesson from this is patience — if you are doing a good thing and believe in it, then persevere.

Interactive exercises are more valuable than just talking

The team brought some interesting exercises to meetings with users and other stakeholders, for example UI sketching to capture what the users thought a perfect workflow could look like. Even basic exercises like retros and lean agendas worked well to get people involved. It may be novelty, but its amazing what a pack of post-its and sharpies can achieve.

Relationships are the single most important factor of success

Our project would have faltered in the final weeks were it not for a couple of amazing colleagues in the enterprise architecture team pushing to broker a compromise between the security and cloud infrastructure teams which allowed us to meet our deadlines.

Trust your experience

This was my first time for a number of things:

• Working on a government project
• Being part of a GDS-style cross-functional team
• Being Technical Architect on a project with a single developer
• Working with agency contract Ruby developers

When it came to estimates, I second-guessed myself. Maybe I was being too pessimistic. Perhaps I’m just not a very efficient developer. Agencies are used to working with solo developers, and agencies seem to get a lot done. Maybe I should revise those estimates.

My “pessimistic” estimates were pretty accurate in the end, but I revised them. I should have trusted my experience and shunned the self-doubt. In future I’ll use that to start a conversation rather than talking myself out of it. I could still be wrong!

People play the long game

If the project is short and someone doesn’t agree with it, they can probably just wait it out, especially if the project team is external or will disband once it’s completed. This sounds cynical, but if they’ve seen lots of short-lived projects come and go they’re likely to experience change fatigue. They’ll also learn that they’ll outlive failing projects, and that it’s (maybe often) not worth the emotional or cognitive effort of engaging with something that seems flawed. This is a vicious circle, where a lack of engagement increases the chances of the project floundering, or just not meeting their needs, which then validates the initial resistance to engaging with it.

I’ve not got an answer about how to overcome this, other than that getting them onboard is almost certainly more important than it appears when you hit that first resistance.

The team is key

This isn’t new, but it’s good to reinforce that the team makes all the difference, especially when things get tough. During the last few weeks of the project we encountered a number of technical and process challenges which knocked us back and slightly off-course. This could have been a horrible environment, as the impending hard deadline ratcheted up pressure from ourselves to deliver what we’d set out to. I’ve been there before, and that stress leads to long hours, which leads to a whole host of other problems.

What actually happened was everyone came together to keep us afloat and (relatively) sane. Having a friendly, supportive environment in the office each day made the last weeks much more enjoyable, and helped prevent us spiralling off individually as we tackled our own challenges. Tacking on “check ins” (thanks for starting that Urska!) to see how everyone’s feeling, and openly promoting mental well-being and the importance of looking after yourself first is paramount. Kudos to Jon for always putting people first, and not faltering when times got tough.

When you’re part of a great team it’s easy to take it for granted. The lesson I’ve taken from this project is to be thankful, and to take the time to let people know when they’ve made an impact.

Hi Ryan, could you do me a favour and just confirm this user’s account please?

This request didn’t pop up in Slack in the first days of a new user confirmation feature. I was seeing this a couple of years later. The single line of Ruby was well known amongst the developers (it’s hardly rocket surgery) as we’d get a couple of requests a month, and within minutes we’d marked that account as confirmed and got back to more interesting challenges.

I see it over and over again. I fall for the same thing myself, even though I should know better: failing to automate menial tasks that encumber our non-developer colleagues because there’s “more important stuff to do”.

In our case, we’d gone as far as to create an issue to track adding a user confirmation function to the admin dashboard. It was hard to prioritise it above revenue-generating stories and it languished. A couple of years (!) later we sat down with the support team and figured out this was one of two things they regularly came up against which required the dev team. This was understandably frustrating for them — support resolution times were a key metric of their performance so having to fire off a message to a group of developers who would much rather stay focussed on their current work ground them down.

It took a couple of hours to change this from something only a developer could do to a task that can be resolved by any member of the team. Not only did this empower the support team, it also reduced the amount of urgent interruptions the dev team was getting.

Value non-developers

Developer time often takes precedence because it’s so easily tied to the delivery of new features. When there’s a push for features and pressure from investors it’s easy to sideline other functions of the business. Sales and Support often benefit from being able to get insights into the system, flip check-boxes, and set up new accounts. Spending time to make their lives easier reaps dividends (if you’ll excuse the pun) not just in their productivity but also in engagement with the developers. Small businesses really need to fight to keep everyone on the same side, and it’s easy for boundaries to emerge when people feel hard-done-by.

What do you tackle?

Good candidates for enhancement fall into two categories:

1. Simple administrative tasks, for example adding users to a client organisation.
2. Reporting and business intelligence.

It may be that the development team can come up with a list of internal requests they see often, but in the spirit of engaging the whole business a great place to start is to interview representatives from each business function with a question:

If we could do one thing that would make your work easier, what would it be?

And if you like variety, a more open question which allows you to work through to the solution is:

What hiccups are there in your workflow? Where are you left needing answers from developers, or just guessing?

The development team can weigh in on the complexity of the fixes. Value isn’t just measured in time, but there’s a handy graph to give you an idea of how to evaluate time-saved vs development effort by XKCD:

Quick fix ideas

One of the most common quick-fixes is to add an admin dashboard, such as RailsAdmin. With very little custom code, your non-technical internal users can add, edit, and maybe delete records from your application. This (obviously) requires a degree of caution, but resolves a host of tiny support requests.

It’s also very common to see the business requesting simple reports from the developers, e.g. the number of registrations by month for the past quarter. Maybe these rear their heads for investor meetings or quarterly all-hands, but they always point to a more subtle problem — the business lacks Business Intelligence tools. Spending half a day installing Metabase may not only prevent these requests coming through, but also empower other parts of the business to investigate your data and start making more informed decisions. One of our clients still raves about the impact Metabase had on the whole business over a year and a half later!

So, when do you enhance?

“Soon, when we have a bit more time” is a popular response. The future always feels like it’ll be a little less busy, a little more structured. The truth is that future never comes; once the imminent hurdle is overcome the next challenge comes into view.

The time to do it is now. Always. Making tiny improvements to the working lives of your non-developer colleagues pays back many times over, compounding productivity on both sides as developers are interrupted less often (or at least, for less meanial sidetracks 😛).

The most common approach to setting aside time seems to be adding one or two items into a sprint as nice-to-haves, but this feels like it subverts the principle of the sprint because they’re often seen as lower priority (and we all know everything in the sprint scope is equal… sometimes).

Another way which looks very promising is to have one week of improvements every 4–6 sprints. I read an article a while ago which described lining up sprint starts with the beginning of a month, which built in both the internal improvements iteration week and made it easier to other parts of the business to know when sprints would start/finish (if anyone can remember where that was from I’d appreciate the link!).

There’s always the good, old 20% time approach. We’ve successfully run “Fun Friday Afternoons” where we were a bit tight and only had 10% time. The point is to experiment and see what works well for your team.

Invest in internal tooling was originally published in Honest Focus on Medium, where people are continuing the conversation by highlighting and responding to this story.

We rely on Open Source for a huge portion of the Internet (and beyond), yet many projects still rely on goodwill and donated effort in order to survive. Sometimes that’s not enough, and organisations like Ruby Together have helped to make critical pieces of developer infrastructure more sustainable. Other projects have taken the approach of introducing premium tiers, adding enhanced functionality to libraries, tools and services in an effort to generate revenue and enable the (sometimes sole) developer to spend more time on the project.

Sustainability in Open Source software development is hugely important, but we need to walk the path carefully.

How do you choose which features to include in the “pro” version of your library or product? Include too few and users may not see the value in upgrading; include too many and you may not see enough adoption of the free tier to funnel into your paid version. But I think feature choice goes further than that.

Developers are starting to adopt serverless patterns for side-projects to keep hosting costs down. Message queues and background processing are built in to modern frameworks. Federated authentication is just a library away. The lines between enterprise and personal projects are blurring.

As a community we need to push best practices. Maintainability. Accessibility. Security. Probably not in that order. We have a responsibility to remove barriers to developers using our software so they fall into the Pit of Success. If we withhold features from these categories from our free version, we’re making secure, maintainable, accessible software harder to produce, which doesn’t feel like a good thing.

Now, I’m going to pick on the excellent Ruby GraphQL library purely because finding it prompted me to write this post and having a concrete example makes it easier to think about. Authoring and maintaining this project is no small feat, and in an effort to make the project sustainable the author has created GraphQL::Pro, which adds a number of features to the free library, provides a GraphQL subscriptions stack, and adds prioritised support. The first feature jumps out:

It would be unfair to say that the free version prevented you from doing authorisation. A few walkthroughs exist demonstrating authorisation within mutations, and it’s feasible to implement your own authorisation layer in the Open Source gem. But, if this were a free feature would we expect to see better GraphQL implementations in Ruby, with less data potentially exposed to maliciously crafted queries?

Unfortunately this approach isn’t limited to independent library producers. Elastic hides almost all their security features behind a subscription (which reportedly costs >$5k USD per node):

For many organisations, this just means Kibana or ElasticSearch end up behind an nginx proxy or with no security at all. Considering how great Kibana is for visualising data, it’s easy to see how these unsecured applications end up accumulating more sensitive data. If Elastic provided RBAC and encrypted communications as part of their free tier, would we see smaller businesses picking up better security practices?

Elastic’s pricing highlights how the need to generate revenue has eaten into features that should be the right of every citizen of the Internet. Developers should be encouraged and pushed to do better security, for the sake of our users. It’s pretty easy to argue that LDAP, AD & SAML authentication are primarily used by larger organisations who have more ability to pay these license fees, but shouldn’t we be promoting encryption at rest for every use case? Doesn’t every Kibana installation deserve encrypted communications?

Frustratingly, while Elastic “opened up” X-Pack recently, all the Security features remain “pro”:

Ryan Brooks on Twitter

@elastic I've just seen https://t.co/78oTMrRXSN. Great news! Is authentication/authorisation & RBAC from Security included in the free/open features?

elastic on Twitter

@spikeheap The code is open, but it's still a subscription feature.

I absolutely support efforts to make Open Source projects sustainable. Charging for the use of libraries and services is a completely valid way to generate revenue, and we all need to eat. However, I’m conscious that we may be creating modern crippleware, where the free tier necessitates poor security practices or forces the ones who know better (and have the capital) to upgrade.

Security is not a "pro" feature was originally published in Honest Focus on Medium, where people are continuing the conversation by highlighting and responding to this story.