Very good rant which explains nicely why rewriting some software from scratch is almost never the right answer.

Second time I bump into this book being mentioned somewhere. This good summary really makes me want to read it. At least it gives a clear overview of complexity and how it's tied to other softer topics. I especially like the distinction between tactical and strategic, it's one I do often. I think I'm particularly willing to read the chapters about comments and TDD... from the summary it seems it's where I'm the most at odd with the ideas in there.

I've been banging the testing drum for so long I'd have a hard time to not violently agree with that article. I have a couple of beefs with it though, like the sacrificing encapsulation point but other than that...

Interestingly, I'm going through this book right now and indeed I have to agree with most of this article. It didn't age well, it's become a mix of nice advises, things which are kind of obvious nowadays and points which are clearly obsolete. I find that "The Clean Coder" (different topic I know) aged way better. I think I'll give a shot to the proposed alternative book to see...

Like everything, Pair programming also has a dark side. It's obviously more potent if you do it too much.

Interesting simple exploration. This seems to confirm that there's a lot of hype all around. Whatever the language, even if it is hot today it probably won't look as fun tomorrow when you'll have to maintain millions of lines of it.

Plenty of good advices for code reviews. Fairly comprehensive since it covers both ends of the review.

Good reminder of why idempotence is a very important property.