I can't find all of the Better Software Magazine articles on the Sticky Minds web site, so I can't provide a permalink. But look for "A Story About User Stories and Test Driven Development". It's good stuff, weighing out the good and bad features of "by-the-book" TDD.

Dr. Dobb's Journal …

In Lenses That Distort Our Software , I noted that the relational model of data can distort our view of the underlying reality that software models. In that posting I was whining about how meaningful structure is sacrificed to force fit information into the rows and columns of the relational world …

I see organizations stymied by a few individuals that seem to subvert initiatives and prevent progress. Or they somehow evade being useful and spend all their time in hand-wringing and "yeah-but"-ing. I'm not sure how to exploit what they can do, while getting past the stalls and evasions.

Here's …

Back in the olden days (ca. 1981) Barry Boehm's Software Engineering Economics provided a detailed and definitive guide to estimating. It did one really important thing: it provided a conceptual model of software development that had a (relatively) focused set of degrees of freedom, an input driver and a couple …

When approaching reverse-engineering, we have to partition the big puddle of code into some useful pieces that we can manage intellectually, and will likely become parts of the resulting application. In some cases, this is either impossible or valueless. It may be that the application is so hopelessly bad that …

In order to talk about what goes in the database, we need to put the question into some kind of useful context. Weirdly, the question came to me in a context so twisted and bizarre that it's a little hard to sort out what -- precisely -- was going on. First, what …

A taxonomy of pipeline alternatives is a big, hairy deal, involving lots of alternatives. While your basic API methods are relatively few in number, each language and platform introduces new options. Without some focus, it's challenging to produce a big, fluffy description of all potential alternatives.

However, the interesting thing …

When I was a kid, reverse engineering a legacy application was a challenge. Tools were non-existent, and even a civilized practice like unit testing didn't really exist. Now that we have test driven development, I think we can apply this to reverse engineering the billions of lines of legacy software …

This is not a Python to the rescue story. This is a true, deeply horrible situation. I was rescued by a reframing technique I'll call Extraction.

First, the function had nested if's without enough else's -- the kind of thing that handles two of the four possible conditions.

if( a ) {
    if …

Why Python, indeed?

"It's clear that you find it easier and quicker to use Python, and that's fine. It's often quickest for people to use the tools that they know best."

As they say on Fark.com, "This".

However, the Python advantage doesn't stem from knowing Python better than Java …