In doing Sudoku puzzles, most of the time the next solution is staring you in the face. But you can't see it for all the other numbers in the way.
I got stumped on a puzzle Saturday, one that I'd stared at for about ten minutes without success. I have a ten-minute rule, so it was time for a new tack. (Others might call this ADD, but I follow Weinberg's Bolden Rule: "If you can't fix it, feature it.") I turned the book around to let my son look at it, but continued to look at the upside down numbers. Thirty seconds later, the very obvious solution almost started blinking at me. Duh.
Often, all we need is a different perspective on the problem. Many of us have experienced code enlightenment when having someone read over our shoulder. The usual explanation is that we're now trying to perceive how others are reading our code. Another thought: Sometimes I suspect that a very brief mental break is all that's needed.
But maybe it's just that we're shifting in our chair and catching the code at an odd angle. :-) Next time I'm stumped on code, perhaps I'll invert my display. Or change my font.
My dog kept wandering around the neighborhood, so I recently put up a fence around my back yard. Now I'm experiencing some regret: after all that expense and effort, the dog no longer gets out of the yard! Was it all a waste of time?!!?
(I think Ward Cunningham puts it much more nicely, but hey, I'm not Ward and will never be. Ward says, "How about FIND BUGS PROMPTLY?")
A trend I've noticed in the software development community is that there are a large number of developers who resist the new wave. Many of those who spent their formative development years doing procedural development went kicking and screaming into the OO age; some suggested that it was an inappropriate tool for many problems. Many C++ developers looked at Java as a toy, not useful for any real work. And I've met enough Java developers who thought that Java was the last word in programming languages.
Certainly we should question newfangled tools and techniques, and insist on putting them through their paces. OO is not the best tool for every problem, Java did suck big time when it first came out, and yet there are now some significant advantages to continue doing business with it. Challenges ultimately help the tools & techniques improve.
Experimentation and innovation is at the heart of the software industry, not active resistance. But it's far easier to sit in a corner and make as many possible excuses for not doing something. I know, because I've done so myself. There are plenty of jobs out there using old technologies, and places where people are happy with the status quo.
So, TDD. Some of us strongly believe in it, only because we've seen benefits firsthand--not just from toy Stack examples, but from working on systems that range from tens of thousands, to hundreds of thousands, and millions of lines of code. Ahh, but the stack example is all the people sitting in the corner see, because that's all they want to believe is behind TDD.
I agree with the vocal dissenters that TDD should not always be used, but not for the lame list of excuses they often come up with. Primarily, the reason is that the typical American software team just isn't that good. TDD is a reasonably tough discipline to get a handle on, and most developers are still struggling with OO, language, and tool basics.
What's interesting is that TDD would ultimately help these people the most--some of its best potential is its use as a learning tool. The vocal dissenters, on the other hand, are usually reasonably sharp developers who already have a good notion of design. Thus they can't quite understand why a technique that promotes more decoupled and cohesive designs is important--"duh, we already get it." Particularly, for example, if they don't happen to work with lots of typically underachieving coders.
Is TDD overhyped? Not a chance. There are still mountains worth of learning that TDD will promote in the minds of the majority of the developers out there. For those who don't want to do TDD, don't do it.
Can TDD be dangerous, and lead to disasters? Yes. This is true for any tool in the wrong hands. That also includes insisting on emphasizing test-after--I've seen that lead to plenty of failures and wasted time. TDD, like OO or any other tool/technique, is not for everyone or every project. But in the right hands, I've seen TDD work wonders on software projects.
Who else has this quandary?
I'm long, long weary of Java and C++ (which I thought I had been weary of over well over a dozen years ago, but here I am again struggling with it). Where next? Sure, I've been looking at Ruby for over five years now, and Rails a bit as well, but I've not had an opportunity to put it to any real use in a production environment (except for an odd pairing session here and there).
Recently I've also looked at D, Erlang, and Scala. "Looked at" means that I've downloaded it, gotten it running, run through at least a tutorial or two, maybe read the book, and then moved on to experimentation, perhaps starting to re-implement pieces of systems.
Seems like the most interesting stuff happening is going on in Ruby--it's a rapidly maturing environment. There are things going on around the other three languages I mentioned, but it doesn't to be nearly as much. Maybe when they've reached "critical mass," there will be more going on around them.
In any case, there are scads of new languages and tools vying for attention. It seems like there are more than ever, making for an exciting time. It also means that my stack of what I don't know keeps piling up. I think I need to pick one and invest some real, significant effort into it.
So, the decision: ride on the bandwagon, or blaze a trail? What are your reasons for putting your money where it currently is? What else should I be looking at that I'm not?
February 2004 March 2004 May 2004 September 2004 October 2004 January 2005 February 2005 September 2005 October 2005 November 2005 December 2005 January 2006 February 2006 March 2006 June 2006 August 2006 January 2007 February 2007 March 2007 April 2007 September 2007 October 2007 November 2007 December 2007 January 2008 February 2008 March 2008