Re: Practice: Single Code Base

Kent Beck wrote:

>There is only one code stream. You can develop in a temporary branch, but
>never let it live longer than a few hours.
>  Multiple code streams are an enormous source of waste in software
>development. I fix a defect in the currently deployed software. Then I have
>to retrofit the fix to all the other deployed versions and the active
>development branch. Then you find that my fix broke something you were
>working on and you interrupt me to fix my fix. And on and on.
>  There are legitimate reasons for having multiple versions of the source
>code active at one time. Sometimes, though, all that is at work is simple
>expedience, a micro-optimization taken without a view to the
>macro-consequences. If you have multiple code bases, put a plan in place for
>reducing them gradually. You can improve the build system to create several
>products from a single code base. You can move the variation into
>configuration files. Whatever you have to do, improve your process until you
>no longer need them.
>  One of my clients had seven different code bases for seven different
>customers and it was costing them more than they could afford. Development
>was taking far longer than it used to. Programmers were creating far more
>defects than before. Programming just wasn't as fun as it had been
>initially. When I pointed out the costs of the multiple code bases and the
>impossibility of scaling such a practice, the client responded that they
>simply couldn't afford the work of reuniting the code. I couldn't convince
>the client to even try reducing from seven to six versions or adding the
>next customer as a variation of one of the existing versions.
>  Don't make more versions of your source code. Rather than add more code
>bases, fix the underlying design problem that is preventing you from running
>from a single code base. If you have a legitimate reason for having multiple
>versions, look at those reasons as assumptions to be challenged rather than
>absolutes. It might take a while to unravel deep assumptions, but that
>unraveling may open the door to the next round of improvement.
>
>
>  
>

On our product, we have to maintain 'at least' one version prior to the 
latest version. Shortly before we had to start our second version, I  
looked at most/all of the various techniques (Brad's book is excellent 
for helping here) and quickly came to the conclusion you are referring 
to above - one code base is a lot easier and safer than a multitude of 
them. It took some selling to management, but I pushed for and won 
branching to be done during build and runtime.

We are now onto our sixth version, using the same original code base - 
we can still build each of the six versions today from the same 
mainline, just by setting the desired version before starting the 
release build.

There is a trade off, the 'branch'ing still exists, albeit in code 
rather than SCM, and so its just as possible to introduce bugs into one 
version but not another.  However, this is largely mitigated by because 
we can build and test each of them at the same time from a single source 
code base, rather than having to use the SCM tool's branching support.