I quickly learned that you cannot build a website out of nothing. Before anything actually gets made, you have to pick the tools you are going to use to make it. So without realising it, the first thing I did wasn't building a website at all. It was trying to choose a platform to build one on.

My first instinct was to go for the fun part. The first platform I thought about using was Vercel. A friend had told me you could push your own code and have a live website within minutes, which sounded exciting until I started thinking about who would maintain it after I was gone, at which point the excitement cooled noticeably. So I kept looking. Then Wix. Then Notion. That evening I alternated between the tabs I had open and made absolutely no progress, picking one platform over another and then endlessly justifying my choice. I was losing a battle with myself, which is the most annoying kind of battle to lose.

I had quietly jumped from "build a website" to "choose a platform" without noticing, and then it went a rung deeper. The problem wasn't picking a platform. The problem was that I had no rules for picking a platform. I was choosing based on whichever option looked nicest to me ten minutes ago. Then a slightly unpleasant thought came to me. Picking a platform is work. It is an actual task, just like building the site, or writing, or anything else. And task work cannot be done on gut feeling. There has to be a process. So the first task wasn't deciding which website-building tool to use. The first task was deciding how I was going to decide which website-building tool to use. I had to build a process, then run the process, then decide.

What got me there was, of all things, curiosity. I had hit a dead end and figured: people build software for a living, surely they have a better way of choosing software than I do. So I looked it up. It turns out professional software engineers have a very dry, very structured way of making decisions, and they actually write the reasoning down beforehand. The format even has a name. An ADR, short for Architecture Decision Record. I borrowed the system.

The funny moment came when I started writing my first one. I was using the ADR format, and when I got to the "A" for "architecture," I had to pause. I wasn't designing any software. I was choosing a way to decide. I almost gave up on the format right there, until I realised that what I was choosing was architecture, just not software architecture. A method is a way of structuring how a team works and decides. That is organisational architecture. So it actually belonged in an ADR. This became ADR-1: the method itself.

The method I landed on had two steps. First, score every option against a set of hard criteria and throw out anything that fails any of them. No exceptions, no special cases, no rescuing your favourite option just because you like it. Then take what is left, and score those options against what each team member weights as most important. The second pass makes sure that a small win on something genuinely important doesn't get cancelled out by a small win on something trivial.

The process forced me to be honest with myself about who I was actually building the website for. I will be graduating in two years.

The people who will come after me to update the site, to post events and announcements, are not programmers and won't be. The only person who could realistically deal with a technical problem on the site is me, and I will not be there. Engineers have a slightly dark term for this sort of situation, the "bus factor." How many people would have to be hit by a bus before the project is abandoned? Mine was one. Me.

Only one thing defeated my first choice. I wanted to build something impressive. Something custom-coded, fast, and showcase-worthy. I could have built it. But once I was honest with myself that I would be the only person on Earth able to maintain it, it failed one of my own criteria, and I had to drop it. No matter how much I liked the idea.

The options I had been least excited about were the ones that remained. I scored them, and the clear winner was Google Sites. By far the least exciting option on my original list. The right answer was the boring one. That frustrated me for about a day. Then it stopped frustrating me, because I understood why. A website that goes dead the moment its one technical person leaves isn't a better website. It is a worse website that happens to be clever.

Looking back, the choosing itself had two distinct steps rather than one. Step one was choosing the method. Decide how I would decide, then write it down. That became ADR-1. Step two was the actual choosing. Run the method, score the options, write down the outcome. That became ADR-2. Only after both of those steps did I actually open a browser and start building.

The detour cost me about two evenings I had set aside for coding. They were two of the most useful evenings of the whole project, and I don't think that had very much to do with the website itself. It was the first time I caught myself falling in love with the most complicated option, mid-fall. Before this, I had been optimising for what would impress people, and what would impress me, rather than what would actually be useful for the club after I was gone.

So I ended up with two of these records. ADR-1 contained the method, the rules I would use to choose. ADR-2 was the result of actually applying the method, written up the same way. Two steps of work, two records. I like that they exist. They show that the choice wasn't made impulsively, and they leave a note for whoever inherits the site about why it is the way it is. They are included below, in all their boring formatting.

