The Pragmatic Craftsman
:: Simplicity from complexity : by Stanley Kubasek ::
The Pragmatic Craftsman
:: Simplicity from complexity : by Stanley Kubasek ::
I am a TDD fan. I’ve been one for a long time.
But I’m not a TDD practitioner. I don’t follow the TDD methodology of writing the test first, implementation second.
Not yet.
Uncle Bob convinced me to try. Again.
Time to become a TDD developer! Time to step up my code quality.
I have said it many times, Robert Martin, Uncle Bob, is someone who has had a big influence on my career (you can find other references on this site). I usually buy all his books. His latest one, The Clean Coder, is not only a joy to read, it’s filled with great advice. It’s like reading The Pragmatic Programmers again. Who doesn’t want that?
Let’s get to the point, though. Why would I ever want to follow TDD? Isn’t that counterproductive, and… silly!
Do I want to write higher quality code? Faster? Less buggy? And get more fun out of it?
Of course!
But I’ve tried before. And reverted to old ways of doing it.
This time, I want to infect myself with it.
How? By trying harder. By making this “my way” of doing things. And by actually writing the tests first.
It’s going to take more effort than that! 
Today I got an opportunity to do just that. And I am surprised how I was able to kill a few bugs. Bugs that would have “bugged” me later.
But why write the tests first?
So I develop good coverage. So I design better. So I get instant feedback. Those are 3 very good reasons. Not only that, but by first thinking about the tests, I will cover more corner cases; I will make my code testable.
Do I really need more convincing?
Not really. Benefits are clear. It’s just a matter of “doing” it.
Lastly, to give some direction and insight on how to proceed, here are the three laws of TDD as per Bob.
The Three Laws of TDD
1) You are not allowed to write any production code until you have first written a failing unit test.
2) You are not allowed to write more of a unit test than is sufficient to fail—and not compiling is failing.
3) You are not allowed to write more production code that is sufficient to pass the currently failing unit test.
Martin, Robert C. (2011). The Clean Coder
Ready to join the TDD camp?
I’ve been quiet on this blog lately. I’ve been quiet in 2010 as a whole! Only 5 blog posts during the year. That does not make it too active, I must say. As new year’s resolutions go, I plan to change that.
Starting from this week, I set a goal to write a blog post per week. But wait, I have 4 blogs (click Home to see them). So that’s roughly 1 post a month. That should at least double the postings in 2011.
In 2010 I changed jobs. I am now involved with pure Java development, which I love. But it’s also a nice change from using Java sparingly, mostly coding Velocity templates — not too say you cannot get creative, but it’s a “contained” circle. I am now “free” and that should lead to more interesting ideas and topics.
What am I up to lately? Deepening my Java threading knowledge, and Java in general. (I just got an idea for a separate post on this subject. )
What are my plans for 2011? I plan to deepen my Java skills. Java 7 is around the corner (finally!). I’d like to improve my Spring knowledge — if you don’t use it you lose it. Guava — a google collections library. I’d like to learn that as well. I mean, I’d like to find uses for it. I also want to learn bash scripting. Never learned it, but coming across it very often. Time to dig deeper. If time allows, I also want to learn Python. Seems like it should be in my toolbox. I can perhaps combine it with Google App Engine application. Sounds cool.
2011 should be a busy year.
How am I doing it? How do I find the time? Early to bed, early to rise… said Benjamin Franklin. And that’s exactly how. I wake up at 5:15am everyday. And I try to collect at least 2 pomodoros (25 minute sessions, with 5 a minute break; check out ChromoDoro in Chrome) reading, practicing — doing dev-improvement stuff. That’s how. It works for me.
