Is BDD/TDD and pair programming a waste of time?

As usual the answer is it depends. If you insist on looking at short term effects of TDD for example there is no doubt in my mind it is a waste of time. Why deliver great software in six months when you can deliver decent software in four months? Personally I believe there is too much software out there that started as "a little temporary solution we will only use a few times" and that later turns out to be used, tweaked, fixed and updated for years and years to follow. You never know what will happen except that you probably have to maintain the software you write for a longer period than you really want. And the best way to not spend time on old stuff you wrote ages ago is to make sure it works in the first place and that changes/updates can be made quickly (and preferably by someone else without asking you for help). So in the long run, TDD is definitely not a waste of time in my book. There are also some research on this if you like to crunch numbers.

So what about pair programming? As pointed out here, you do much more than just write code when you develop software. In certain situations such as spreading knowledge pair programming is a no-brainier. One experienced person showing someone else how things work at the same time as new features gets created is probably more cost effective than having somebody sit for days by them selfs trying to figure out how things work in the code. And two skilled developers probably solve any problem faster together than if they try alone. Since two people also look at the code all the time you will probably end up with a better design because it is the work of two rather than one. And you always have (at least) two people that understands each part of the code so if somebody gets seriously ill it is not catastrophic. But all this (except maybe teaching novices) is definitely a waste of time if you insist on looking at the short term consequences. But once again, software always survives longer than you think. And each thing you do in your development process must be measured against the total life cycle of the software. Not just until the next release (or on a day to day basis).

I think all agree that quality costs but it pays in the long run. And there is always a breaking point. Some things are just not worth the price of quality but before you can make that call you must know the real costs and the real benefits. As provided above there is some research on TDD and developers don't just write code so two developers pairing is not half as fast as two working independently. And if you really need numbers then you should try TDD and pair programming and actually measure the cost vs benefit rather than focusing on the short term cost in time. Remember, quality typically pays of in the long run. Both in terms of less bugs and happier staff that stays on the job.