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?

  • 5
    Is this really about explaining branching? If I'm reading this right, you should focus on explaining to them why you just spent 9 month without releasing anything. Nov 30 '10 at 15:50
  • Yes, it's about branching. The reason we've spent 9 months not releasing anything is that 6 months ago they told us they weren't sure that they wanted what they'd ordered (and paid for) and to stop while they worked out what they did want. As a result the trunk is unreleasable. If we branch from before that then we need to explain to them why they can't just pick up from where we left off six months ago. Nov 30 '10 at 16:01
  • Do you have some kind of dependency graph that shows how changes to feature (1) might influence feature (3) (11) (15) (27) and (119)? Can you illustrate that recursively, showing multiple changes to several features to show the exponential growth of uncertainty? What you are indeed managing here is uncertainty, if I read your question correctly. I think I have a good answer, but I need to be sure that I understand what you need.
    – Tim Post
    Nov 30 '10 at 16:10

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.

  • 2
    +1 for document based metaphor - they're project managers, they get documents. Dec 1 '10 at 9:40

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.

  • 3
    +1 because clients really don't care about the implementation and mangement details.
    – Gary Rowe
    Nov 30 '10 at 16:58

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.


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.

  • And when they say "but why does it cost more" which tends to happen when you give them a five figure estimate for (in their eyes) nothing? Nov 30 '10 at 15:50
  • 6
    I slightly disagree with this, everything we do to de-mystify our profession and work more closely with clients, the better. Nov 30 '10 at 15:51
  • 1
    I almost dinged this with a down vote. You do need to explain to the client, in terms that they can understand, why (not just how) their decisions might influence their bill.
    – Tim Post
    Nov 30 '10 at 16:06
  • -1. Would you rather take five minutes and have a smarter client? I sure would.
    – Josh K
    Nov 30 '10 at 17:07
  • 2
    I still think this is just vanity. This stuff is important to you, so you think it needs to be important to them. In reality it isn't any more than what temperature they cooked your lunch. If you ask for a well done burger, you would probably be satisfied with that takes longer without a lecture on convection ovens.
    – JohnFx
    Nov 30 '10 at 17:44

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.

  • The problem is a release with sanity testing takes maybe a day (which they know). This is likely to be 10 - 15 days. Dec 1 '10 at 9:39

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.

  • 6
    8-| You lost me at 'A'...
    – Gary Rowe
    Nov 30 '10 at 17:00
  • 1
    Yeah, word problems involving trains ALWAYS make things easier to understand. =)
    – JohnFx
    Nov 30 '10 at 17:44
  • @Gary Rowe, @JohnFx - it's a ridiculous answer to an even more ridiculous request to explain this to a client.
    – JeffO
    Jan 30 '11 at 0:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.