Software creation using Collaboration(I): Why?

Today I want to change my usual sports' talk in my blog. I know talking about sports every time can get boring for some of you, specially while drinking a cup of coffee in our break:)
Today I want to talk about the power of collaboration.

I always have thought that two brains think better than one, far more if the one is mine:)

Collaboration between colleagues it's a powerful weapon we often forget... We work with colleagues, we create a software that is huge, we put our own ingredient but the final recipe and dish is the result of the team.
We sometimes use "pair programming" to solve unknown tasks. I put quotes between pair programming since we actually don't know what that implies.
We're almost scared as the boss walks near our place, "will he think we are wasting our time? Will we be fired?" Furthermore if you work as a programmer in Spain...

I'm currently reading one amazing programming book: the mythical Code Complete by Steve McConnell. While following the chapters one by one, I found a lot of references to Chapter 21 - Collaborative Construction. 
I felt the need of digging into that chapter and surprisingly, it talks about the power of collaboration. 
I would like to write a phew highlights of it so that I get them tightened in my brain and others can learn from it.

Maybe this sounds familiar to some of you: 
A workmate walks into your desk and say: "Would mind helping me with this code? I'm stacked because I have done this... and that result on this error, and it can't be so because... Ouch wait a minute! I have the answer!! Thanks for your help mate"
You say: "Oook, I didn't did a thing..."

In one way or another, collaborative construction techniques are attempts to formalize this experience.

Let me say a phew words you can say when you big boss asks: why are those two programmers working together? :D

Defects detection

The main goal we have is to improve software quality.

We have testers at Unit4, we have system analysts,...  All of them trying to reduce defects in our ERP.

We use Test Driven Development (TDD) to create our software, we trust in our changes.

But as the book says, UnitTesting have an average defect-detection rate of 30%, Integration Tests increases it up to 35. In contrast, the effectiveness of Collaborative design and coding is 55-60%.

Time

Another benefit of collaboration is that it decreases development time. 

In the book we have dozens of figures that justify it. E.g. IBM found that each hour of code inspection with pairs prevented 100 hours of related work (testing and fixing bugs).

Surprisingly, collaborative practices have proven to being more efective at caching errors that testing, furthermore it detects find different kind of errors.

A colateral effect is that when people know their work will be reviewed, they do it better: scrutinize it, criticize it,...

Mentoring

We need feedback about our job, about some subjective aspects of programming: style, naming, design approaches,...

Collaboration between more experienced programmers and less experienced can encourage those newbies. Collaboration (review, pair programming,...) can create a venue between them, therefore the latest ones can quickly be brought up to the level of the best developers.

Commitment, collective ownership

All the code produced by Procurement in the last sprint is owned by the TEAM rather than individuals.

This mindset produces several key benefits:

-Multiple sets of eyes seeing the code, again, increases quality.

-The impact of someone leaving the team or getting sick is lessened because everybody know what is going on.

-Time to fix bug is shortened since everybody is familiar with the code, any programmer can be assigned to fix bugs.

In next chapters I will talk about a couple of Collaborative techniques that have proven its efficiency widely throughout years and years of ussage: Pair-Programming and Formal Inspections (aka Fagan Inspection).

Let's change our mind, stop thinking somebody sitting at someone's  desk is loosing his time!