I have just submitted a talk about Introducing Decombination to XP Days Germany 2015.

If you’re thinking of taking part in XP Germany, send me your review.

If you’re interested in having this talk at your event, send me an email.

Here is the abstract of the talk:

Introducing Decombination

“Reuse” and the many design principles based on the concept are generally recognised in software engineering. And yet the promise of being able to build software with reusable building blocks, like a game of lego, has, over the years, been a disappointment. The reality developers are struggling against each and every day is that developing new features is a journey of exploration that cannot be controlled nor predicted. New lines of application code will always need to be written. The lack of reusable modules (modules which can be used in predictable, similar contexts) and recombinable modules (modules which can be used in unpredictable, diverse and different contexts) makes the software system’s codebase continue to grow. As such, developing new functionality becomes more complex and requires more effort and higher costs.

Developing even the smallest functionality involves making thousands of teeny tiny decisions. What do you do when the cursor blinks and you know you have to do something, but you’re not sure what? You can see software as a “thing” to observe and onto which to impose your decisions. The principles of traditional and agile design are based on inspecting and assessing certain external properties of the software system (e.g. coupling, cohesion, responsibility), thus reinforcing the idea of software being a “thing”. Or you can see software development as a relational exchange with the software system. Like between humans, having a useful exchange with your software system means knowing when to open up and look for relationship with the other and when to exert control on it to, for example, protect and favour exchange.

My new approach, Recombining Relational Production (RRP), shows that, contrary to what you might think, your relational capacity can be applied even when the “other” is a product you are developing, software for instance. We need to learn to recognise this ability, favour it, develop it. When you recognise the “other” in the software you’re developing and know how to make a conscious decision between two types of response – exerting control or looking for relationship – at each teeny tiny design decision, you can choose to bring about decombination. In this talk I will present a real example of RRP. I will show you how to “decombine” software by consciously applying control and relationship decision after decision. I will explain how to obtain software modules that can be used to create value in different and unpredictable contexts. Lastly, I will show you how using decombination and more generally RRP lets you deliver more features with less effort, in a more controllable and sustainable way.