I work on a team where we practice pair programming and TDD every day. Pairing alone isn’t the key to our success, another important element is Test Driven Development or TDD.
Traditional Engineering Teams
Most engineering teams today, make changes to their code and often these changes break a whole bunch of ‘stuff’. If you’re lucky, you find out which functionality was regressed prior to pushing code to production. But more often than not, we’re not that lucky. The breaking change isn’t caught because automation does not exist. So the code gets into the hands of the customer long after it’s been written and results in an escalation. This leads to frustration and increased customer dissatisfaction. But it doesn’t just lead to frustration and inefficiencies for our customers, it results in Increased TCO for everybody involved. The cost of working this way is ENORMOUS.
