Here is the full interview - Q&A on Test Driven Development and Code Smells with James Grenning
The whole Q&A is good but here is my favorite question and answer from the interview.
InfoQ: In your opinion what are the causes why are people not doing technical practices like TDD or refactoring sufficiently or well enough?
Grenning: Even though the technical practice of TDD and Refactoring have been around visibly since 1999 (with the publication of Extreme Programming Explained), most people in software development have no idea what they are. I recall being a young engineer, having large demands on my time from my employer and family. There was not a lot of time to devote to learning what the best ideas and techniques are. There are many ideas out there on how to build software. Not all of them so helpful. So its hard to know where to put your energy. As a young engineer in a new field, I thought I knew everything too.With experience came the humbling realization that I did not know everything. There is a lot to know in this broad and deep field. We each learned how to program in a very unique way. For me, a professor showed some examples of C programming constructs and then gave us an assignment to write an operating system. Go figure it out! And we each did figure out how to program in our own unique way. It seems that no one was taught how to program. If you think you are already a master of your craft, what motivation if there to learn more?I give a survey to people that are about to attend my training. You can see the questions and answers here: Training preparations replies. You can see the techniques for writing and testing software are all over the map. Most report using the techniques we used at the university in the 70s, and in industry in the 80s and 90s: print statements, break pointing and single stepping the debugger. Congratulations, it is 2015 and you are using state of the art debugging techniques from the 1970s! How about trying 1999 state of the art defect prevention with TDD!?After seeing TDD, engineers tell me they do not have time to write tests. They do not have time to proactively prevent defects but they do have time to react to those defects. Engineers also tell me that their boss won’t let them write unit tests. It should be equivalent to me not not following my doctor's prescription because I’m in a hurry.The long feedback loops that most developers live with are part of the problem. Let’s say I provide an estimate of three months to my boss. After two and a half, I go and deliver the bad news that I need another month. This repeats. Finally a subset of the promised functionality is delivered after six months. It only looked like the engineer was really working when the deadlines were close. What does this do to the engineer’s credibility? Not much.Working in iterations, with slim vertical slices of functionality, delivered every couple weeks, does a lot for a programmers credibility and confidence. Having the test safety net catches unwanted changes in behavior. The programmer gets all that for free once they master TDD as it takes about the same amount of time to get the code working in the first place with TDD as it does the 1970s way, Debug Later Programming (see the physics of test driven development).
