Incredible Summary of Where Software Testing Could Improve

I ran across an article today about "What is the biggest weakness in software testing today?" Noah Sussman put forth the most succinct and clear articulation on the real cost of software testing I've ever seen. Seems like I've been stumbling along for years trying to make the point he does in a mere 212 words.

Noah Sussman, Technical Lead, Etsy:A surprising number of organizations seem to dramatically underestimate the costs of software testing.
Testability is a feature and tests are a second feature. Having tests depends on the testability of an application. Thus, “testing” entails the implementation and maintenance of two separate but dependent application features. It makes sense then that testing should be difficult and expensive. Yet many enterprise testing efforts do not seem to take into account the fact that testing an application incurs the cost of adding two new, non-trivial features to that application.
There also seems to be a widespread misconception that testing somehow makes application development easier. In fact the opposite is true.
If I may mangle Kernighan: testing is much more difficult than writing the code in the first place. To implement testability and then write tests, one needs first to understand the architecture of the application under test. But testing also requires doing hard things — like input partitioning and path reduction — that are beyond the scope of the application. The reality is that to get good tests, you’re going to have to ask some of your best people to work on the problem (instead of having them work on user-facing application features). Yet many organizations seem not yet to have recognized this.

Awesome. Thank you Noah. 

Education Today and Tomorrow

This is an amazing model for education. I heard it on KALW Cross Currents today. I'm so inspired by it. It's the kind of teaching I'd like to do if I were a teacher. It's the kind of school that I wish I had gone to.

The sequence below was seen in the comments on io9, and I thought it was somewhat brilliant:

 Brandon Creek @DonRivers

 

 onathanatos @Brandon Creek

 

 Brandon Creek @onathanatos

Is this one of those "Try to Spot the Difference"
games. I love those!

 onathanatos @Brandon Creek

Did...did we just become friends...? 

From the Ironic Juxtaposition Department

Flipping through the feed for Gawker, I see this from two hours ago:

Watch a 12-year-old put your startup to shame

and I see this from six hours ago:

Why did this 22-year-old entrepreneur commit suicide?

The profundity of the comments regarding the pressures of the technology business were matched only by the depth of snarkiness of the comments about the 12-year-old.

Reading Revolution

Presented with an upcoming vacation, and presented with the ever falling price of kindles, I'm in that uncomfortable zone where an original Kindle for $79 is totally in my price range (anything less than three digits is really attractive to me for some reason).
However, you can get what is essentially a tablet with the new Kindle Fire, for only $200. The thing I worry about is that when will that $200 be down to $99 or less. Probably soon.

I know that it's kind of a high-class problem having to decide between what gadget you should get for some ridiculously low price. I'll probably just get some paper books for this vacation and wait for the free Kindle that will get bundled with the New York Times some time in the near future.

Messing around with MySql

Odd moment today. I was fooling around with mysql date functions and ran the following:

mysql> select now()+0 from dual;

+-----------------------+

| now()+0               |

+-----------------------+

| 20110901111111.000000 |

+-----------------------+

1 row in set (0.00 sec)

It looked funny at first glance, but then I realized that I'd run the query at exactly 11:11:11 on 2011-09-01

No, this is not really that big of a deal. Just tickled my coincidence antennae.

Debt Crisis? Which Kind?

I was sniffing around the dusty corners of my LinkedIn profile, and recalled a group that I'd started three years ago when I was at Netflix: Software Quality People Who Run With Scissors.

Seems like I was looking in on the group about once a year, since there were some folks who had asked to join and it had been a year since the last batch of folks was all added at once.

Anyway, I dusted it off and made it an open group. To try and seed the discussion, I posted the following reaction I had to an idea I heard at a recent Meetup:

Agile has the idea of technical debt. An elaboration heard recently resonated with me. There are three kinds: design debt, quality debt and test debt.

Design debt is the more commonly thought of type of technical debt. You're compromising your current work in some way that will affect the future flexibility or maintainability of the system.

Quality debt is just another way to think about bugs in the system. I suppose you could also map them as "unintentional design debt". They are work you can either do now or defer until later, but that deferral has a cost in either maintainability, customer experience or business process disruption.

Test debt was the one that was most interesting to me. This is measured by the total time needed to regress the product after every iteration. This is the most insidious of the three types of debt. If you're developing software in an agile fashion, but you're not building automated tests to support the effort, this debt can grow without bound and it grows very quickly. It becomes either a crushing workload or an exercise in triage as to which parts of the regression suite are most important to run.

You can't ever have a project without some kind of debt (well, you could, but you'd either never ship anything useful or you'd never iterate enough to make it significantly better). However, being aware of how much debt you're carrying and thinking about the cost to your team's productivity is an important exercise.