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

Notes from YOW! 2014: Jez Humble on ‘The Lean Enterprise’

I attended YOW! Sydney 2014 and thought some people might get something useful out of my notes. These aren’t my complete reinterpretations of every slide, but just things I jotted down that I thought were interesting enough to remember or look into further.

A man in a suit, who probably works for an enterprise, running in a marathon and looking very agileJez Humble (@jezhumble), co-author of ‘Continuous Delivery’, spoke on The Lean Enterprise, specifically “the principles that enable rapid, software-driven innovation at scale” and how to transform organisations. (Slides)

He briefly covered the three horizons method of innovation and highlighted that you actually need to plan and be executing on all 3 at any one time. They also need separate management styles and reporting lines so that they don’t try to squash each other in departmental trade-offs or management bunfights. The two management styles are explore (discover new stuff) and exploit (capitalise on existing assets). Continue reading

Are Git and Mercurial Anti-Agile?

Drainage pipes running down the wall of a factory, branching and merging as they descend, similar to the disorganisation that branches can cause in Git and Mercurial.This is a question I’ve been asking myself for a while. It’s not a fully-thought out argument (that’s why it’s still a question), but it’s a train of thought that I think warrants some investigation. I’d love to get some opinions from people with good or bad experiences of using DVCS with Agile as to how this plays out practically.

So, here’s my train of thought…

Easy branching and merging is the killer feature of Git and Mercurial.

They improve on other centralised systems (Subversion, CVS) in many other ways, but branching and merging is the reason that’s always used to sell the switch. The question I want to raise is whether branching and merging are good tools for an agile development team, or a nuisance. Continue reading

Meetup Digest: Migrate to DVCS Sydney (October 2012)

Two weeks ago, I and a couple of other developers from Tyro went to the first “Migrate to DVCS Sydney” Meetup at Atlassian’s new headquarters. Here’s my notes on the most salient points from the evening (with some editorial by me in italics) …

Talk 1 – Jonathon Creenaune from the JIRA team

  • Know why you’re migrating. I’m sure he meant, and may have even said: have a business reason to change, don’t just be a cargo cult.

Continue reading