Before I get to that, though, here's a thought. For anyone who is an experienced TDD (or variant thereof) practitioner, Joel and Jeff's comments are utterly telling of their complete and overwhelming lack of experience and understanding of the underlying concepts of TDD. So, I'll let people who have more patience than I do respond to them. My only statement is that they obviously have no clue what they are talking about, and their opinions are so stale and old that I think all responses should consist of telling them to google their concerns/questions; there are lots of answers already published on them. But, that's not why I'm writing this entry.Now, on to the thing that I've noticed in the blog posts and comments and tweets about this: "Getting it done" vs "Doing it right." I spoke about this in my last Road Thoughts, but I wanted to make a very simple statement about it (Ron Jeffries makes a much more encompassing statement on this topic, too).
If you find that you are faster doing it in a way that does not conform to what you consider "good" and "right," then you are suffering from a deficiency in your skills. Period. The techniques that you fall back on when the deadline looms are the only techniques that you can call your own; everything else is something you are still learning. How quickly they become 'your own' is a question of how much you practice. If you have a technique that you think is 'better' than how you do it when the deadline looms, you owe it to yourself to practice it.
Notice, nowhere do I mention exactly what techniques I mean. That is for you to decide. If you are interested, I will gladly tell you what the best techniques I've found are (hint: the blue circle in the picture).
Posts
I took your 2nd to last paragraph and I'm going to print it and stick it on the wall. I hate what I become when I fall back to what I know in the face of a deadline.
ReplyDeleteThanks for opening up my eyes!
Hi, Louis!
ReplyDeleteThanks for the kind words.
One effective way to overcome that is through focused, directed practice. Watch my road thoughts video for some more thoughts: http://programmingtour.blogspot.com/2009/02/road-thoughts-practice.html
It is important to take time to practice specific things, working until those techniques are what you fall back on. For most people (me included), the techniques only slowly become second nature. This is because we don't focus on repetition.
Good luck and keep me updated on your progress / thoughts / insights.
This is excellent advice Corey, and applies to so much more than just development. Mastery of any craft requires practice, anything less is just cheating yourself and your customer.
ReplyDeleteHi, Chris, thanks for the comment.
ReplyDeleteIt definitely applies to most any skill. The weird part about development is that we tend not to have a culture that focuses on practice; we spend too much time learning 'new' stuff and relying on time to provide the repetition needed to establish our techniques.
"If you find that you are faster doing it in a way that does not conform to what you consider "good" and "right," then you are suffering from a deficiency in your skills. Period."
ReplyDeleteThe only point I would make, is I would be more worried if they /do/ conform to what you consider "bad" and "wrong". If you find more efficiency in another method that's not what you consider "good" or "right" it might be time to review those techniques. If you then agree that the original techniques are "better" because of some other aspects (maintainability, readability, etc) then it's worthwhile to work on the speed aspect. One cannot be afraid to adapt to new techniques due to ideology :)
Absolutely.
ReplyDeleteMost of the time, I hear people say 'I want to do it right, but I'm under the gun.' That tells me immediately that they have an idea of how they should be doing it, but they don't have the necessary experience with those techniques to make those natural and fast.
One should always be on the lookout for improving their skillset with new techniques. If they find a new set of practices (for example, when I was introduced to TDD), and they are convinced that those will be a better way to develop, it is their responsibility to practice until those newer techniques are the norm.
Suppose their argument is based on more than just ignorance. What do their comments suggest in such a context?
ReplyDeleteIt might be instructive to think it through.
I'm not sure what you mean. Which argument?
ReplyDeleteLove the blue circle reference.
ReplyDeleteInteresting thoughts about the SO people's podcast. Coming from a tester's perspective, I find that no matter which set of principles are followed, humans (read developers) are not fully debugged, so they will never write code that will be "right" or "done on time" considering the vast powers and unexplored minds of the users.
ReplyDeleteA lot of times I have noticed that the best piece of code comes from either a large effort upfront to get something "right" or an individual's passion to get it "right".
No matter what you do, somebody is going to say: "Your software sucks".
Howz life, give me shout if you are in the Bay Area. Manan :)
This is a classic. If you don't use TDD or pair-programming when there is a crisis or a deadline, it is because you don't yet believe that they are the fastest way to deliver working software.
ReplyDelete