What's the best way to explain branching (of source code) to a client?

Question

The situation is that a client requested a number of changes about 9 months ago which they then put on hold with them half done. They've now requested more changes without having made up their mind to proceed with the first set of changes. The two sets of changes will require alterations to the same code modules.

I've been tasked with explaining why them not making a decision about the first set of changes (either finish them or bin them) may incur additional costs (essentially because the changes would need to be made to a branch then if they proceed with the first set of changes we'd have to merge them to the trunk - which will be messy - and retest them).

The question I have is this:

How best to explain branching of code to a non-technical client?

Answer 1

Explain it like writing two research papers. You might want to go with several different thoughts. In order to do this you create a copy and continue work on the "branches" simultaneously. This issue comes up when you have work done on various different papers and you need to "merge" them into a deliverable.

This explanation has always worked for me.

Answer 2

It probably not that important to explain branching. What is important is that you explain the impact of their non-decision.

In this case the impact is if they decide they want the first set of changes down the road it will increase the cost then if you implement the change now. One nice way they will get the message is if you do an estimate for both.

If they don't understand why the estimates are different you can explain as you already have. Testing will have to be done twice and incompatibilities will need to be resolved, etc.

You can also use a building metaphors. Personally I don't like them but it wouldn't be that hard to do. One example that springs to mind replacing a bathtub and the plumbing together is cheaper than replacing the bathtub and plumbing separately, since you only have to rip out the tub once and re-caulk once and so on.

Answer 3

You are building a truck. You think you want to use it for towing, so you want a bigger engine and brakes. Brakes are cheaper so you put those in first. No wait....You might not need to tow. Pause engine choice.

You now want better gas mileage so it needs to be lighter you swap out some components so it's lighter, but if you can't decide on the heavy engine/towing or not. The big brakes might now cause it to break traction and skid out of control. If we take out the big brakes the truck might not stop.

Either situation poses a problem. To finish end tasks, dependent tasks should be complete or double/triple work is generated.

Moving forward at all creates double work. Double work costs money or time. More money == over budget / more time == outside of time-line.

If you can make a logical problem physical more people understand it...the money relation never hurts.

IMO, you get to try and explain cost impact once. If they don't get it, you point out that new deliverables require contract renegotiation. Are you nearing a payment milestone? That could be it too, they want to force either you eating the feature, or contract renegotiation failure so they can move to another development team with the progress they have and not pay for it.

Answer 4

Don't bother. It isn't your job to educate them on your job.

Just say that not having a decision on the first set of features will complicate the project management which might have repercussions in terms of time and expense. That's all that is relevant to them.

Answer 5

I wouldn't even try. Just tell them if they want to do both sets of changes now it will cost less than if you do a release now for their recent changes and then a later release that brings in the old-set of changes that are on hold. Why? Because a release itself costs money.

Answer 6

You have an 'A' train with several cars carrying thousands of boxes. After 9 months you decided to create another train on siding called 'A-b' filled with a similar load to train 'A', but some boxes and train cars have been added and some removed.

The train 'A' keeps running down the track and no one has decided if they want the 'A+b' train. A detour is being considered. Train 'A' is going to have to unload some boxes and load some others and the 'A' train would be renamed 'A+c'.

The railroad must ask the customer to make some decisions on what shipment they want.

• Forget about 'A+b', unload all the cars and eat the loading costs.
• Have the 'A+b' train catch up to and replace the 'A' train before the detour and create train 'A+b+c' train.
• Let the 'A' train make the detour becoming the 'A+c' train and then have the 'A+b' train catchup and then reconfigure train 'A+c' and become '(A+c)(A+b)'

(A+c)(A+b) will cost more and take longer due to all the loading, unloading, and figuring out how to fit the new order configuration on the train.