Architecture Decision Records:

1. ADR-0001: Decision-Making Methodology for the Green Club Website

2. ADR-0002: Website Platform for the Green Club

What is the best way to locate an unseen and inaccessible leak in a pipe that we cannot dig out and repair?

My idea is that the solution is actually a simple answer. It is mathematics. More specifically, a type of math that originated about 200 years ago with a Frenchman interested in the movement of heat through metal.

Everything can be considered a signal

When sounds are made, changes in the air pressure are made over time. The sound of a heartbeat is the measurement of changing voltages over time. A pipe that is leaking also produces a vibration that is a measurement of amplitude changing over time. While most things can be considered a measurement of a changing signal, there is a problem. If you are looking at a raw measurement of a vibration, it will most likely appear to be a chaotic mess. It will be an honest measurement of a signal, but a wholly meaningless display of one.

This is represented in the graphs below.

The Cake and The Recipe

One raw signal is like a cake with no recipe. A raw signal is essentially a cake and with no recipe you can’t really decipher what the ingredients are. When you see a cake you probably think that the cake is the final product and the recipe is the process behind the creation of the final product. The Fourier Transform is the machine that turns the cake back into the recipe. The Fourier Transform tells us that any raw signal can be constructed by simple sine waves and that every frequency and every raw signal completely describes itself and makes a unique fingerprint and will be found by the transform. Just by knowing this and how to describe these simple sine waves allows us to create MRI images and Wi-Fi, MP3’s and JPG images.

Listening to The Pipe

When pressurized water leaks out of a pipe it causes a vibration in the pipe. When this vibration occurs it then starts a chain of acoustic emissions and these emissions will spread throughout the length of the pipe. If you put sensors above the pipe in the location where the emissions have spread, you can use the Fourier Transform and cross correlate both recorded signals. The time delay between when the emissions are heard will provide a location of the leak, sometimes within a meter of where the actual leak is, without having to lift a single paving slab.

The telltale sound of a leak is determined by pipe type. For metal, it’s the 100 – 1000 Hz range. For plastic, the range is 20 – 250 Hz. However, these frequencies are coupled with a 50 Hz mains hum, noise from low-frequency traffic, pumps, and random thermal noise.

In these situations, the philosophy of “noise” becomes interesting. Noise is not incorrect data. Noise is everything in the data that does not pertain to the answer of the question posed. To a leak hunter, a rumbling bus is considered noise. To a bridge engineer, the leak is the noise.

Same Data, Different Lens

The best example I could provide the club was the following. Take a recording that looks like chaos, and apply the Fast Fourier Transform. Suddenly, you can see. The rumble of the low-frequency traffic is in a clump on the left. The sharp spike of the mains hum is at 50 Hz. In the leak frequency range, there is a suspicious peak. Something is in that pipe.

You have not altered the data. You have altered the question to something you can now see.

The Bigger Picture

I wanted to end my lecture with a statement I hold dear. New infrastructure is simply old hardware and a new way to think about math. Civil engineering is becoming an information science.

Many infrastructure failures have tell-tale signs long before people realize they are happening. Data repeatedly sent out. The only question is if anyone is picking it up.

This was a lecture that lasted about an hour and a half. We began with signal math and moved into the Fourier Transform. After, we played a real pipe recording. We finished by revealing a hidden leak using frequency spectrum. If you want to go deeper look up acoustic leak detection and cross-correlation, and be warned: the rabbit hole is very, very deep.

My full presentation below

How To Hear A Leak

1.1MB ∙ PDF file

Download

Download

:

Our certificate was signed by Professor Clemens Kaminski and Raffaella Ocone OBE. It describes the award as being given for "showcasing exceptional creativity, groundbreaking innovation, and a passion for solving real-world challenges." I have read that sentence at least twenty times. I hate it, appreciate it, and am grateful for it, all in roughly equal amounts.

