Chris McMahon's Blog

Even before I ever heard of Edward Tufte , I had always disliked scripted presentations. My approach to speaking in public is very much like my approach to performing music used to be, back when I made my living that way: know your material thoroughly, and be prepared to interact with your audience as much as possible. It's a strangely rare approach among those who speak about software, but one or two people get it. Martin Fowler points out one danger of this kind of presentation, being quoted, but what I find is that there are always one or two points that I really, really planned to make, but the conversation with the audience didn't go that way. Luckily, here in the 21st century , we have blogs, so we can go back and talk about the bits we missed the first time around. I discussed the very basic aspects of copyright and license and how they relate to open-source and proprietary software. I left out a discussion of plagiarism, which is critically important in an academic...

One of the points I'm making to the students in my lecture tomorrow is that the most important things to contribute to open source projects are questions and answers. Documentation is also really really important to healthy open source projects. To my mind, code is the last thing most open source projects need. Good timing that yesterday someone added to the main soap4r wiki under " Howtos " a link to my blog entry back in March dealing with " SOAP + Basic Authentication in Ruby ". The link is called "Basic SOAP Authentication".

In our SOAP API, we have a function that I believe is intended to take care of small jobs, special cases, cleanup areas, things like that. Using this function bypasses a lot of the niftier features of our application. I have some functional tests for it, it works just fine. Not long ago one of our customer support people asked me what kind of performance we could expect running almost a million transactions with this function in at least 30 threads. I pointed out that that was not at all what the function was designed to do. He made the excellent point that that was what the customer wanted to do , and we should be able to provide some information for them. Well, crap. I am simply not set up to run that kind of a test. Neither Ruby nor Windows is very good at handling threads, and I don't have a *nix box I can appropriate immediately. (I'm working on that as we speak.) I did suggest a test that the customer could run on a test server with their own code, but I was dis...

The CS department at Fort Lewis College in Durango has a tradition of featuring a speaker from the community for the last lecture before the Thanksgiving break. I did the lecture two years ago on "The History of Software Testing", and I had a blast. I was asked to do it again this year after starting the Four Corners Open Source mail list . (I hope to have a number of students (and even professors) join after the lecture.) I have a few things on my mind this time around. For one thing, the job that I moved to Durango to take, got outsourced to Canada. Or possibly Denver. Or maybe Israel. I left before they figured out the details. But it's definitely gone. For another thing, I spent a year working for Thoughtworks . TW itself is not gigantic (although they are spread-out) but I worked on some enormous agile projects with some really smart people from all over the world. The work was amazing, but the travel was brutal. For another thing, I've published s...

Better Software magazine feature article for November is about using mind maps for test cases. I learned about mind maps at Thoughtworks, where they had been in use for test case management (and lots of other things) long before I arrived. The key advantage of mind maps, as Robert Sabourin points out in the article, is that " ...misunderstandings and ambiguities are exposed and resolved in real time as you build the mind map". That sounds too good to be true, but it really does work like that. They are also readable, easy to construct, portable, and attractive. Here are two other ways I used mind maps that were very, very effective: Accounting and coverage: The project involved a re-write of an existing system. All of the (very complex) features of the existing system had to be accounted for in the new system, under the (very complex) new architecture. I used a mind map to relate existing features on the left side to new features on the right side. It was SO MUCH BETT...