Softwire Blog

Using git-tfs in anger

31 August 2016, by

A while ago I wrote about how no-one should ever user TFS, ever. While I was unfortunately forced to use it I experimented with git-tfs to see if it would ease my pain, and this is what I found.
Why git-tfs
It seems to be the main git-to-tfs-bridge right now. There’s another option, git-tf, but that one hasn’t been updated since 2013. git-tfs appears to be an active project.

The Good

  • Local version control: local commits and local branches. Proper branches (not TFS folder-branches) which are lightning-fast to switch between, and you can cherry-pick between.
  • Rebase temporary dev branches back onto master instead of clumsily re-applying old shelvesets.
  • If more than one person is using it, push and pull git branches between yourselves, and keep developing even when the central TFS server (inevitably) goes down.
  • Separate source control from Visual Studio: generally a good idea in my opinion, and particularly useful if VS is already running slowly.
  • Reliable version control: TFS get-latest is a bit buggy, but git-TFS seemd to work reliably. Perhaps it abstracts away for you the tedium of always telling TFS explicitly to get the latest version of all files, not just some.

The Bad

  • You can only checkout one directory at a time so you need separate checkouts for different root-level projects in the same repo. This is pretty minor though.
  • Visual Studio gets a bit confused and integration isn’t as good. Keep it happy by using msys git (git for windows) not cygwin git if you can.
  • Changing between TFS and git-tfs, or just using visual studio with a git-tfs checkout, leads to corrupt TFS workspaces.
  • Doing things differently from the rest of the team means you lose out on their TFS knowledge and support, for what it’s worth.
  • You won’t be able to add projects to the solution properly.
  • Visual Studio will constantly try to remove the tfs element from the .sln file, which will break TFS integration for everyone else if you commit it.
  • If you need to keep local changes, e.g. for local environment config, then it’s a pain to stash the changes all the time (you need a clean checkout to rebase).
  • It’s just really slow – mainly because my team’s TFS server was slow; but git-tfs was even slower.


For me, unfortunately the advantages don’t outweigh the disadvantages, and I probably wouldn’t use it again. it’s a bit of a pain to set it up and to use different tools to the rest of the team. On my next TFS project (and I’ll do everything in my power to make sure there won’t be one) I’ll just embrace the shelveset workflow instead.

What I might try is just to git init a local repo in my TFS checkout and get local branching that way, adding the .git folder etc to the local ignore list, although it might lead to some manual effort keeping branches in sync with the remote.

Setting up

If you do decide to use it, this is what I did to set it up:

  1. Install git, and configure it:
$ git config --global core.autocrlf true # see
$ git config --global core.filemode false
  1. Install git-tfs:
  2. Clone the repo:
$ git tfs clone http://tfs:8080/tfs/DefaultCollection $/some_project -c XXX

Where XXX is a recent changeset – you’ll only have history available from this changeset, but the further back you go the longer the clone will take.

  1. Open in Visual Studio!

Don’t bother to un-map your workspace: the Visual Studio TFS integration will go away when you open your new “git” project. And it will be easier to go back to pure TFS if you want to.

Everyday Use

Always rebase when pulling:
$ git tfs pull --rebase

To map local commits to checkins one to one, use rcheckin instead of checkin or checkintool.

$ git tfs rcheckin --no-merge

Be careful though, this makes a number of commits in a row, and because TFS is so sloooow the can be nearly a minute apart and trigger more than one consecutive CI build. If the build time is slow this might hold other people up from committing, so keep an eye on it: you can always cancel the first build(s) if this happens. You might just want to squash up the commits to save time committing!

If your project requires certain custom notes fields to be supplied, use the -n (--notes) argument to supply it from the command line:

$ git tfs rcheckin --no-merge -n 'JiraNumber' 'AA-123'


What I did on my volunteering day – Zoe

29 August 2016, by

For my volunteering day I worked at Barnardo’s in Marylebone, organised through Benefacto. Barnardo’s is a major UK children’s charity and does a great job with lots of different aspects of supporting children: fostering and adoption, work skills, domestic child abuse, nurseries and supporting families.

Working in the shop was awesome on many levels. They have great donations because it’s such a wealthy area, so it’s quite fun seeing what stock they have. It was also really awesome for reminding me what a great job I have at Softwire… When I arrived I was told that my first job was hoovering and dusting (I HATE hoovering) and – even worse – I was told that mobile phones were not allowed on the shop floor and Eduardo the manager made me check my phone in a locker!

Another awesome thing about the job was the clientele. The first customer I served came in in a shell suit top and paint spattered jeans. He tried on a few shirts and bought one “oh and wait” he said, and returned with 8 pairs of socks.


Introducing Git Confirm

24 August 2016, by

Get easy confidence on exactly what you’re committing.

