Climate Action: Accelerate. Safely. But, Accelerate.

Why can’t nuclear power help Australia solve the climate crisis?

Read on to find out.

I Had To Explain The Energy Transition To My Local Federal MP…

My local Australian Federal MP, a member of the Liberal party (that’s roughly equivalent to Republican / Tory / conservative, for overseas readers) – posted a video on Facebook implying that recent blackouts in the area, as well as increasing energy costs, are Labor’s fault. It accused Labor of making energy security “partisan”, and called for “a mature debate”.

I replied, trying to stay as factual as I could, pointing out that the blackouts in NSW are the result of one third (4 out of 12) of our coal power plants being out of action, nothing to do with (unmentioned but dog-whistled in “Labor’s energy plan”) renewables, and that the finger point for a lack of energy supply likely shouldn’t go to the government that only came into power 2.5 years ago, but the (Liberal + Nationals) one that was in power for the decade before that and did little to prepare for the inevitable exit and breakdown of many ageing coal plants.

He replied – politely, I will say – asking:

Should we be closing coal early and taking it offline?
That is what is in the AEMO plan.

… along with platitudes that he is focused on the future, not what previous governments could have done differently. He also dropped in a recent quote from a very highly-paid, conservative-leaning, and polarising former bigwig of the public service, which included, “We are rushing into a third-world country.”

Here’s the thing about that question, though:
IT’S A TRAP!

Wrapped up in the notion of “early” is some sense that there’s an inherent reason not to close a coal plant before… well, when, exactly?

Anti-climate action folks like to play on this notion imbued in that word “early” to try to make climate action advocates look like we want to waste things, or perhaps even ruin society! (Ye gods, could anything be further from the truth?!)

So, I thought that trap needed addressing.

Now You Can Read About It Too…

Since he’d taken the time to write a polite, sensibly-lengthed reply, and asked a question of me, I took the time to respond in kind, though, admittedly, with a bit of passion thrown in. But I answered his question honestly – and thoroughly – I checked my facts, and I walked through the logic of why nuclear doesn’t get to have a ‘Climate Action’ badge slapped on it in Australia.

Proof-reading it before sending it to Zuck’s cloud, I thought, “Hey this isn’t half bad. Other people might benefit from reading this.” So, here it is. Hope it’s useful to you in understanding and/or explaining to others where we find ourselves.

I wrote…

Thank You For Your Reply

I think it’s important we are clear with people about what “early” means. Early in regards to closing coal plants does not mean “earlier than when the grid is ready”. It means “earlier than when the plant owners currently plan to switch them off”. 

Should we close coal plants “early” if we can? Absolutely! We should be ending all use of fossil fuels AS SOON AS PRACTICAL. Solving the climate crisis depends upon this transition happening right now, and rapidly. We should all be heavily invested in making “as soon as practical” earlier, wherever we can. So yeah, if we can accelerate when we can switch off coal generators, 100% we should do that.

This does not imply putting the grid in a bad state!
It is about accelerating the grid’s transition into a better state, where coal isn’t needed.

How do we bring forward the date when we can safely turn off coal generators? Simply: By accelerating the deployment of firmed renewables and their integration into the grid ASAP.

On nuclear power: It has no role to play in accelerating the transition [in Australia]

Unequivocally. Why?

Currently half of remaining coal fleet owners WANT to retire their plants by 2035, with those closures being voluntarily brought earlier all the time. AEMO’s ISP (that’s the long-term national plan for Australia’s electricity) advises us that, for Australia to meet our climate goals, that needs to be closer to 90% by 2035.

There is no pathway by which starting a nuclear power industry here is going to deliver any power before 2035, and yet ALMOST ALL of our coal should be replaced BEFORE then to meet our goals. That means it can only be replaced by firmed renewables. (Or those who speak on behalf of the gas lobby might say lots more gas, too. But that would be giving up on the climate goals.)

What’s great news is this: Renewables don’t need a debate, don’t need a new industry, don’t need 15+ years of lead time, and don’t need to be 100% bankrolled by taxpayers. Firmed renewables are available now, are cheap, and constantly getting cheaper, and there’s a huge industry and workforce ready and willing to roll them out.