This is the story of how we built it, and why. The problem we set out to solve isn't the kind of problem that gets solved easily, but we figured we should at least try.

Millions Live Without Safe Drinking Water

More than 2 billion individuals do not have safe drinking water. We researched and studied the statistics, and we were shocked to find that, in Sub-Saharan Africa, approximately 33% of the population rely on surface water that could be contaminated with waterborne pathogens.

The standard way to check if water is microbiologically safe is to culture a sample in a lab and measure how much grows. It's reliable but slow. One to three days, typically. If you are standing in front of a stream right now, wondering whether you can drink from it, three days is not a useful answer.

So we asked ourselves the question: could you build something that gives an answer in minutes, costs almost nothing, and runs on sunlight? It sounded slightly insane when we wrote it down. But that was the goal.

What we invented: the Firefly Hydrolyte

The solution was the device, the Firefly Hydrolyte, which is portable and completely reusable, and tests water for four parameters:

- Microbiological activity, via ATP-bioluminescence, which is the same chemistry that produces glowing light in fireflies. Since ATP is a biomolecule and exists in all living organisms, its detection is a rapid and reliable indicator of the presence of an organism in the water.

- pH, in case of chemical imbalance.

- Total Dissolved Solids (TDS), which is a quick measurement of dissolved ionic contamination.

- Temperature, which, as I’ll elaborate, is of more importance than it seems.

We made the output deliberately simple. A safety rating from 1 (unsafe) to 3 (safe), shown on a small screen. That wasn't the plan at first. Originally we had a much fancier interface with numbers, units, and graphs. Then we surveyed potential users, and almost every one of them said the same thing: just tell me if I can drink it. We overhauled the design around that.

The feature that I lost the most sleep over

My job on the team was to get the device to self-calibrate and run on solar power. It turned out to be the hardest part by some distance.

Here was the problem. The enzyme that makes the glow happen, luciferase, is fussy about temperature. The same water sample will produce different amounts of light depending on how warm the water is when you test it. If you don’t account for this, your readings are just wrong. And a water tester that gives wrong readings is genuinely worse than no tester at all, because at least with no tester, nobody is being lied to.

So I used published activity data to draw a curve relating luciferase activity to temperature. With that curve, you can take a raw light reading at any temperature, work out what fraction of peak activity the enzyme is running at, and back out what the reading would have been under standard conditions. We built that logic into the device. I also added a precaution: if the temperature or pH reading is unreasonable, the device throws an error rather than confidently making things up.

The same self-calibration logic applies to the hardware overall. The device doesn’t slowly drift out of accuracy, and doesn’t need a reference standard to stay reliable. It also runs on solar power, which means it can be used out in the field, where wall sockets tend to be in short supply.

One of the biggest lessons I learned came from the many attempts to get that curve right, not from the things that worked out on the first try.

Testing

This was not a "poster and pray" project. We built a working prototype around an Arduino, wired up the sensors, and tested it with real water samples.

Below are our three test samples, in increasing order of how “dirty” we thought they were:

• Filtered tap water was 87 mg/L (which is a safe drinking water level) and received a safety rating of 3.

• Regular tap water measured at 303 mg/L.

• As for the water with dirt, which measured at 838 mg/L, the device was right to flag it as a very serious issue.

We also compared pH across a few different solutions. For fun, we ran some Coca-Cola through the device, which came back at 2.61. That is exactly the pH of Coca-Cola, so the device passed its surprise audit. The results across the board matched what we expected, which was the first real evidence that the design actually worked.

What this taught me

The thing I'm proudest of, looking back, is that the whole process actually held together from start to finish. We started from a real problem, grounded it in the literature, looked at existing solutions and where they fall short, talked to actual potential users, designed around what they told us, built a prototype, tested it against controls, and refined it based on what came out. None of those steps got skipped, even the boring ones.

I honestly didn’t expect a school project to involve all of that. But I think this is how real engineering projects more or less go, and finishing one made me appreciate the profession quite a bit more, especially given that we wrapped this one up when I was sixteen, about to turn seventeen.