Git Confirm is a git hook, which asks you to confirm when you commit a change that includes additions from a (configurable) list of risky matches. Think ‘TODO’, ‘FIXME’, ‘@Ignore’, ‘describe.skip/it.skip’ and ‘describe.only/it.only’. You can drop Git Confirm in, and effortlessly stop yourself ever committing anything like this by accident.

TODO is the easiest example. It’s really useful to sprinkle TODO comments in your code as you work, to mark things that will need fixing in future, and jot down notes as you work. It’s really terrible to end up with a codebase riddled with them though. You need to actively deal with them in the short term, either fixing them immediately as you wrap up your larger piece of work, or moving them into a proper task tracking system somewhere.

Unfortunately, it’s easy to fail to do that; to add todos as you go, skim your code later and assume you’ve to-done them, and end up slowly rotting your codebase over time.

With Git Confirm, you put ‘TODO’ on the watchlist, and any time you commit code that adds TODO, you’ll see it (in context) so you can confirm you definitely want to commit it. Demo time!

This could be you right now.

Simple, effective and ready to go. There’s other options for this, but personally they’re either too simplistic (rejecting commits to any matching files outright) or more complex and overpowered than I want by default (automatically opening TODO issues on Github, or fully synchronized tracking of TODOs with external issue trackers). All of these have their place, but there’s a big gap in the middle for a simple tool that stays out of your way and catches you if you slip up, without being too opinionated.

There’s also a lot of edge cases that these often don’t cover: changing other parts of files that do already contain TODOs, removing lines with TODOs in, or including context with failures so you can see find the issue. Deep interactions with Git like this create surprisingly fiddly edge cases, but Git Confirm has your back all the way.

In addition, as far as I can tell there’s no tools for the general case at all, where I want to match arbitrary patterns. I’d really like to never accidentally commit an ignored test, and never ever ever ever accidentally ignore all my tests but one. With Git-Confirm, that never happens.

Want to try it? In the root of your repo, run:

curl >   .git/hooks/pre-commit
chmod +x .git/hooks/pre-commit

Done! By default it’ll just match ‘TODO’, but you can override that and add any regular expressions you like with:

git config --add hooks.confirm.match "pattern-to-match"

Happy committing!

This post originally appeared on Tim Perry’s personal blog. Want to learn more? Check out Git Confirm on Github to see the full details, and reply below or tweet Tim at @pimterry with your questions.

What I did on my volunteering day – Mike

22 August 2016, by

I volunteered at the “Share Garden” in Springfield Hospital, Tooting (organised via Benefacto).
It’s a community garden in the grounds of a psychiatric Hospital that primarily exists to provide horticultural therapy and training to patients of the hospital, who have a variety of mental and/or physical disabilities.

The day was relatively simple: it was a garden in the summer, there was lots to be done, and most of it was weeding.

Over the course of the day, I:

  • Weeded a square bed of lavender & roses bushes (general small weeds, thistles, and fair amounts of bindweed which absolutely loves wrapping itself around lavender)
  • Was commandeered by one of the students/patients to help him clear out a large patch of nettles that ran beside the path to the loo block (they’d started getting big enough that they were occasionally stinging people who wanted the loo). First shearing the nettles down to 3-4 inches, then pulling the remaining stems out and finally digging out whatever amount of the roots we could get at.
  • Re-arranged one of the (6!) compost heaps so that new waste didn’t need to be lifted over the barricade of clippings that had be put on the front of it.
  • Weeded another square bed of lavender & roses bushes.
  • Watered the covered “green house” section of the garden where they grew plants and seedlings to sell. (Maybe 10 m x 20 m of pots).
  • Started Weeding a 3rd square bed of lavender & roses bushes.

I had a great time (I managed to hit a continuously sunny day. Score!), and it was really clear that the students got a LOT out of being in the garden, but that some tasks were more viable for them than others. Fine detail weeding being one of the harder tasks for them to achieve.

Visualising your project’s progress with Burnup Charts

17 August 2016, by

One of the most important aspects of Project Management is being able to answer the question, “How is the project going?” Is it on schedule? Is it on budget? A very popular tool for keeping track is a Burnup Chart.

Here’s a simple example:
A simple example of a burnup chart

