Breaking Myths

I was chatting with an old mate of mine, Lev  Ozeryansky, with whom we graduated together computer science about 8 years ago (man, that was long time ago, but doesn’t feel like that). He’s a great developer, with lots of experience. Yesterday we have finally met and chatted a bit (guess about what). Two things I heard bothered me a lot.

1. You need more than 2 developers to do pair programming and being effective.

2. TDD is a waste of resources (where resources are developers, money, time, you name it) and only possible in big companies.

Lev was doing TDD, but he was the only person to do so. Why didn’t this work for the entire company? It was considered a waste. Worse that that, it was mandated as a waste by the management to the point where developers believed in it. What a waste… Immediately I thought just about the blog published lately – management has got to buy into this and adopt, and it’s a developer role not to give up on change promotion.

As to the first point, about pair programming, well… Personally I am a huge fan of pair programming for multiple reasons (final code quality, knowledge transfer, overall design, better testing in place, etc). I agree that it is impossible (and from the psychological point of view even not always desirable for certain individuals) to pair a 100% of time, but even 2 developers in a shop will do a huge difference by pairing.

Along with that I am no longer surprised that bigger companies are adopting both. Not just because “they have more money to waste”, but since they have already “wasted enough to realize that something was absolutely wrong”. If I would be today in a position of a start-up, yes, I would think twice before throwing these two aspects into the game. In case of a running shop – no thinking. Just do it, unless you want to vanish quickly among piles of in-maintainable legacy code in the suffer-land.