Tejas Software Consulting Newsletter

October/November 2004, vol. 4, #5

"I'm a consultant too. I tried a 12-step program and it didn't take."
This is one of many "Karlisms" from Karl Wiegers that I picked up at the Better Software conference, and it sets the stage well for the feature article (though I'm quick to point out that he's not the anonymous figure that I refer to in the article). I also have a big helping of feedback for you this time, so enjoy!

I'm proud to have merited the attention of your eyeballs for a few minutes. As always I must point you to http://tejasconsulting.com/newsletter/, where you can browse past issues and make sure you're on the list to receive future newsletters via email. If you know someone else who might enjoy the newsletter, please forward it to them, but keep it all in one piece when you do.

-Danny R. Faught, Software Alchemist
faught@tejasconsulting.com -- http://tejasconsulting.com/ -- +1-817-294-3998

Contents

Tejas Newswire

I have the following events on my schedule over the next few months -
My latest StickyMinds.com column is "Being Resourceful When Your Hands are Tied," posted August 30. My co-author on this one is Alan Richardson, marking the first time StickyMinds has had to squeeze two author's portraits onto their home page.

The slides from my talk at the 2004 Better Software Conference are now posted: "Open Source Development Tools: Coping with Fear, Uncertainty, and Doubt".

I gave a talk at the DFW Mercury Users Group on September 14. The slides are now posted: "Keywords are the Key to Good Automation".

The latest Open Testware Reviews feature is a review of the screen capture tool MWSnap, only the second tool to get a production rating. I also recently posted a lineup of web load testing tools and a note on Alan Richardson's test tool that runs within an Excel spreadsheet..

Feature Article
The Consultant as Human

At a recent conference I re-introduced myself to a well-known and successful consultant. I had recommended his services a few years back, which netted him a new client. His response to me at the conference wasn't rude, but it was terse, even cold. I didn't seem to merit more than a few moments of his time. I didn't have any particular agenda except to shake his hand, so I can't say that he neglected any pressing need I had. But I wonder how many other people have had a similar encounter with a consultant. That wasn't the first time it had happened to me.

Since I'm a consultant myself, I fear that people may think that all consultants are similarly aloof. I give you permission to chastise me if I ever become aloof or pretentious. I especially need your help with this as I'm scheduled to give my first keynote speech at a conference this week, and I shouldn't let it go to my head. Also, if you send me email and I don't respond as quickly as you'd like, please don't assume that I think you're not worth my time. Send me a reminder that there's a personal message that deserves attention buried somewhere between the spam and mailing list drivel.

I remember a phone call from a prospective client earlier this year. It seemed to be a surreal experience for the caller, actually talking to the person whose picture is plastered all over StickyMinds, who has been published. It gives me pause to think that my marketing efforts are creating that kind of impression. Have I built myself up so much that people are nervous to pick up the phone?

Another thing that makes people nervous about contacting consultants is the perceived cost. The first thing to consider is that I don't mind answering occasional questions via email--no purchase order, no invoice, no charge. After all, if I can't show that I'm useful for quick questions, I have no chance of getting a more substantial engagement some day. If you'll accept that my answer might point you to a few resources that will help you flesh out an answer for yourself, then I'm happy to try to help. But some questions are so fascinating that they send me down a new path of discovery, or at least give me a better understanding of what's going on in the industry.

Regarding the more substantial projects, I don't have a standard rate. I wrote an article where I chastised tool vendors who don't post the cost of their tools on their web sites ("Let's Hear It for the Underdogs"). Unlike tool vendors, though, I don't have an off-the-shelf solution that I can mass-produce. No two projects are the same.

I set rates based on several factors, including the value the client is getting, my opportunity cost of doing the work, and the roller coaster economy, plus a bit of conjuring a number out of thin air. But I'll set a broad range for you. When I worked for a consulting firm, I was billed at US$195 per hour. My hourly rates are nowhere near that now (don't worry about my ego - I didn't see much of that $195 in my paycheck). Perhaps I'll work my way up to that level again, maybe in three years, or maybe thirty.

