Software Product Lines (Last Edit: Feb 21 2004 11:58:57)
RecentChanges Edit Search GoodStyle

Florian Weber wrote:

''a lot of my projects are very very small ones. mostly in the range of between one and three weeks. well, now i wonder, what would you guys recommend concerning writing stories? how long should one story take?''

Every small project has a large project inside waiting to come out.

Strike that.

Every group of small projects have a large project inside, waiting to come out. ;-)

Each project you likely don't start by re-writing the low level functions, like 'split()', from scratch. You probably have grown some lite libraries around your favorite database, GUI, etc.

So, after satisfying Customer A, don't just push all their code aside. When you start your project for Customer B, each time you hit The Test Button, all the tests for Customer A still run and pass.

This technique gives you extraordinary freedom to refactor a common core of opportunity out of projects for A, B, C, etc.

Don't say "if Customer == A" in any of the source. Split out the configurations on things by naming features. Then put configuration lists into common files that everyone shares. (Don't switch from one customer to another by changing the configurations back and forth manually!)

Next, make sure you can add a new customer, D, by adding their name to a brand table, turning their configurations on or off there, and recompiling. D should now join the test suite that covered A thru C.

Grow a star topology, where the core code, with its configurations, is the star, and custom code for A thru D are the planets around the star. But any duplicated code in the planets is a candidate for refactoring into the core.

This technique is called "Software Product Lines", and the SEI recommends it to companies big enough to hire them for a lecture. But SPL doesn't itself only work for large scale situations.

Describing SPL in XP terms (such as "fold duplication") might reduce several posts to one Wiki page. ;-)

With Software Product Lines, a big company splits out a core group, and assigns each product line's source to a product line group co-located with an OnsiteCustomer?.

On a small project, that's all you. ;-)

So user stories in this context are requests to change The System. You have new freedom to mingle requests from many customers in your input stream. Your customers don't need to "wait until you finish another project". If they vote (with money) that their feature request is higher priority, you can add it to your input stream, and finish it sooner.

But one problem here is executives who allocate your time, per week, to individual customers, to pay your salary, and can't let you mix your behaviors together.