Monitoring Driven Development and throttling your own network

Recently CompareTheMarket sent me to a conferene in London called Progressive .NET Conference .

Here are two great ideas for the sessions:

Monitoring Driven Development

This comes from the talk ‘Testing in Production’ by Gel Goldsby.

You are hopefully familiar with the red, green refactor cycle from Test Driven Development (TDD):

What if we could use the same principles on business-facing projects. What if we could do TDD with our stakeholders?

Imagine your company asks you to increase the percentage of visitors who create an account. Or decrease your site’s shopping cart abandonment rate. How can monitoring help?

Red: show it failing

With monitoring driven development, the first thing to build is a dashboard showing the current situation. This allows you to set a baseline before making changes. It also helps everyone agree on the metric for success.

Recently my team was asked to improve page loading speed. The first thing we shipped was a Slack integration. Its sole purpose was to display the Google page speed score each morning.

The Google page speed score (out of 100) for our homepage

That allowed us and non-technical stakeholders to:

1. assess the current situation
2. agree what success would look like

Now that we have a ‘failing test’, we can start improving things. Initially, we set a goal for both desktop and mobile scores to be above 80.

Green: write the code

Every time we made a change, the monitoring showed the impact. As we ship improvements, we can move closer to a ‘passing test’.

We can also refine the metrics with stakeholders. For our team, we realised we wanted to measure the score of more pages. And also added the speed index metric. Finally, we decided to add emojis to indicate if we were making things faster 😊.

Starting to measure score per page. Adding the speed index (and emojis).

Now stakeholders don’t need to request status updates as frequently. Anyone can look at the dashboard and see the progress. And as you can see, we eventually hit our initial goal of 80 on mobile and desktop.

Refactor: change with confidence

Now that the dashboard is showing a satisfactory result, it’s time to set up alerting. That way, you can keep iterating with the knowledge that you’ll be informed if things get worse.

The whole team is alerted when our mobile page speed score drops

Alerting informs us as soon as the score drops. The speed of alerting helps us quickly isolate the relevant commit.

Idea #2 — Throttle your own network

This comes from the talk ‘The Development Platform Landscape in 2017’ by Carl Franklin and Richard Campbell.

The central idea here is that the developer device != user device .

For example, many developers check your website on a large monitor with good wifi:

But this is how most users see the site:

This discrepancy hides problems from developers. Users on their phones with 4G can encounter issues that developers may never experience on a monitor with WiFi.

Here is our site loading on WiFi:

It loads in 1.38 seconds.

Compare that to the experience on ‘slow 3G’ below:

It takes about 30 seconds to load.

The user has to wait 18 seconds to see our ‘call to action’ buttons.

This prompted many questions in our team about performance and development priorities. You can emulate a 3G connection yourself via the dev tools if you want to improve this.

More radically, consider having ‘3G days’ once day per month. All devs throttle the connection for your website to 3G or 4G. See what kind of improvements you identify!