There was a slow period earlier this year when I decided to get creative about finding work. I bid a landscaping project to my church. The price I quoted was $100 worth of grocery store scrip. I underestimated the effort required, and the end result was that I was working for less than the U.S. minimum wage. I chalked it up as volunteer work, and I don't regret doing it. Not only did I learn a bit about landscaping, but it also must have affected my karma, because business picked up shortly afterward. So there's my range for hourly work--does that help?

What if I'm too expensive? I'd be glad to help you find a contractor who might ask for less. Or we can reduce the scope of my involvement, setting you up for more of a do-it-yourself approach. One of my specialties is having a multitude of resources on tap that I can recommend.

Oh, and about being published, at least in periodicals. I can easily dispel the mystery around being published by helping you to get published yourself. Yes, you. Really. No charge.

My goal in sharing all of this with you is to encourage you to approach consultants and other knowledgeable people. You'll risk encountering aloofness, but not everyone you approach will react this way. There's a good chance you'll get some free help, and your correspondent will get a new fan and perhaps some help putting food on the table at some point down the road.

Thanks a bunch to the participants on the SHAPE Forum who let me bend their ears on this topic, especially Sue Petersen, Dave Liebreich, and Jim Batterson, who reviewed a draft of the article.

Feedback

One of my subscribers is so eager to be helpful, he read the first line of my August/September newsletter, which read, "Can you Q&A this over the weekend, so we can launch on Monday?". Then he answered:

I'll go through this by Monday. By Q&A it, I assume you mean test all the links. That's what I'll do.

He didn't get to the second line, where I pointed out that this was just a malapropism that I was making fun of. I've learned that I need to identify my quotes more clearly in the email edition. My helpful reader was kind enough to let us make fun of his perpetuation of the twisted use of terminology. By the way, at the Better Software conference I heard yet another case of using "Q&A" to mean "QA".

Mark Wiley wrote:

I have a similar one. Years ago a company I worked for always froze the code on Friday, and we started testing on the weekend. One time they had to delay the release until Monday, and the developer insisted this was only a one day slip. I argued until he finally agreed that it was a 3 day slip.

Don't underestimate the difficulty of date math. It gave us fits on my last project.

Jerry Weinberg also commented on the issue of confusing "question and answer" with "quality assurance":

Oh, Danny, you're so naive. I have clients who think they're the same. You assure quality by having some overbearing manager ask some wimpy tester a few leading questions, to which the tester gives the "right" answer and now quality is assured. That's far more common than most other meanings of QA. :-) or :-(, I don't know which.

I told Jerry that I'm surprised he didn't beat me up for not pointing out the importance of asking good questions in the course of assuring quality (Q&A as a part of QA), and he said: "That was too obvious. I'm not a bully (hmmph)." Somehow, Jerry, I think that makes you a more human consultant. Jerry continued:

Enjoyed this issue a lot. I'm particularly interested in software you don't have to install. I've been of mixed mind about this approach, because in order to use such software, I have to trust it to a certain degree.  I have avoided using all sorts of apps that want to handle my financial data up on their servers. Not enough trust. Same for apple's .mac services. I suspect trust will be the killer issue for this type of software if they don't solve it. Or maybe I'm just paranoid.

Even with a bug tracking tool, we have to trust that the vendor has made a big investment in security so that our proprietary project information is kept private.

Andy Lake from Information Management Services, Inc. wrote:

I received my copy of your newsletter and I wanted to thank you personally for the kind words about Squish. It was very well written and it showed that you had thoroughly tested the features of many tracking systems.

One of the nice features of an ASP is that the customer never has to perform any system updates. You can always be assured that you are running the latest version of the software. One of the updates that we are currently undertaking is a revision of the search system that you described in your newsletter. We hope to have the updated version released sometime in the first quarter of next year.

