RE: Re: Sticking point

Stefan,

> > I can imagine software that runs on my machine and not yours.
> 
> Hey, but if it cannot run on mine, I cannot prove anything, while 
> if it does
> there is a chance it works on another machine as well.

Absolutely. But a chance it doesn't.
 
> See, think positively.  If I can show something that runs on my machine,
> there is a positive statement.  You have "added value".

Quite true - I wasn't saying otherwise.

> > Just kidding, we don't have to imagine that, it happens all the time!
> 
> True.  But there are several issue.  It's not because it runs on 
> yours that it will run on mine ;-)

Right, the most common problem I've run into is that software makes
use files that are normally not part of the OS, but are installed with 
the development environment. So unless those are also added, only
developers can run the software. I actually saw one product ship
and then have such a bug discovered. Rather embarassing.

> > In a shrinkwrap environment, there's generally a requirement that
> > the software run when installed on a newly set-up system with only
> > certain things on it. There's generally also a requirement for an
> > install program to do that setup.
> > 
> > So at least in that environment, I'm for creating the CD and 
> > running the install as soon as it's available... and I think
> > it's better to have it available pretty early in the process.
> 
> I think you need it early on but not necessarily continuously.
> Why wouldn't an image of the CD on an FTP server be equally good?

It can be. When it is, that's what I would do. I'd certainly start
out with that approach. My usual way of doing the setup in a 
project is in this order:

1. Clean copy of all the files needed on a network server with
manual instructions for copying them - possibly a script.
2. An actual setup on the network which also does the proper
settings on the machine in addition to copying the files.
3. A setup on a CD or a user-friendly web page - depending
on how the application is being distributed.

I consider #1 as the minimum, and I just do it without asking
anyone. Stage #2 is often needed where a seprate testing group
is working on multiple machines, OS versions, etc. I usually
will do it but tell the customer what is going on and how much
time it will take in the iteration. [If the customer disagrees,
then it's a matter for discussion, of course.] Stage #3 is
an actual customer story. Depending on the environment I may
encourage it strongly, or I may not. [I was thinking of a
particular environment, which I'll describe below.]

> > This is similar in concept to quickly developing a version of
> > the entire system that runs from beginning to end, but without
> > some of the detailed featurs. The installation process is
> > also part of the user experience and it really s*cks to get
> > to the "end"  and find out you don't have a way to install.
> 
> But you don't need the CD, you only need the setup.exe (sorry for the
> simplification)

The development environment had sales staff all over the world.
Interim releases - sometimes unplanned - were given to them so
that important customers could get an advance look at what we
were doing and plan their future purchases - or stop planning
to buy from a competitor. We also had demos at shows and to
sales meetings that needed to be done on short notice. The 
sales guys needed a very simple way to install on their laptops. 
They needed to be able to reinstall if they messed up. We 
decided that a CD-based setup was the easiest way to do this.

This approach paid off in our case. Before we did this, we 
would frequently have to interupt the normal flow of work
in order to create special versions or manually set up a
laptop. This approach was taken to simply accept and implied
customer need and make it explicit. 

Like everyone, I was thinking of my own experience. Of course,
without the particular needs we had, we would have just stayed
with the network. But with this experience under my belt, I
always check into the need for frequent interim releases, demos
etc. when I'm planning a project.

> > In an IT environment, I'd expect some similar criterion to
> > be applied. If you plan to distribute by handing out CDs,
> > then exercise that. If it's web-based distribution, then
> > get it set up early and test it.
> 
> What risk is there that an image of a filesystem cannot be burnt 
> onto a CD?
> Why is everyone so succesful in ripping Audio CDs (and DVDs).

The only risk I know for the CD distribution is that the machine
may not be properly setup to do it - but that's fairly easy if
the hardware is already installed.

In the case of a web-based distribution, it can be more
sophisticated since you may be downloading individual files
on demand. If it's just a large download and then execute,
it's even simpler than CD.

> I think I'm missing something but I don't know what.

I hope I explained it.

Charlie Poole
[email protected]
www.pooleconsulting.com
www.charliepoole.org




------------------------ Yahoo! Groups Sponsor ---------------------~-->
Get 128 Bit SSL Encryption!
http://us.click.yahoo.com/CBxunD/vN2EAA/xGHJAA/NhFolB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, send an email to:
extremecustomering-unsubscribe-hHKSG33TihhbjbujkaE4pw@public.gmane.org

 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/