[breck]

How do you guys maintain an ever growing code base?

It seems to me that the practices you have--TDD with full code coverage and regression tests, pair programming everything, many client libraries--would lead to a massive amount of code that needs to be maintained.

In my experience I've found that TDD often leads to a huge amount of code that needs to be rewritten if you do a major change to your codebase. If you have a new pattern you want to implement it may require rewriting dozens or more tests. Also, when I'm working alone I constantly go back and clean up functions and what not to make them shorter and clearer. I've found I do that less while pairing because you want to keep moving forward.

My opinion is probably just biased by the fact that I've done relatively little pair programming and TDD. I'm sure the more you do the better you get.

But I'm curious if you could take some about the size of your code base and how these practices effect that?

[brown9-2]

How do you safely make those major changes to the code base without all those tests?

[mkramlich]

By using one's brain. Understanding the code. Knowing what effects what. And by running it, particularly the changed flows. The disadvantages to tests/TDD is (a) it assumes the developer is stupid, and (b) even if he is not, he has the additional burden of creating and updating the tests as he goes along, slowing him down. Yes there can be downsides to not having tests/TDD. But the upside can vastly outweigh the downside, in many situations. YMMV.

[Retric]

One of my favorite stores from an old and vary experienced coder. Someone had been fired after a spending around a year on a project that never quite worked, it was hack upon hack and had failed several passes though QA with major issues etc. So he spent 2 weeks cleaning the thing up redoing about 1/2 of it in the process and sent it to QA to see if anything else was missing.

Anyway, a week later he get's a call that some fairly basic functionality was broken in production which he fixed. Afterward he asked some people in QA how it ended up in production so quickly and how they had missed such a basic issue and their response was "Ops, we stooped testing your code a few years ago this is the first time it bit us."

TDD always struck me as an attempt to answer to the question what do I do if I don't know if this actually works and nobody is going to QA this crap. But, if you actually consider what happened TDD was unlikely to help because the coder was simply unaware that existing code was broken and needed to do something else.

[mnutt]

Sure, but that just means that QA knew something about how the application worked that the developer didn't. In an ideal world the developer would be familiar enough with the product to write good tests. In the reality, TDD is good for checking the really repetitive edge cases, and QA is good for catching business logic failures that the devs aren't aware of.

[breck]

Good question. Separate your Dev from QA, and make QA code the automated tests. That way, you still get the eventual safety of test coverage but developers are never slowed by the need to write or rewrite tests.

[brown9-2]

And what is the benefit of that separation? Seems like that sort of thing makes it easy to blame the other guy "I didn't know to test that / I'm not the tester, not my job".

The "cost" of high-coverage automated tests is overblown, IMO. The few extra minutes spent writing test code is worth the extra safety and confidence. However I believe striving for 100% coverage on every method/branch is overkill.

It doesn't have to be either you do TDD religiously or you have no tests.

[breck]

I agree. The middle ground is better than writing no tests.

I do think it's more than a few minutes though. The problem is when you do a big rewrite you've now sometimes got a lot of failing tests. Do you go back and delete these tests and write new ones? Or refactor the test code? It's just a big distraction because sometimes you're "holding the program" in your head, as PG would say, and to worry about tests might cause you to lose your focus on the more important code.