The Wayback Machine - https://web.archive.org/web/20170628121941/http://www.advogato.org/article/653.html

Branch Constraint Theory: Limitations on Software Development

Posted 23 Apr 2003 at 00:04 UTC by apenwarr Share This

After a lot of consideration of release processes and the different kinds of mistakes we and others have made in releasing software, I finally arrived at a mathematical theory that can tell, at the highest level, how fast we can release software, how much testing we can do, how many simultaneous branches we need to have, how many people need to be dedicated to testing, and how to balance these variables to get the results we want. I call this my "Branch Constraint Theory" (BCT).

Like I said, this theory operates at the highest level - it applies to all software projects that use a standard "add features, code freeze, stabilize, release" cycle. It uses several variables that are different for each project, and which we can tweak for our own project. I call these "implementation details." But the fundamental rules, as it turns out, are always the same, and they reveal some surprising things about software development.

In this document, we proceed through the following steps:

  • derive the Branch Constraint Theory and its variables, drawing some conclusions about the universal laws of software development along the way;

  • show how these laws have been affecting us in our own development processes, even though we hadn't realized it before;

  • discuss which variables need to be adjusted in order to attain particular goals; and

  • suggest ways to change our software development processes in order to adjust these variables.

See constraints.pdf for the complete story.

huh?, posted 23 Apr 2003 at 06:29 UTC by walken » (Master)

I read the paper, but I dont get it - it seems to assume that people can add features and stabilize simultaneously (in different branches), while still doing both of these as fast as if they were only adding features or only doing stabilization work. Then from that it does a big calculation and concludes that working on multiple branches at once helps.

I'm sure I misread something...

Working on multiple things at once, posted 23 Apr 2003 at 22:29 UTC by apenwarr » (Master)

The mathematical model used in the article assumes a project with lots of developers, so individual effects (should I personally be adding features right now or fixing bugs) tend to cancel out.

For example, the Bug Find/Fix Rate depends on both the speed of finding bugs and the speed of fixing bugs, in no particular ratio (since in every project these two things will be done differently). Often, finding the bugs is much harder than fixing them - and often they're done by different people. So you might have beta testers constantly testing the software and identifying bugs, and then have developers that are "mostly" adding features drop in to fix them once they're found, which probably doesn't take long and thus doesn't much affect the result. This is what mostly happens at my company.

Alternatively, perhaps half your developers are working on version 1.1 and the other half are working on 1.2; when 1.1 is released, those developers could rotate over to work on the new 1.3 branch, while the 1.2 branch starts stabilizing. I've heard of some companies that work this way.

Another way of doing it is approximately what happens to the Linux kernel: some people only want to use stable versions, and some people only want to use unstable versions. So when one stable version (2.2) is dropped in favour of a new one (2.4), then the people working on the last unstable version (2.3) jump straight to the new one (2.5) and the stable users move from 2.2 to 2.4.

Debian, with different people usually working on stable, testing, and unstable, experiences a similar effect.

Anyway, don't get lost in the "implementation details" - the point is that somehow it does happen in branched projects, and the end results are some simple, mostly measurable numbers: the bug addition rate, the bug fix rate, etc. And from those numbers come some global restrictions on development rate.

Intresting, posted 7 May 2003 at 15:42 UTC by sarum » (Journeyer)

I don't know if anyone else read this, might have been descussed to death in the diaries already. I found this an intresting read and most of it seam to make sense. The only real criticisim I have is that you use too many abbrevation and this confuses the message.

So Interesting, posted 22 May 2003 at 20:02 UTC by Akira » (Master)

I found this article very interesting.

A configuration manager guy from my company read the document and is actually checking these information against the statistics we have on a 150 persons R&D software department.

I hope I will be able to share some information with you as soon as possible. Hmmm. Without disclosing any confidential information :-).

Should it be possible to adjust some variables to access our goals more quickly ?

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!

X
Share this page