Thoughts from a Thirsty Bear

Feature branch workflows appear to be the flavour of the month for software development right now. At its simplest, features are developed in isolation on their own branch, then merged back to the trunk. More complicated variants exist, most notably Git Flow . Git is undoubtedly a powerful versioning tool. It makes branching easy and reliable, and it is truly distributed. These capabilities open up a whole range of possibilities and workflows to support different ways of working. But, as usual, the sharper the tool, the easier it is to cut yourself if you don't understand what you are doing. My problem is this. Feature branching is a very effective way of working when you have a large, distributed team. Code is not integrated with the rest of the codebase without a lot of checking. Pull requests ensure changes - often done by developers who are in other countries, and often part of a loose-knit open source development team - are reviewed by a core team before being inte

A wise man once said, " I've got a plan so cunning, you could put a tail on it and call it a weasel! ” Unfortunately in software it isn’t quite so easy. Simply renaming a broken process doesn’t really change the way a project is set up. Unfortunately a growing number of managers seem to believe they can turn their projects into lithe, agile weasels simply by wrapping pre-planned waterfall projects into iterations and calling it “agile". Projects like these tend to ring several alarm bells, such as: The entire project is estimated up front (usually taking up a huge amount of development team time) Stories are split by service, and not by end-to-end functionality (usually a sign that key design decisions have already been made without being validated by working code). Ie the now discredited smokestack development approach. So a team (or even separate teams!) might be developing the front end first. Then later develop one of the services the front end uses later.