The UN’s Sustainable Development Goals 6 (Clean Water) and 12 (Responsible Consumption) were both on our minds when we designed the device. Being recognised as Highly Commended by Cambridge and IChemE mattered to us, not because of the award itself, but because it felt like a signal that the idea was worth building further.

Thanks for reading. More soon.

My job was to make sure the device actually delivered on the claims we were making. That the readings could be trusted. It turned out to be a lot more interesting than I expected.

How the Device Detects Contamination

The main trick comes from the firefly. All living cells contain a molecule called ATP. There is an enzyme called luciferase that reacts to ATP and produces light:

The brightness is proportional to the amount of ATP in the sample. High ATP means a lot of living cells, because ATP breaks down once a cell dies. So a darker reading is actually the reassuring one. A bright reading means the water might be dangerous, which is the opposite of what your instinct says. The sample passes through a luminometer that counts the photons, and an Arduino turns the count into a safety rating from 1 to 3.

This would be the whole story, but it actually isn’t.

An Inherent Problem with Chemistry

Luciferase is fussy about temperature. Most enzymes are. When they get cold they go sluggish. When they get hot they fall apart. So the light output doesn't just depend on how much ATP is in the water. It also depends on how warm the water was when we measured it.

The published info on this is practically all we have (Activity curve from the literature — Bechara & Stevani, 2018):

Since we didn't have a lab where we could measure enzyme kinetics ourselves, we used published values as our starting point. Worth flagging that this introduces real uncertainty. Published enzyme curves vary between studies, and the conditions in our device (buffer, pH, reagent purity) aren't identical to the conditions in the paper. We took the best data we could find and assumed it was close enough. Usually a fine assumption. Sometimes not.

Between 25 and 35°C, the enzyme runs at near 100% activity. At 5°C it drops to 50–70%. Above 37°C it falls off sharply. In practice, the same contaminated sample could glow nearly twice as bright on a warm afternoon as it would in cold mountain runoff.

This was the first real crack in what we’d built. I’d been assuming the device measured contamination. It doesn’t. Without correction, it measures contamination plus whatever mood the enzyme happens to be in that day. Two variables collapsed into a single number.

The Firefly Hydrolyte is meant to work outdoors, often near streams that can be much colder than a room. A device that only works at room temperature isn't very useful in the field. And if the same stream gets rated Unsafe in July and Fine in February, same water, just a different season, the rating can't really be trusted.

The fix: measure the temperature, then undo it

The correction has three parts. First, add a temperature sensor. Then use the activity curve to scale the raw reading back to what it would have been at the enzyme's peak activity. That way, readings can be compared regardless of the temperature at which they were taken.

The last step is a pretty basic math idea:

So if you measured a light output of 50 from a sample where the enzyme was running at 50% activity, the corrected value would be 100. If you measured 100 from a sample where the enzyme was at 96% activity, the corrected value would be about 104.

The hardest part was getting “relative activity at any given temperature” to actually live inside an Arduino. Published data only gives values at specific temperatures, but a sample could be at anything in between. We needed a continuous function. I ended up fitting a quartic regression to data points I'd read off the curve in Desmos:

You plug in a temperature, get a relative activity, and apply the correction. There is also a fail-safe. If either the pH or temperature reading is unreasonable, the device throws an error rather than confidently reporting nonsense. Since the entire problem we were trying to solve was the device confidently reporting nonsense, the fail-safe was not optional.

A quartic isn't meaningful in a biological sense. There's no theoretical reason enzyme activity should be a fourth-degree polynomial. But given the data we actually had between 5°C and 40°C, it was the best fit available. Honestly, it was also the only fit available. The fail-safe boundaries were there to stop the regression operating outside the data range, where it could happily generate garbage with full confidence.

Did it work?

We tested three samples. Filtered tap water (clean), unfiltered tap water, and water we'd deliberately contaminated by adding dirt to it.

The results for dissolved solids were 87 mg/L, 303 mg/L, and 838 mg/L respectively, and the temperature adjusted safety ratings on the prepared samples were reasonable for the scenario.

