Re: Arlo, a little QA comment regarding your interview with linux.com

[Kevin Cullis <kevincu orci com>]

Hey Tom,

Tom Musgrove wrote:
> 
> Hi Kevin,
> 
> a while back I posted to a list (not sure which, can't find the email), a
> suggestion for having some software to track feature usage in the assorted
> gnome programs to find out which are the most used, as well as tracking what
> features are used with each other for grouping purposes.  It could be built

You can do some of the grouping by doing some preliminary stuff by
asking developers and software development companies for their input.

> into the standard distribution, and be an opt in thing (Would you be willing
> to have your feature usage tracked, for the purpose of improving the Gnome
> GUI?).  Although some would opt out for privacy purposes, I'm sure that many

Two things here.  First, I would try an Opt Out first and allow people
to see the information/stats which are gathered (rather than telling
them what is tracked) via a read only file (to prevent tampering or
contaminatig the data) rather than an Opt In. That way you can encourage
participation.  I would also tell users what information you would be
tracking, why it's used, and who/where to contact if there are any
questions or feedback .

Second, I wouln't mind at all. From a QA perspective, there is an
interesting point here.  I've got a Masters degree and my thesis was on
process improvement.  I consider the software development industry to be
where the auto industry was in the 70's, just beginning to see the
benefits of improving quality because competition was catching up to
their level of quality (see it as a rate of improvement).  Most of the
software houses I know of see QA as only applying to testing, not to
design.

Let me explain a Quality Principle: the closer you get to the original
idea, the cheaper it is to fix it.  Take a look at Taguichi's function
below:

$$$$|                    *
    |                    *
    |                    *
$$$ |                   *
    |                  *
    |                 *
 $$ |                *
    |             *
    |          **
    |      **
  $ |***
    ------------------------
   Idea--Design--Manufacture--Sale--Customer
   Idea--Requirements--Plan--Code--Test--Install--Customer

The above graph represents the costs to fix something over time.  The
closer you get the problem into the customer's hands, the more expensive
it is to fix.  By the time a $1 fix is found at the design phase, it'll
cost $1000 to fix when it reaches the customer.  Preventing a problem
costs less than letting it go through.

Now with that said, regression testing is only the "manufacturing" phase
of the problem, or based on SE stuff, toward the end of the process. 
Without designing quality INTO the process you've incurred REAL costs
are in SE stuff.  It's also the reason that "costs" are over budget in
software projects, because company's don't have good enough measurements
to KNOW where they are.

That being said, most programmers don't measure their time, and notice
that I said time, not productivity (besides, I believe that thinking
comes before doing).  Time AND software defects should be tracked to
determine problems within the repeatable PROCESS, not the person. Think
of the Olympics, they measure stuff so that they can improve their
chances of winning, not to beat up on people. The key issue is to
measure to PREVENT problems over time.

> would be willing to participate.  We could easily end up with a much larger
> user base than most GUI research gets.  If we accompanied this with an
> interview about the type of work they do, we could find out what features
> are most relevant to what professions.

Absolutely!  You might want to look at users group to solicite initial
feedback or input.

> 
> Also, if we have a general interviewing tool about what software they are
> familiar with, they could have the option of using familiar key bindings and
> layouts if they so desire, also it would provide a method for explaining the
> relevant differences in the software and thus reducing training times.

True!

Kevin

begin:vcard 
n:Cullis;Kevin
tel;home:720-489-9283
x-mozilla-html:FALSE
adr:;;8285 S Poplar Way #202;Englewood;CO;80112;USA
version:2.1
email;internet:kevincu orci com
x-mozilla-cpt:;0
fn:Kevin Cullis
end:vcard