There is a narrative from fossil fuel lobbies and many conservative politicians and pundits, trying to fool people into thinking that the people most vocal about climate action want to do it faster than it’s safe to do. That is a straw man argument.

What people concerned about the future want is to accelerate a safe and just transition, not a transition faster than is practical. That is why all this talk about nuclear is so infuriating and concerning, because a plan for replacing coal with nuclear power in Australia can only achieve delay, not acceleration.

P.S. I think talk of Australia becoming a third-world nation is farcical hyperbole, and I don’t think it belongs in a mature debate, as your video calls for.

Microservices: The Benefits and Costs

'Mycenaean Bronze Scales' - a set of ancient, bronze scales. Any tech team should weigh microservices benefits against their costs before deciding whether to make the switch. Photographed by Mark Cartwright.

If you work in tech, you’ve almost definitely heard about microservices: the trendy style of software architecture where a system is split into multiple, independently-releasable services, that are modelled around business domains, and communicate via a network. Some people rave about all the amazing things they’ve achieved by using microservices’ benefits. Others rant about how much of their time it wastes and how much they hate it.

Like pretty much everything in tech, microservice architecture is a trade-off. Will it do great things for your organisation or not? That depends largely on how well set up you are to take advantage of the benefits and to absorb the costs.

Microservice Architecture is a trade-off. Whether it's going to do great things for your organisation depends on how well set up you are to take advantage of the benefits and absorb the costs. Read more: Microservices: The Benefits and Costs Share on X

If you’re looking to make a decision about whether to use microservices in your team (or reverse one!), here’s a list of many of the pros and cons which you’ll want to consider.

Continue reading

Using Microservices to Make Costly Deployments Less Frequent

This article on costly deployments is part of a series on How to Choose Your First Microservices.

Switching to a new software architecture style is costly. I advocate choosing where to employ microservices first by using them to solve existing problems in the team. This helps the organisation extract value from the new architecture with each step towards the new world. This series is working through a set of problems that your org may have, and how microservices might help solve them.

Tricky Deployments

A fighter jet on an aircraft carrier being signalled to launch by two ground staff. Launching a fighter jet is a costly deployment, just as deploying a monolith may be.

Some components of your system will be tricker to deploy than others. This is true regardless of whether you’ve already got microservices or you’re deploying a monolith. Some components might be in use by 1000s of customers 24×7, while others might only be used once a month. Upgrading a component might require other components to be placed into a certain state, while others can be upgraded independently of the rest of the system. Coordination may be required between multiple teams in order to effect a trouble-free deploy of some components, whereas others might be actioned by a single person.

Continue reading

Using Microservices to Solve Developers Stepping on Each Other’s Toes

This article on reducing merge conflicts is part of a series on How to Choose Your First Microservices.

Switching to a new software architecture style is costly. I advocate choosing where to employ microservices first by using them to solve existing problems in the team. This helps the organisation extract value from the new architecture with each step towards the new world. This series is working through a set of problems that your org may have, and how microservices might help solve them.

Is your team wasting a lot of time working around each other?

A side-collision car crash at an intersection, surrounded by emergency personnel. Like this, merge conflicts can be messy and dangerous.

If you have a large team of developers working in a single code base, it’s inevitable that the work of some team members will interfere with the work of others. Many of us are now using tools (like git) and processes (like continuous integration) that can lessen the impact of interference. (Although other modern practices like feature branching can make conflicts worse.)

Continue reading

Using Microservices to Solve Slow Build Times

This article on slow build times is part of a series on How to Choose Your First Microservices.

Switching to a new software architecture style is costly. I advocate choosing where to employ microservices first by using them to solve existing problems in the team. This helps the organisation extract value from the new architecture with each step towards the new world. This series is working through a set of problems that your org may have, and how microservices might help solve them.

Slow Build Times?

A snail crossing a road, which might happen faster your slow build time.

