On August 3 Brian Marick tweeted 
Agile is a melding of a craft ethic and super-responsiveness to change. How would some explicit Slow Programming http://bit.ly/ieB4n fit in?
Then, on August 4, Ron Jeffries responded: 
@marick I wonder if TDD might be “Slow Programming”
I also responded quickly – but wanted to take the time now fill in some more details to my response.
This response is based upon my personal understanding of the ‘Slow Movement’ which may or may not be entirely in line with the actual goals/aspirations of the ‘Slow Movement’. Also at the time of this writing I find that there is already a Wikipedia entry for ‘Slow Programming’ but I disagree with the description of that as linked from the Wikipedia article.
What Slow Programming means (to me)
To me the “Slow *” movement is about being deliberate, mind-full and sustainable. Thus slow programming would involve programming in a way that is done with thought, and is sustainable over a long term. It would not involve quick “hacking” of code to meet arbitrary deadlines in a way that cannot be kept up for weeks/months/years.
The ‘Agile’ process(es)/practices to me lead us to this “Slow Programming”. Specifically the practices of TDD & Sustainable Pace.
We all know that going ‘fast’ does not mean necessarily going ‘well’. As Kent Beck says: “If it doesn’t need to work; I can get it done much faster”.
TDD leads me to program very mind-fully. Always thinking of the next thing the piece of code must do or not do. Before TDD I would just write the code I thought was needed for the requirement. But with TDD I write the requirement as a test and then write the code to make the test pass. That leads me to be constantly thinking about the requirement; constantly questioning the requirement. I am always asking the “Customer” what they meant, do they mean “this” or “that”; and what if “something-else” happens? My code with TDD is not done more quickly than before; but in the end I know exactly what it does; and it does not more. In the past my code might do things I had not intended (for better or for worse).
Sustainable Pace keeps me from overextending myself for long periods of time. Of course when a important deadline looms I push; but through long experience I know that pushing is a double edged sword: the stress keeps me focused; but the speed reduces quality.
Programming needs to do be done very conscientiously and at a pace that can be kept up in the long term. One must always be 1) doing only that which is needed, 2) questioning the customer what is needed to ensure #1 and 3) keeping up a good pace because burning out your resources are, in my opinion, unprofessional, since it leads to worse code.
In Reaction to the existing definition of Slow Programming
When I began this blog post I was not aware of an existing ‘definition’ of Slow Programming. That definition appears to be made in opposition to Extreme Programming and I think that is not the right angle to take. Given that we know that requirements will always change (unless the “Customer” begins a “Slow Business Requirement” Movement) the concept of having “careful design process by a fairly small number of people who know the business well” is not going to work. We must design only as much as possible to handle the given requirements, meet them; then allow the “Customer” to play with them to discover their next requirements. Perhaps this is the important part of the “Slow Programming” concept: giving the “Customer” the time to discover their own requirements – not rushing them to attempt to get all their requirements before we start programming.