I've come to rely on other people rather than RSS feeds to point out the really important stuff to me.

At last week's SPA conference, Paul Dyson and I ran a workshop on planning non-functional requirements in agile projects. Here is a personal account.

This is the fourth installment in the "Working Effectively With Characterization Tests" series. This time we look at how automation can help you create and/or improve your characterization tests using JUnit Factory, a free, web-based, experimental characterization test generator (and my pet research project).

In addition to being a rich-client development toolkit that targets the Flash virtual machine, an interesting aspect of Flex is that it relies on code-generation to reduce the amount of code a developer has to write by hand.

In this 3rd part of the series, we put our newly created characterization tests to work, and we see how even the simplest and most innocent code changes can cause unexpected and unwanted changes in the behavior of our code. Fortunately our characterization tests are there to protect us.

Netflix has been everyone's darling long enough that customer abuse has slowly been creeping into their business model. It's ironic that they were the ones that, through competition, forced Blockbuster to stop abusing customers.

What automated refactorings would you like to see?

In part 2 of the series we look under the hood of legacy code we inherited and experience a moment of panic when we see how cryptic the code is. Then present a simple strategy that does not require us to fully understand the code in order to write good characterization tests.

Since we have limited time each day to learn new languages, language features, and APIs, we must decide where to focus our learning efforts.

This is the first installment in a series of short articles I plan to write on characterization testing. Characterization testing is an important concept and an essential tool for software developers working with legacy code (i.e. most of us) and it deserves broader exposure and more attention.

Almost every program we write today will execute in a concurrent computing environment. But to what degree do developers really have to be aware that their programs run on concurrent hardware?

For those of you who are programming in C#, what would you say are the biggest sources of pain, or at least discomfort, when using C#.

My impressions of the Python Conference 2007 in Dallas, Texas, written up on the plane home while it was still fresh in my mind.

James Ward and I just finished an eSeminar, which was recorded as we gave it. The URL is available here, so you can listen to and view the recording.

Testing is tough for most programmers, but without some amount of developer testing delivering quality software is even tougher. We propose a new software specialization and position – Developer Testing Master – to help software organizations fill the horrifically expensive testing gap between development and QA.