Every burnup chart has the same basic anatomy:

  • The x-axis denotes time. Usually it’s measured in sprints, but it can be weeks or even days depending on how much granularity you need for reporting (and how frequently you can measure your progress).
  • The y-axis is a metric of progress. In this example, the metric is story points completed which is a common choice but can be somewhat subjective. Other possibilities include number of stories completed, or amount of budget used. You can choose any metric you like as long as it’s a good representation of progress.
  • The scope line (shown in black, and labelled “Scope (points)” in this example). This represents everything that needs to get done. In this case, it’s the total story point estimate for the whole project. If you’re measuring story count, it’s the total number of stories. If you’re measuring budget, it’s the maximum budget for the project. In this example the scope line is nice and flat, but in some cases, scope can change over the course of a project, so the scope line will change accordingly. This is one reason why burnup charts might be preferable to burndown charts – it’s easier to represent changes in scope.
  • The burn line (shown in blue, and labelled “Story points” in this example). This is a cumulative plot of work done, according to our chosen metric. In a project that’s running to schedule, we expect the burn line to meet the scope line around (or ideally just before) the end of the project. The gradient of the burn line indicates velocity, or how fast we’re burning through work. Velocity can help project a rough end date for your project and is another useful indicator of how things are going. If your velocity is much lower than expected, there’s a good chance your project will be late. Also, if your velocity changes unexpectedly, it may indicate that something has happened that is worth investigating. Your burn line should be relatively smooth if things are going well.

Here are two projects with similar scopes and schedules but different velocities. Adding a trendline to the burn line makes it clear which is likely to be delivered early, and which is in danger of being late.
A burnup chart whose velocity indicates a likely early finishA burnup chart whose velocity indicates a likely late finish

Another way to visualise this is with a target line. Here’s a project that ran pretty much exactly on schedule.
A burnup chart of a project that progressed on target
It’s normal for the burn line to wobble above and below target (staying perfectly on target would be a bit spooky – and may be a sign that your team is gaming the system), so a small wobble usually isn’t cause for concern.

One way to be sure is to add multiple target lines – one for the worst case (shown in dashed red, labelled “Pessimistic”), one for the best case (shown in dashed green, labelled “Optimistic”) and one for the average case (shown in dashed grey, just labelled “Target”).
A burnup chart of a project that progressed on target, indicating the expected best, worst, and average cases.
Now we can see that once the project gained momentum, it stayed within our expectations, so we know that the wobbles in progress were definitely ok.

This other project, however, has been below the red line for all 8 sprints so far. Work is being completed, but the burnup shows that it’s not happening at the rate we would expect in order for the project to be delivered on time.
A burnup chart showing a project that appears to be at risk
It looks like things might be improving: the trendline shows that at our current velocity, we should just about finish before the worst case end date, but it’s a pretty narrow margin and it assumes nothing else will go wrong.

Because we can visualise the project’s progress so clearly, we have the opportunity to take action before it’s too late. This project’s PM was able to intervene and turn things around. In the end, it finished ahead of schedule!
A burnup chart of a project that was in trouble, but recovered after intervention, and ended up finishing early
It’s easy to see the point at which effective changes were made to the project because the gradient of the burn line (the velocity) changed sharply. Burnup charts are also a great way to check whether the changes you make as a PM are having the effect you want.

Another handy use for burnup charts is keeping track of Work in Progress (WiP). If you’re familiar with Lean or Kanban, you’ll know that too much Work in Progress slows your project down, so it’s useful to be able to visualise how much WiP you have. The way to do this on a burnup chart is to plot a second burn line for work that’s in development. Just as the usual burn line shows cumulative work completed (using your metric of choice), the “In dev” line shows cumulative work in development or further, using the same metric. The distance between the two lines is your Work in Progress at that moment in time.
A burnup chart indicating Work in Progress
In this example, we can see that we had a lot of WiP in Sprint 6 (20 points!) which might have been slowing us down a bit. In Sprint 7, we picked up fewer stories and pushed more of the in-progress stories through the pipeline, which helped get velocity back on track. Here’s that project’s burnup again with target lines added.
A burnup showing a project that was kept on track by controlling Work in Progress

One final tale of caution – Burnup charts are an excellent tool for visualising progress, but they’re only as good as the metrics you choose and your interpretation of them. Here are two burnup charts of the same project, one plotting story count and one plotting story points.
A burnup of a project that seems to indicate it is going wellA burnup of the same project that seems to indicate it is going badly
What’s going on here? Is the project running early or running late? Should you be worried?

What these charts are telling us is that, in Sprints 6 and 7 in particular, we got through a lot of stories but not a lot of story points. A look at the backlog shows that we completed a lot of smaller stories then, which gave us some quick wins. Does that mean we’re now ahead of schedule? Or are the remaining, larger stories going to bite us in the end, meaning we’re actually behind schedule?

Looking at the work remaining after Sprint 8, there are 3 small stories, 7 medium stories and 9 large ones. Large stories carry a lot of risk, so the project is starting to look precarious. At this point, it’s critical to remove any blockers and progress those large stories. In this case, the story points chart is probably a truer picture of what’s going on because it captures the risk associated with the size of the stories, and that’s where the trouble with this particular project lies. If you report the story count chart to your stakeholders, they may get their hopes up that the project will be early, and will actually be disappointed if it’s late. They also may not understand the urgency of unblocking the large stories if it looks like everything’s fine.

