Water Monitoring

In some of my previous posts, I talked about my journey towards monitoring every aspect of my home. For a long time now I’ve been measuring temperatures, electricity and gas usage, solar power and more. One area that has been on my target list from the start was our water usage - not least because a few years ago we had a leak that went undetected until it became a fairly significant problem. Recently while my plumber was doing our annual gas boiler service I asked him to fit a water meter which has allowed me to finally start tracking this data.

The key discovery that allowed me to do this was that you can get “pulsed” water meters (I used this model from B-Meters). They come preequipped with an inductive reader, and have a couple of wires you can connect to that receive a pulse for every litre of water used. Installing the meter was relatively straightforward for my plumber, despite the cramped space he had available.

LeadDev London 2024 (Day 2)

This is the second part of my write up of the LeadDev London 2024 conference. To read my thoughts on the talks from day 1, and my overall impression of the conference please read my previous post. As with that post this is just the summary of my notes, so will give you a flavour of the talks. This should help you decide if you want to pay for a digital pass to access the videos, or if enough time has passed to look them up on YouTube or the LeadDev site.

In the afternoon I attended a workshop by a couple of Google engineers on DORA. I’ve watched the recording of the talks I missed, so I’ve included my thoughts on those below. My write-up of the workshop is at the end of this post.

And with that out of the way, on with the talks…

LeadDev London 2024 (Day 1)

In what is fast becoming an annual tradition I recently switched on my Slack out-of-office, packed up a bag with plenty of room left for some conference swag, and got on the train to the Barbican for LeadDev London 2024 (see my review of 2022 day 1 and day 2, and 2023 day 1 and day 2). As with last year, this is a one-track conference focused on leadership and engineering management, with a separate one-track conference at the same time, StaffPlus, focused on Staff+ engineers. I only have a ticket to LeadDev, so I only got to see those talks.

What Do You Want From A Team Meeting? A Decision Or A Team?

Most teams will have a team meeting on a regular schedule. Once a week, every two weeks or once a month the team gets together to discuss the day’s big issues. This can be a difficult meeting because it doesn’t have a defined agenda, and is open-ended.

Other meetings either drive a project forward, solve a specific problem or implement a specific process. They might have a varying agenda, but the overall goal of the meeting is (hopefully) clear, and there is a point when the meetings will stop. Barring the team disbanding, this is not true for team meetings.

A common pattern, and one I am certainly guilty of, is asking people what issues they would like to discuss, and perhaps sharing a few updates from around the business. When you get to the end of the agenda you just say “Thanks everyone” and go back to your desks.

The problem with this is that you are encouraging people to just bring existing problems to the table, and then only if you manage to get the culture to be non-threatening enough that they feel comfortable with sharing their issues with the group.

Balancing Standardisation With Innovation

In my earlier post Sustainable Software Development I talked about how to build software that can be maintained and improved over the long term, and how to run teams that can work without burning out. In this post, I want to expand on one area of this - how to maintain innovation while using standards to reduce diversity in your code base.

Snow-flake applications, which have unique characteristics compared to others in your estate, take a significantly outsized amount of time to maintain. This extra complexity requires specialist knowledge in your developers, and the time taken to context switching between applications is increased. You also don’t benefit from the economies of scale, where you can apply improvements across many of your applications simultaneously.

Historically, sharing code across applications would be done through shared libraries, but the modern software development landscape is more complex and many companies are moving to Platform-as-a-Service models (PaaS). This is where the infrastructure used to run an application is more than just a server with a CPU, some memory and a disk. Instead, it is a whole ecosystem of APIs, developer tools and a platform for running code. Whether internally developed, or purchased from an external company, PaaS systems are chosen because they abstract developers away from much of the drudgery that previously they would have had to work through, but this also constrains them to only using services provided by the platform.