Does your team have an application that takes a long time to build and run tests? Is a large portion of the development team working on it? That could be a huge amount of idle time you’re pouring down the drain. The classic XKCD ‘Compiling’ comic makes light of developers enjoying the time they spend waiting for their code to build. The truth for most devs is they would far prefer to be making fast progress on their work than sitting around waiting.

Continue reading

How to Choose Your First Microservices

Are you early in your microservices journey? Maybe you’ve decided you need to start deploying applications outside your monolith but you haven’t cut any code yet. Or maybe you’ve put your first few services into production and addressed some of the first pains that happen when you start on that path.

A large number of interacting LEGO cogs making one large machine, similar to a monolith from which you want to break out your first microservices

A common question that comes up for teams at around this time is:

“What should we split out into a microservice first?

And why?”

Continue reading

Feature Flags and Test-Driven Design: Some Practical Tips

A country road with a fork going off to one side, symbolic of a feature flag in codeIn 2018, our team spent a lot of time working with feature flags and test-driven design (TDD).

Our project was to effect an architectural change to our system, changing the source of truth of some data, moving it out of the database owned by a legacy monolith into a new database controlled by a new microservice. However, much of the code requiring the data would remain in the monolith.*

Some examples of the types of things we feature-flagged are:

    • whether to go down a refactored code path or not;
    • whether to publish messages to a message queue when a certain event occurred;
    • how to publish those messages (we tried multiple variations of batching and transaction boundaries to achieve acceptable performance);
    • whether to just delete messages at the receiving end or actually handle them; and
    • whether to use a local source of data or remote one.

We were working on a pretty important piece of code; the kind of business function where, if we stuffed it up, someone would probably have to spend several days doing remedial fixups or making phone calls to chase up millions of dollars. Continue reading

Time to Evolve Again

My mid-2000s, fresh-faced, professional look from around the time I joined Tyro.

After 12.3 years, yesterday was my last day at @Tyro. 😢

It’s been a huge journey, from a perilous payments startup with less than 20 employees and only ☝🏻 customer, to now a VC-backed, fully-licensed bank with well over 400 staff that is Australia’s 5th largest EFTPOS provider (by transaction volume).

I’ve done time as a Software Engineer, Development Lead, Engineering Lead (part of the management team), Technical Project Manager, Team Lead, Product Lead, and this last year, back to Software Engineer. I must have hired 50+ (awesome) people and interviewed many times that.

Continue reading

“This work kinda sucks right now”: Staying motivated in the uninspiring phases of long projects

In April 2015, I was the technical project manager of six software teams all working on one gigantic project. It was the biggest challenge the company had ever taken on. The goal: create and stand up a transaction account product for small and medium business so that we could apply for an unrestricted bank license.

Tired marathon runner with hands on hips

We were 12 months in and were about to finish the project bang on the week we’d estimated, when the inevitable happened: we received a new raft of requirements that would add at least another 3 months of work. The extra work wasn’t glamorous; it was mostly security enhancements, disaster recovery preparation, and a complicated behind-the-scenes tweak of the product that added little benefit for users but was a requirement from a regulatory point of view.

Understandably, morale took a hit, but we needed to keep the pace up or we’d risk missing the deadline we’d been set for acquiring our license. After an interesting discussion with my father-in-law about the project, I found a new perspective on where we were at, and it prompted me to write the internal blog below to help motivate the team towards our final goal. Continue reading

9 fascinating things I learned while coding up the rules of a board game

I recently decided I was going to take the rules of the board game Forbidden Island and write them up as code.

A screen full of code in an IDEI guess that sounds like a weird thing to just decide to do, doesn’t it? It’s actually one part of a bigger goal I have at the moment of teaching myself some practical machine learning. As part of this journey, I heard a great idea from YouTuber Jabrils to set yourself a significant challenge that you’re interested in, and to work towards surmounting that challenge. For Jabrils, his challenge was getting an AI to control a Forrest Gump character to run around a course in a game. For my challenge, I’ve decided I’d like to build an AI that can play Forbidden Island. (And win!)

Obviously, if you’re going to have an AI play a game, you first need a digital version of the game for the AI to play. Continue reading