Years ago there was a very popular television program called "Bonanza". It was about a father and his four sons living on a ranch in the Lake Tahoe, Nevada area in the 1860's. It ran on NBC from September 12, 1959 to January 16, 1973; in other words 14 years, and thus it was the second longest-running western (just after "Gunsmoke"). Everyone I knew watched it and knew all about the characters and plots.

But no one asked a very simple question: Why is this show called "Bonanza"?

I like tools. I'm old enough to remember what it was like to develop software with a simple text editor (VI, anyone? Emacs? How about See? I'll bet nobody remembers See.exe…) Then you'd compile it at the command line, manually run the linker, etc… and I appreciate how much our tools have improved over time. I love intellisense, source trees, version control, context highlighting, the wonderful way resharper allows you to fix problems en-situ, and all that.

But I also know that the more powerful your tools are, the more you can become dependent on them and, worse, the easier it is to misuse them.

I recently had to install a driver for a network printer in my home. This is, I would say, a pretty commonplace thing to do in modern life.

I don't want to suggest that what happened was limited to a particular vendor, so we'll leave the company name out… however, it is one of the most prominent and successful printer companies in the world. Not some little podunk knock-off, in other words.

I put the CD that accompanied the printer into my drive and ran the SetUp program. Given that this is a device intended for home use, one would assume (as I did) that I would simply answer a few questions that the rest would be handled for me by the installer.

I'd installed this driver before, on other computers in my house. I knew it was large (much larger than I would think it would need to be) and that the installation took upwards of 20 minutes to complete, and that the "progress bar" would often just seem to be making no actual progress sometimes, but so long as the task manager said it was "running", I'd just have to be patient. So, I left it alone.

I came back a few hours later, and it was frozen at 24%. Task manger reported that it was still running (no "not responding" message or anything like that), so I left it. Two hours later, still nothing, so I finally cancelled the process and tried to determine the cause.

Recently at the Rails conference, Bob Martin served up a very provocative talk: "What killed Smalltalk could also kill Ruby." There has been a fair amount of controversy about this particular presentation, most notably from the Smalltalk community who consider themselves to be not-at-all-dead. They point out, for instance, that Smalltalk was not free "back in the day" and Ruby/Rails is, and that this makes more of a difference than many of the factors Bob was referring to.

For my part, I don't care all that much whether one language or another is in vogue as much as I care how the technology is being used and specifically how our profession is or is not maturing as a result. Bob said that we were not a profession in the past but are now. I tend to agree with him. He also equated the notion of a profession with the concept of disciplines which I also totally agree with (this should not be too terribly surprising to anyone familiar with the book I wrote recently - Emergent Design: The Evolutionary Nature of Professional Software Development - and if you note the particular engineering practices we choose to teach at Net Objectives).

So I'm with him on this, but I think there were a couple of things missing in his equation.

Last year I was diagnosed with a "nodule" on the right side of my thyroid (this is the word they use when you have a tumor and they don't want to freak you out). My doctor told me that the nature of the thing (soft, large) meant that it was unlikely to be cancerous, but that we might want to remove it anyway because it might turn cancerous later.

I asked "would I have to stay overnight in the hospital, or could this be done on an outpatient basis?"

He nodded and said "well, it's superficial, so…"

I interrupted. "Ah, good, so it's no big deal."

He looked puzzled. "Um, no. What?"

"You said it was superficial, so that means it's no big deal, it's trivial."

"No," he said, "it is not trivial, it is superficial."

With the holidays coming on, many of us are heading up to the attic to retrieve the boxes of decorations that have been waiting all year to be called into service again. In my family we put up and decorate a Christmas tree each year, but I suspect Hanukah and Kwanza, etc… have their festive ornaments too, and probably electric lights are involved.

One thing I'll do this year, as I do every year, is to lay out the strings of lights on my coffee table and plug them all in, to see if any of them fails to illuminate.

 Transition Testing - The Cornerstone of Database Agility (audio of the webinar)

 Database Agility

Databases are central to almost any software development project of any size. Developers have been gaining big improvements as they adopt Agile approaches: higher quality, more satisfaction, delivering more value to customers. It seems time for database developers to begin to experience the same gains!

But database development is special. It is not like just copying new bits into the environment. Databases need to retain their identity and the data that are in them. They have history and investment and must survive. Transitioning change is much harder and requires more care.

Is it possible to use iterative, Agile approaches with databases?

Yes it is. This podcast describes the landscape for doing so. Early adopters of this approach have learned the key principles involved and tools for testing and transition management are now available. Training is also available to equip teams with the new skills and ways of thinking that are required in order to be successful.

 read more »

OK, that was an intentionally provoking title. I believe in TDD, but I don't believe it's really Test-Driven Development. It's something else. I remember when people first started calling it TDD I used to say TDD stood for Test-Driven Design. I'd say this because your tests helped you define how you designed your code. But this assumes we even know what I mean by Test-Driven Development. What kind of testing first am I even talking about?  read more »

When I first talk to a team as their agile coachf, I often discover that they've read some books or attended conferences, and they've come away from these brief experiences with lingering concerns over certain "agile catch-phrases." Of course, the skepticism is healthy, and the misconceptions are natural. This is all part of a team's transition to true agility.