How did it end? The large stories were unblocked after Sprint 8, and things got better. Here are what those charts looked like at the end of the project.
The final burnup of story points for the confusing project
The story points chart shows an increase in velocity when the large stories were unblocked. Things stayed pretty much on target after that.
The final burnup of story count for the confusing project
The story count chart shows how the team got as much done as they could while they were blocked, but then ate through that buffer as they finished off the large stories. It shows that the rate of story completion was not sustainable, because of all the large stories still to be done.

Make sure that you choose the right metrics for your project so that the shape of your burnup chart is a true representation of its status. Then, use your burnup chart as a tool to help you identify when investigation and action are needed. Finally, use your burnup chart to verify the results.

What we did on our volunteering day – Andrew and Ying

15 August 2016, by

Ying and Andrew Bike FixingAndrew and I volunteered at The Bike Project for an afternoon.

They give bikes to refugees and asylum seekers who can’t afford public transport. Did you know asylum seekers only get £36 / week in benefits? They also teach female refugees to cycle.

We kind of expected to be fixing bikes and giving them to refugees, but what they needed was someone to clean and fix second hand bikes to sell, to earn some money to keep the rest of their operations going. A step further removed from the beneficiary, but equally crucial!


Tips for managing technical people – Talk to the Duck

10 August 2016, by

Galvanizing the geeksThe following is an excerpt from my new book, “Galvanizing the Geeks – Tips for Managing Technical People”. You can buy the full book on my website, here.

‘Rubber duck’ technique is one of the innovations that I have seen introduced by a project manager who was willing to try something new. He didn’t invent the practice, but no-one works in a vacuum; the best project managers build up their skillsets through others’ experiences as well as their own.


What I did on my volunteering day – Chris Harris

8 August 2016, by

On my volunteering day I went to Deptford Reach.

I was irrationally scared about doing this, simply because I had no idea what it would actually be like. Of course, it turned out to be fine. So I’m going to present an account of what happened, in the hope that it might make similar opportunities a bit less scary for anyone else with a similar fear of the unknown. I’ll then put some “lessons learned” at the end.

What happened

The timings were 8:30am – 2:30pm. The location was a day centre for homeless and vulnerable people, it serves hot breakfast and lunch, and gives out day-old Pret sandwiches for dinner; there’s also an IT room, an art room, and they have yoga and fun stuff like that throughout the week.

I got a very quick induction and was told I’d be in the kitchen. It’s a proper commercial kitchen and I got to wear whites and an apron and feel very professional. My fellow volunteer had been there for a month, and our boss was a trained chef from Zimbabwe called Renee. During breakfast time I chopped a load of mushrooms and was on toast duty for a brief while, during which I had my only interactions with the actual clients. They are charged a small fee for most breakfast items (e.g. 30p for a slice of bacon), but tea and toast is free, so lots of people were asking me for 4 slices of toast.

At about 11:30 it became clear there wouldn’t be any more kitchen work for me, so I made it known that I worked in IT and they asked if I wouldn’t mind working on their website. Apparently even though they get a lot of IT people volunteering, none of them want to do the website as they’d rather be in the kitchen or gardening or something. I actually found the mix of a morning in the kitchen and an afternoon on the computer quite nice. I spent 3 hours making some changes to a WordPress instance, including a bit of design (“add more colour”), a bit of bug fixing and a lot of adding new pages. See here for my handiwork!

I ended up leaving at about 3:15, later than my allotted hours but still a nice early finish. I’d been given some nice food, met some lovely people, had some new experiences and got to use my skills. Success.

Things I learned

I’m sure there are some more but here are the main things I learned:

  • Places like this exist. I’d never really been aware of them before, so I know a bit more about the world than I did yesterday.
  • I was reminded what it’s like to be completely new to something. I was glad to have an understanding boss, who delegated in a great way (started something off for me, watched me do it for a bit, and then let me get on with it). My goal was to not make a major blunder, so I spent a lot of time checking and confirming before doing anything irreversible.
  • My IT skills, although horribly out of date, are good enough to make a difference to a small charity like this.
  • My default tidiness standards are not good enough for a commercial kitchen…

Speed Coding 2016 – Q4 Solution

3 August 2016, by

This post explains the solutions to Question 4 of our speed coding 2016 competition. If you haven’t yet read the question, head back and have a go now.


Employee Volunteering

1 August 2016, by

This summer Softwire launched an exciting new Employee Volunteering programme with the help of a great social enterprise called Benefacto.

At the heart of the programme is our offer to every employee of two free days this year that they can spend volunteering instead of working. I’m pleased to say that within the first two months of this scheme, 19 people (around 10% of the company) have taken us up on this offer, and have done some amazing things!