For about three years I published two articles a week, every week, on the old Creative Chaos blog. In 2008 we moved Creative Chaos to be the blog for Software Test Professional, and I continued two per week, ending up with some podcast and one article – for two more years. (You can go to http://www.softwaretestpro.com/Blog/Page/9 or so and click older posts, again and again and again and again …)
Eventually my blogging and writing moved on to other venues, and this became more of a corporate blog. But I still publish a great deal.
Recent Articles, Interviews, And A Video
I continue to blog at Uncharted Waters, a general IT blog with test/delivery feel, as I have since 2011. In 2014 I invited Justin Rohrman and later Michael Larsen joined me as bloggers – right now we are pushing eight articles a month. In December I wrote How To Build a Future, about the best startup book I read all year (It’s a great stocking stuff for techies), and Heads I Win, Tails You Lose about a sad, but common human interaction – and what to do about it.
I’m still writing for CIO.com, which is producing more and more slideshow like content. This month I published a slideshow on the Fundamentals of Scrum. Most of my recent writing for CIO has been a little on the technical side; you’ll find articles on GIT, Ruby, and Jenkins in my CIO.com author feed.
Of course, I continue to edit Stickyminds.com; we publish a new article each week! My editing role includes blogging for techwell, where I write an piece each month. In December I wrote about how to analyze the value of the test tool approach the team is currently using … or trying to.
And I do an occasional interview. In October the folks at A1Q1 interviewed me about agile-testing. It is important to note that my answers pre-supposed an agile context; I assumed the implied premises in the question. If your team is not pursuing an agile approach, the answers might not be hepful. Likewise, a friend chastised me, in the piece, for talking about 100% quality. First, check the safety language I threw around my words; I wrote:
…there may be a few domains where it may be possible to get close to 100%. For the most part, for what I do, I can be most valuable in the domains that offer risk – because riskier domains are ones where risk management is called for.
If someone wants to take that and claim Matt Heusser believes in 100% coverage … well … misinterpreters gonna misinterpret.
The more important thing in the piece, I think, is that the author never defined what they were talking about 100% of. We mix in between the idea of zero defects and 100% coverage in the piece. The implied connection there is that to get to 100% quality (Zero defects?) you need both an oracle (to know what the software should do) and you need to test all the things. I was mostly interested in talking about the impossibility of all the things in that paragraph.
For a more nuanced discussion of 100% coverage, my might enjoy the talk I gave on the subject at Nordic Testing Days with Pete Walen in June:
It’s time to talk about Save Our Scrum.
Save Our Scrum
When I talk to people about software today, more often than not, those pursuing Scrum express disappointment, challenges, and problems. After a bit of discussion last year at the Agile Conference, Markus Gaertner and I decided to take some personal initiative to create an education project we call Save Our Scrum. In October I ran the first meetups on the subject in Grand Rapids and Lansing, Michigan. In January I’ll be presenting Save Our Scrum at CodeMash in Ohio, then QAOrTheHighWay in February; over the next few weeks I expect to at least one more announcement.
If you’ve noticed the writing is a bit thin for Matt standards, you’re right – Markus and I have been spending our spare time on a writing project called Save Our Scrum.
And yes, you’d better believe that there’s more to come.