What I learned

Most of the work that goes into a device like this happens in places nobody can see. The people who look at it don't see the correction equation. They see a number on a screen that is, conveniently, correct. What this project taught me is that a measurement is only ever as good as your model of what you're actually measuring. The gap between the glow and the contamination is where the most interesting, and the most worrying, part of instrument design lives.

Some context. A few classmates and I built a portable water-quality tester that uses a firefly enzyme called luciferase. Luciferase glows in proportion to the biological activity in a water sample, which is a very neat property to have, except that luciferase is also fussy about temperature. Cold makes it sluggish. Heat makes it fall apart. The brightness of the glow ends up depending not just on how much life is in the water, but on how warm the water happens to be. My job was to deal with that. Measure the temperature, work out how much activity the luciferase had lost, and adjust the reading back to a standard.

To do this, I needed a way to express any given temperature as a "percent of peak activity." The published data I had was only available at specific temperatures, but a real sample could be at anything in between, so I needed a continuous function. I decided to use a quartic regression. Below is the equation I actually shipped.

Substitute a temperature in, get an estimated activity percent out. Not mathematically correct, but functional.

Why it’s wrong

There is no fourth-degree function in a biological sense. Nothing in enzyme kinetics is fourth-degree. I picked a quartic because it happened to fit the data nicely between 5 and 40 °C, which is the entire scientific reasoning behind the choice.

The real curve is the result of a balance between two competing things. The reaction rate goes up with temperature, while the protein itself starts denaturing as it gets hotter. A proper model would combine both processes and would have parameters with actual physical meaning, like denaturation rates and activation energies. My parameters mean nothing. They are the numbers Desmos handed back.

This sounds like a cosmetic issue, but it has teeth. My polynomial is only reliable between 5 and 40 °C. Outside that range, a quartic is free to go wherever it wants. It can shoot off to infinity, while in reality the enzyme would have given up entirely. My function will happily hand back a confidently wrong number. This is the worst kind of failure. Not a crash, not an error, just a number that looks fine and is actually completely false.

So why keep it?

The question I had to answer was not "what is the most correct model of this enzyme?" The question I had to answer was "what is the most correct model of this enzyme for a cheap device that has to run on an Arduino in the field and never mislead anyone?" Those are very different questions. A lot of engineering, I think, is about quietly answering the second one while everyone assumes you've been answering the first.

A research instrument needs the mechanistic model, because accuracy is the whole point and the extra complexity is worth it. A two-pound microcontroller in a portable water tester is a very different thing. Within the range of temperatures water can realistically reach, the quartic and the "proper" enzyme kinetics model would probably give nearly identical answers. The extra rigour would buy me accuracy I cannot actually use, in exchange for more complex code running on hardware I barely trust to begin with.

What justifies the decision isn't the polynomial. It's the fact that I bounded the polynomial honestly. There's a fail-safe. If the temperature or pH reads an unreasonable value, the device throws an error rather than guessing. The quartic is not allowed to operate in a region where it would be lying. That guardrail, not the polynomial itself, is the part of the design I would defend the hardest.

What this changed about how I think

I used to think the most complex solution was always the best one. I thought of approximations as a more rigorous answer that just hadn't been figured out yet. I don't really think that anymore. An approximation that is understood and bounded can be a better engineering choice than a precise solution pointed at the wrong problem.

I don't want this to become a crutch or an excuse. The honest position isn't "approximations are acceptable." The honest position is: I can tell you exactly how my model fails, where it fails, and what I have in place to make sure it doesn't fail dangerously. Not knowing how your model fails is dangerous. Refusing to figure it out is worse.

If I come back to this project, the first thing I would do is not redesign the device. The first thing I would do is run the experiment. Swap in a proper denaturation-based model and see how much accuracy I actually gain across realistic water temperatures. I suspect the answer would be "not much," which would justify the original decision. But I don't know yet. And really, the point isn't whether I turn out to be right. The point is that the trade-off needs to be tested, not just assumed.