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

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