As you point out, ASP’s are attractive to many businesses because they allow users from off-site locations to communicate effortlessly and quickly from any web browser at an affordable price.

Andy, thanks for the feedback. Andy also pointed out an error in my article. I stated that the data in Squish is not backed up by the vendor, but in fact they do take daily backups.

Becky Ellis revives the debate about certification:

I think the certification boog-a-boo is getting larger.  People ask me about it frequently and I'm a little ambivalent on the response, I'm afraid.

I have pursued a few certifications, initially just to get a tangible "in" to the world of testing.  It did that - did it quite well. It also provided me with a ready list of the basic theories and history and approaches I should know and books I should read. A self-study curriculum, sort of.  It did increase my interest in areas of testing I would not be able to become involved in at my place of work.  It also gave me a lot of respect for ASQ and its professionalism (despite its engineering bent). However, I'm finding since my place of employment does not support the time or cost of conferences, the only way I can reasonably renew a certification is by pursuing education (which in some cases is not really relevant) or by going for additional certifications that don't in themselves require renewal but do qualify as criteria to renew an existing cert (such as ASQ's CQIA). This becomes a little circular after a while.

Becky also asked about my opinion on new certifications that are appearing. There is an increasing customer demand for certifications. I'm not sure why, perhaps because people want to differentiate themselves in a difficult employment market any way they possibly can. Businesses are recognizing that demand and rising to meet it with certification offerings that they feel are superior to the competition's. The discussion about whether the certification will actually make someone a better tester is absent from this dynamic.

Fern Herring of "Dear Aunt Fern" fame sent this after reading the last issue:

For a person who doesn't have the faintest idea what you are talking about, I found it rather interesting. I am constantly amazed at the vocabulary that has been created by the people who inhabit the technical world of the computer. This includes: bug tracking tools, hosted tools, Squish, froglogic, bandwidth, Bugzilla, blog, etc. There probably is a dictionary for computer terms.
 
I'm curious to hear what readers' favorite technical dictionary is. I occasionally refer to the Wikipedia, which is an encyclopedia that's written by its readers. I just searched for the terms you mentioned and found most of them there, and I added the rest myself (except for "hosted tools" - look up "ASP" instead). If you're really feeling adventurous, look up "Wiki" to see how I was able to add to the Wikipedia.

And finally, John Hebley asked me to play referee:

Danny, I have a question for you, and in some ways I'm asking for you to arbitrate a heated discussion I am having with a co-worker. We are both working in the area of process improvement and are trying to take a relatively conservative company kicking and screaming into iterative development.

Our model (which is very close to the RUP model) shows a small amount of testing in the Inception phase. My co-worker maintains that since there is no "deliverable" in this phase, then there is no testing. He is taking the word "deliverable" to literally mean the solution to the problem, or the application itself. I, on the other hand regard any artifact that is produced as part of the project as a deliverable, and believe that all deliverables should be tested. I also extend the concept of testing to include the validation of a written artifact such as a scope document or requirements document.

So, give me your $0.10 worth and say what you think.

I'm not familiar with RUP, so I don't know what activities you have in your Inception phase, though I agree that any deliverable is testable. But not everyone calls it "testing." For example, some people consider formal inspections of a document or code to be a static testing activity, but other people think it's not testing unless you're dynamically executing a program. They're not saying that it shouldn't be done, just that it doesn't meet their definition of "testing." Don't get too attached to terminology.  Describe what you want to do and why, and then agree on terminology that's acceptable.

Perhaps the term "deliverable" is causing problems too.  You also used the term "artifact," which is a more generic term that your colleague may be more willing to apply to all of the tangible items that are produced along the way.

Once you make sure terminology isn't getting in your way, you can find out whether you can agree on the activities that the testers should be doing during the Inception phase.

Copyright 2004 by Tejas Software Consulting
#####

  Back to the newsletter index     Back to the home page