Thursday, November 16, 2006

stuff I left out of the Fort Lewis presentation

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 setting, and ought to be critically important everywhere else.

Just because software is free and unencumbered, does not give users of that software license to claim it as their own work. Whenever you use software created by other people, please please please make a concerted effort to provide the correct citations for that work, even if the license does not require it. You have far more to gain by honest reference to others' work than you do by plagiarism.

The other bit that I never mentioned (sorry Jonathan) was the ideas in Fred Brooks No Silver Bullet. We talked about all sorts of great stuff, open source, agile development, non-hierarchical management strategies, scripting languages. The point that I should have made explicitly but did not, is that all this stuff is cool, but a) it's not magic and b) in another ten years, it will all be quaint if not hilarious.

Tuesday, November 14, 2006

linked from the soap4r wiki

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".

Thursday, November 09, 2006

another look at soapui: load test

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 disappointed not to be able to say something useful immediately.

But I had been working on this blog, and I re-read my post about soapui, and remembered that it had a load-test feature. Just like the functional-test interface, the load-test was really nicely designed, and I could create a 30-thread, 60-second load test for the function in question in just a few minutes, and get some very nice graphical output. My colleague was pleased, and I hope the customer was too.

I still believe that soapui is not scriptable enough to be my primary regression-test tool, but once again, for exploring-- this time for exploring performance-- you just can't beat it. Very very nicely done.


Monday, November 06, 2006

lecture Nov. 15: "How to be a Software Expert"

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 some pretty heavy articles and given some big time presentations since then.

So I'm not really an expert except maybe at some niche software-test tool stuff, but I do get to talk to some real experts now and then, and I've seen a lot more of the software world since the last time I gave this lecture.

However, because of the bit of expertise that I do have, I am very concerned that the world these students think they're about to enter does not really exist. I'd like to be able to give them pointers about how to jump in and survive in a world where IT paradigms are upset over and over and over again every few years or even months, where the future is always uncertain and the only way to keep up is to keep learning, keep teaching, keep asking questions, and stay flexible. Funny that as I got my material together, Kathy Sierra published this nice bit:
"Why does engineering/math/science education in the US suck?" which points out among other things that "
Where we used to prepare students for a "job for life", now we must prepare students to be jobless."

More than that, though, I would like to point them toward tools and attitudes that will allow them to live and work in Durango, which may or may not be a "faux town" today, but certainly will be soon without more highly-skilled, high-paying jobs. Like in IT.

Here's the blurb, the outline will follow:

How to be a Software Expert

Are you so talented that companies will seek you out to make you a job offer? Or is your next job being outsourced already?

Routine information technology jobs of coding, support, and implementation are leaving the US for places like India and China. But at the same time, tech companies report that they face a desperate shortage of talented employees. ("The Battle for Brainpower", The Economist, Oct 5 2006).

You can be the talent; or you can be outsourced.

In this presentation, Chris McMahon explains how you can use a wealth of free resources to become an expert in information technology, and a valuable (outsource-resistant) IT asset. From local interest groups to world-wide open source software projects, Chris explains and demonstrates the tools and resources that talented experts must know in order to succeed in a global market for IT employment.

Chris is an expert in software testing and agile software development. He has published many articles about software testing, presented tutorials at software testing conferences, runs a weblog dedicated to software testing, and he contributes to a number of open-source projects. He is currently telecommuting from Durango for a software company based near San Francisco.

So here's what I'm going to talk about, feel free to leave a comment or drop me an email:

Copyright and licenses. You have copyright to everything you produce. Learn how to use it, and how to give it away.

Overview of GPL and BSD licenses, along with real-life stories about why they're useful. Possible contrast to i.e. Windows.

Money. A few people get paid because they sell a great idea, like a singer/songwriter. Think Paul McCartney. Most people get paid because they sell a service, like a studio musician or member of Paul McCartney's touring band. So we know how Paul McCartney gets paid. His drummer got the gig because he's an expert drummer.

If you expect to make a living by performing perfectly clear assignments under reasonable deadlines from your immediate supervisor, your job is being outsourced right now. Start thinking now about how to use your talent and expertise to create value and reduce cost wherever and however you work.
Agile teams. Point to Thoughtblogs
Distributed teams. Mention Magpie
Startups. Mention Skywerx

Keep a blog
Write articles
Get a portfolio. Mention Entropy Media. (Check out their About page: "...Every update is important to us. Every client is important to us. Every request is at the top of our list, not waiting to be filled." Go Entropy!)
Contribute to mail lists and technical communities like user groups or SIGs.
Present at conferences if you can
Contribute to open-source projects

Contributing questions. Mention perlmonks, soap4r, Watir
Contributing documentation. Mention the FreeBSD paper noted above and it's origins at PNSQC
Contributing code is often the least important thing you can do.

LAMP is NOT "the acronym given to the mainstream open source movement"! It's an application development stack, and it doesn't even stand for what it used to stand for. (What were you people thinking?)
Ebay, Amazon, Google, Yahoo: who uses Windows?
Google Tech Talks

Ask and answer questions in public to increase your skill.
Work in public because it gives others confidence in your abilities.
Share your work, and others will share theirs with you.
Work with others because doing it all yourself is impossible.
Quote Jerry Weinberg: "Give your best work away for free."

Wednesday, November 01, 2006

mind maps for testing and other things

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 BETTER THAN A SPREADSHEET.

My former colleague Dragos Manolescu uses mind maps when designing systems. He's produced some spectacular work. One I remember had to be printed on a plotter, and was about 6 feet high and 3 feet wide-- but quite readable. It was SO MUCH BETTER THAN A DESIGN DOCUMENT.

Although mind-mapping works just fine with colored pencils and paper, I really recommend FreeMind, it's a very east to use, very popular, open-source mind-mapping tool that will save the diagrams in an number of formats, including jpeg.