Microsoft .Net's impact to Automation Industry

J

Johan Bengtsson

I get vague and "impossible" requests at work too, I argue, I get better requests and so on, in the end I know what needs to be done and do that, but I really have to have those answers before I can do it, otherwise I won't be solving the
real problem, and the one making the request in the first place won't be happy anyway. A lot of times don't the people making the requests really know what they want, how could they possibly tell me then?

The same problems exist in closed developement as well as open if the one doing the work don't understand what work needs to be done then it won't be. That is not a difference - it is a
similarity!

A real example from my work:
Some customers to us wanted the possibility to create new simulated mashines by themself, ok I agree to that it would be a nice feature to have. But I could not get any useful explanation about what types and how complex those mashines needed to be, and not a good explanation on what skills the user would need to have. The answers I got was very vague and something in the direction of "drag and drop" some parts here and some parts there conveyor belts, cylinders, and other similar
parts. And that should end up being a simulated mashine. Runnable in real time on a pentium 90MHz. I thought about it and gave a figure approximating how much time I would need to do that and some doubts that it actually would be
runnable in real time on a pentium 90MHz. Then I asked if the customer really needed that feature to be happy or if more simulated mashines was really what was needed I could simulate several mashines in much less than 1/10:th of that time and they would really be runnable on a pentium 90.
The difference here is that I am a programmer - I can make those simulations without making the tool first, because I already have the tool *I* need. Well we did simulate some more mashines and not many have bought them because they thought the ones already in the product was quite enough.


/Johan Bengtsson

----------------------------------------
P&L, Innovation in training
Box 252, S-281 23 H{ssleholm SWEDEN
Tel: +46 451 49 460, Fax: +46 451 89 833
E-mail: [email protected]
Internet: http://www.pol.se/
----------------------------------------
 
Michael Griffin wrote ........

<snip>
>The reason for this isn't need or technology, but rather
>accounting. If someone from the plant wants to spend any money, they must
>show a direct cost saving. If someone from the finance department wants to
>do something, they just demand it and bury the cost in someone else's
budget.
</snip>


EXACTLY !!!

The last half dozen projects I've done have been controlled by the accounting department. If you can convince bean-counters that a new system
will save them money they'll insist the technical staff install it.

Us techies hate to admit it, but bean-counters rule the world !!

Mark Hill

 
C
Hi Micheal

That is as close I think, as we can come from published and leaked sources. Put the web under the hood, weld it shut, and bill frequently.
I wonder what will happen to those who don't buy in. Will we have all but 20% of the web off-limits to us? Or, will they find a way to bill us too?

I think this is a wonderful idea ( obligatory Not Bashing MS line )

Regards

cww

--
Free Tools!
Machine Automation Tools (LinuxPLC) Free, Truly Open & Publicly Owned
Industrial Automation Software For Linux. mat.sourceforge.net.
Day Job: Heartland Engineering, Automation & ATE for Automotive Rebuilders.
Consultancy: Wide Open Technologies: Moving Business & Automation to Linux.
 
R

Ranjan Acharya

I think that Mr. Griffin has "hit the nail on the head" with his analysis. The point of any plant-floor addition beyond basic machine control is often extremely difficult to justify on a capital cost basis.

We have had many customers extremely impressed with packages that, for example, play "how to" videos for maintenance and troubleshooting purposes. They never get the money from their higher-ups since the cost savings are difficult to justify (even though they are there) or over a too long duration of time. Many customers, especially right now, are pressured with
very short payback times for any capital project that cannot be met with some beyond-basic-automation projects.

On the other hand, when orders appear from on high for an ERP System, Mr. Griffin's point falls into place and the money magically appears.

It just does not matter if the bells and whistles are using embedded Linux, Linux, Windows, Unix, BSD or OS X for that matter. As long as they work
(the point with .NET is that many whistles just will not work or blue screen after two weeks for no apparent reason).

I am more concerned with locking horns with IT types than if the packages are from Microsoft or a collection of Open Source programmers -- they hold the reins of these projects which can be quite a shock when the automation types are used to being top dog. The different approaches to factory automation from IT to field level can be quite interesting and the discussions quite refreshing. As an aside, the IT types need to know that PLC automation cannot be made with a wave of the magic wand -- please put some money in your budget for the PLC and SCADA side of things! Also, don't forget that it requires commissioning (and therefore downtime -- more than
fifteen minutes on a shift change would be preferable) and don't forget that if you take your system down without telling someone the whole factory will shut down.

Complex systems have complex problems that can only be solved by multi-disciplinary teams working in co-operation. My colleagues and I enjoy the challenge.

 
No, you are absolutely incorrect. Your example of illegal drugs is specious and does not pertain to the discussion. I was not using "good" in its moral sense. I was using "good" in its sense of "suitable to the service."

This is as true as gravity: a product is "good" if a large percentage of the target population buys it and uses it for its intended service.

There is no other definition of "good" that works in product development.

There are a lot of people who refuse to believe this. Most of them do not do well.

Putting too many features on a product will usually destroy it. Most engineers do not want to believe that.

A pretty face plate on a product that is 80% as good as the one that is ugly but better: the pretty product will outsell the ugly one.

And every person that buys it will tell you he or she is making a rigorously logical purchasing decision based on the requirements and the
specifications.

What rot.

The key to good product development is to determine as closely as you can what features and what functions the target customer base needs _and knows it needs_ and provide a product with just those features and functions.

Once in a while, somebody will "rare back and th'ow" a product that meets customer needs _that they don't know they need_. These are so rare that they are almost always written up as breakthrough products.

The "law of good enough" stands.

Walt Boyes

---------------------------------------------
Walt Boyes -- MarketingPractice Consultants
[email protected]
21118 SE 278th Place - Maple Valley, WA 98038
253-709-5046 cell 425-432-8262 home office
fax:801-749-7142 ICQ: 59435534

"Strategic marketing, sales and electronic
business consulting for the small and medium-sized
enterprise: http://www.waltboyes.com"
---------------------------------------------

 
Jiri:
> > A lot of the time it's frustrating for us, too, because many of the
> > requests are vague, out of our hands or otherwise problematic.

Ralph:
> Its just an observation of mine that those espousing Linux don't seem to
> take the criticism from skeptical potential users seriuosly. Vague input,
> asking for the unreasonable results, etc. are all very typical of the
> kinds of requests that you get from any potential user.

True.

> Probably because most people don't spend that much intellectual effort
> trying to determine why they won't do something. They don't really know.

Actually, it's probably simpler than that - the potential user doesn't know what can be done, and therefore can't phrase the request in those terms.
It's not even lack of effort, I think a lot of times it's simple lack of knowledge (which is unavoidable under the circumstances).

> > > a comment about the lack of tools to extract data from a server was
...
> > I also pointed out that you probably wouldn't bother, because there's
> > easier ways of doing it.
...
> If there is an easier way, that is the information that Joe needs.

I think I started my post with that... just write the whole program on the server, run "ssh server" on the client and start the program through that.

> > Joe was posting as a VB developer.
...
> he does not consider himself to be a developer from a computing
> perspective. He thinks VB is so high-level that
...

Well, shell scripting is pretty high-level, too. At the level of detail we were writing, the main difference would be that in VB you say "it's the
icon that looks a bit like a squashed octopus, only not so ugly", while in Linux you say "it's nc(1)", which strikes me as much less ambiguous, but
otherwise not all that different.

Shell scripting is based around the idea of pipelines - the data (usually text) is passed along the pipeline from one process to the next. For instance, if you had a table (table.txt) and you wanted to know how many times each value of the second column appeared, you might do this:

cut -f2 table.txt | sort | uniq -c | sort -n

Here, there are four processes in the pipeline, separated by vertical bars. Data goes from left to right:

cut -f2 : grabs particular fields from tables (in this case *f*ield 2)
sort : sorts alphabetically (so equal values end up next to each other)
uniq -c : gets rid of duplicate lines, *c*ounting them
sort -n : sorts *n*umerically

It doesn't say where it should go at the end, so it'll go on the screen.

> > > If the participants in Linux who are steering the bandwagon want
> > > others to jump on they would be well advised to heed Walt's
> > > suggestion and start steering it in the direction that the people who
> > > have reasons to not use it are pointing you.
...
> > Anything I've missed? (I think I've got most of the thread saved, just
> > point me to a keyword or Message-ID.)

> You missed the whole point.

Drats.

> The message from Walt was subtle and there was an element of sarcasm to
> it that I'm sure will get your hair standing up. I enjoy sarcasm but its
> not conducive to understanding.

I don't mind sarcasm myself, actually...

> Walt is trying to point out that if someone desires to get Linux into the
> mainstream of IA then the development of Linux has to be guided in a way
> that addresses the needs of the people who are the potential buyers of it
> (who are not necessarily the users) and not the developers of it.

Well, OK - and those needs are?

(BTW, the MAT LinuxPLC has on-line-editable stepladder, as of yesterday. It's pretty ugly, version ``0.3'', but it's there.)

> Most of the things that Walt has pointed out are his opinions as to those
> issues that the Linux efforts are not addressing.

As far as I can see from his post, that's simplicity of installation/setup and integration?

Simplicity of installation and setup is a lot better than it used to be, and it's improving still. The poster child here is Webmin, a web-based admin tool (which has the added advantage that you can use it remotely).

For integration, linux has an advantage in that its design philosophy from the beginning was lots of little applications that interact (rather than a few big ones that don't), so it has a head start, and that it's better for networking and multi-user operation.

> I don't claim that it is your responsibility to provide this business
> model to them or that you are responsible to overcome any of the
> technical objections either.

On the business model, see my other post with the URL to ESR's essay.

As for technical objections... well, I'd like to hear them, anyway; I might not do anything about them, but at least I'll know about them.

> The Linux effort just does not have any signficant marketing efforts
> addressing the IA industry.

I guess not... apart from Curt and me posting to the A-list...

Jiri
--
Jiri Baum <[email protected]>
http://www.csse.monash.edu.au/~jiribvisit the MAT LinuxPLC project at http://mat.sf.net

 
R

Ralph Mackiewicz

> > he does not consider himself to be a developer from a computing
> > perspective. He thinks VB is so high-level that
> ...

...snip...snip...

> cut -f2 table.txt | sort | uniq -c | sort -n
>
> Here, there are four processes in the pipeline, separated by vertical
> bars. Data goes from left to right:
>
> cut -f2 : grabs particular fields from tables (in this case *f*ield
> 2) sort : sorts alphabetically (so equal values end up next to each
> other) uniq -c : gets rid of duplicate lines, *c*ounting them sort
> -n : sorts *n*umerically

Thank you for the detailed description of how to accomplish this on Linux using scripting. Take my word as a non-programmer: This will not be perceived as easy or simple to anyone who is not a programmer. It is easier for my primitive brain to follow a 20 line VB program to do the same thing than to figure out how this simple script works. VB might not be efficient but it is much more intuitive.

This reminds me of a contest I saw in 1986/7 for the smallest program for sorting names alphabetically. The winner was an APL program that
was a completely unintelligible collection of punctuation marks and letters that was only about 40-50 characters long as I recall. The amazing thing is that it was actually purported to work. Linux scripting is very intuitive by comparison.

> > The Linux effort just does not have any signficant marketing efforts
> > addressing the IA industry.
>
> I guess not... apart from Curt and me posting to the A-list...

That is not marketing...it is evangelizing. Getting to the crux of what a user requires, what they will buy, how much they can afford to spend on it, and how to inform them of the value takes alot of marketing when dealing with a large market like IA. Evangelizing can be an important part of marketing communications but the important
aspect: finding and explaining the value to the potential customer requires a lot more effort (and investment). Given that Linux is essentially free, some other business model must be found that
provides the incentive for making this investment in marketing before Linux will find its way into the corporate mainstream. IBM seems to be finding a business model based around selling high-end servers.

Maybe that will be the coat tails the rest of the Linux community can ride on.

Regards,

Ralph Mackiewicz
SISCO, Inc.

 
B
> 1) Until recently it has been very difficult or impossible to
> connect most production machinery to anything. Proprietary networks still
> make it far from easy.
> 2) Most plants did not have a reliable office network system to
> connect to. If the data wasn't available to everyone, it was of limited use.
> 3) Standard application software which can make use of the data is
> only now starting to appear. Most previous applications were custom software
> which were very expensive to create and maintain.
> 4) People haven't realised what was possible.


I think the assumption is that raw data is of some benefit to someone somewhere. I sort of doubt it. Unless it is in a useful format. Most
people are not in a position to spend a lot of time trying to organize raw data into a useful form.

Bob Peterson
 
B
> I think that Mr. Griffin has "hit the nail on the head" with his analysis.
> The point of any plant-floor addition beyond basic machine control is often
> extremely difficult to justify on a capital cost basis.

Often there is no cost justification for such systems, which is why so few people are willing to pay for them.

> We have had many customers extremely impressed with packages that, for
> example, play "how to" videos for maintenance and troubleshooting purposes.
> They never get the money from their higher-ups since the cost savings are
> difficult to justify (even though they are there) or over a too long
> duration of time. Many customers, especially right now, are pressured with
> very short payback times for any capital project that cannot be met with
> some beyond-basic-automation projects.

I have seen a lot of these systems. As far as I am concerned the short little videos are usually of little value and you can rarely hear whats being said so the real value is generally nil in these systems. People who think otherwise generally like bells and whistles and other fluff and are willing to shortchange things of real value to get them. I have actually seen systems where the graphics change color from season to season to simulate snowfall and shadows on the outside equipment from different sun angles. This information is really generally useless but impressive to some.

> On the other hand, when orders appear from on high for an ERP System, Mr.
> Griifin's point falls into place and the money magically appears.
>
> It just does not matter if the bells and whistles are using embedded Linux,
> Linux, Windows, Unix, BSD or OS X for that matter. As long as they work
> (the point with .NET is that many whistles just will not work or blue screen
> after two weeks for no apparent reason).

This problem is getting to be less of a problem with later verisions of MS OS's. NT is gradually being replaced with W2000 which appears to be far less susceptable.

> I am more concerned with locking horns with IT types than if the packages
> are from Microsoft or a collection of Open Source programmers -- they hold
> the reins of these projects which can be quite a shock when the automation
> types are used to being top dog. The different approaches to factory
> automation from IT to field level can be quite interesting and the
> discussions quite refreshing. As an aside, the IT types need to know that
> PLC automation cannot be made with a wave of the magic wand -- please put
> some money in your budget for the PLC and SCADA side of things! Also, don't
> forget that it requires commissioning (and therefore downtime -- more than
> fifteen minutes on a shift change would be preferable) and don't forget that
> if you take your system down without telling someone the whole factory will
> shut down.

This is mostly about power and control. It took them a long time to take over the PC world and they do not wnat to risk losing any control at all.

> Complex systems have complex problems that can only be solved by
> multi-disciplinary teams working in co-operation. My colleagues and I enjoy
> the challenge.


Bob Peterson
 
J

Johan Bengtsson

Ok, I'll try to explan one possible buisness model:

I have a problem I need to solve, in my buisness. I get paid by someone to get that thing working.

I realize the same, or at least similar problems, would need to be solved by other as well.

The solution to my problem involves making four things, for example a driver for communicating with a certain I/O, a driver for comunicating with a certain brand of PLC, some way of showing
some information on a screen and some connections between those.
(this is a non existing example just selected for describing the model).

Now I have some options:
* I can do them all by myself.
* I can try to find someone selling some of the parts and write the others myself.
* I can join forces with someone else trying to do a similar thing and decide that I write some parts and the others write other parts.
* I can use already made GPL:ed parts and add those missing.

Now, what does this cost?
Well, everything I do by myself will take time, time=money ie a cost.
If I buy something there is a cost.
Joining forces will make me spend less time on my parts, becasue there are fewer of them.
Using existing free parts is of course cheaper - if they exist.
If they don't, well then that is not an option is it?

Further about joining forces: I might be good at writing drivers, bet very bad at writing visualization. Other people might be the other way around.
If each driver would cost me about one week of work and the visualization about three weeks.
Then, if there is someone else just the other way around, he/she would write the visualization in one week but need three weeks to finish each driver.
If I could find one person like that and one other like me we could finnish those three tasks in one week each. The connecting them togheter task might be unshareable since it might need to
be done differently and we all have to do our own part of that anyway.

Some people have realised that if we join forces and thereby do less in order to solve each problem we have then we have to spend less time and thereby have a smaller cost. In order to give a way the work done mutually some people like to have a "guarantee" that using the part I did would remain free to all other people as well.

I hope you see where the buisness is in this model - and why.

/Johan Bengtsson

----------------------------------------
P&L, Innovation in training
Box 252, S-281 23 H{ssleholm SWEDEN
Tel: +46 451 49 460, Fax: +46 451 89 833
E-mail: [email protected]
Internet: http://www.pol.se/
----------------------------------------

 
All,

I had this e-conversation on another forum and Jim Pinto suggested I share it here. I apologize for its length but I used to attend this forum
regularly and I think many will take interest in the content.
======================================================
I read with interest the opinions of Walt in your latest on Microsoft.NET. Is using .NET as crazy as using NT for factory automation? I remember many tireless arguements on the Automation List about that one too.

As you know, I transferred out of industrial automation and into residential automation about two years ago (and just got laid off) and man, you would be set on your ear to find out what is going on over here. By Residential automation I DO mean the Jetsons sitting around the evening JVM dining on downloaded applets. For those of you who believe the Interenet Lifestyle, often referred to as the Jetson's Lifestyle, is a laugh, check out www.internethomealliance.org. Now, once you have digested the list of founding members (Sears, GM, Cisco, Motorola, Invensys, etc) consider that EACH of these founders fronted $2.5mil to join. Yes, that's right - the iHA
hit the ground running with $50mil in cold hard cash. Imagine what Bill Moss could have done with $50mil in his pocket on day one.

Now let's look at the two big driving standards behind Residential Automation, www.osgi.org and www.upnp.org. OSGi is the Open Services Gateway Intiiative formed by Sun and populated by basically the same group of companies as iHA. The principle behind OSGi is that you have a
Residential Gateway running a full JVM ontop of which sits your JAVA Embedded Server as a run-time engine. This is an empty bucket into which
your ISP or some other benevolent body can pour JAVA Service Bundles. To put this into "your" terms, you download Self Tuning algorithms on startup. Once the machine is running and tuned, you remove the Self-tuning and download code for SPC. If there is an SPC alarm, you remove the SPC code and download Adaptive Tuning or Diagnostics code. ...all this just to save
a few Meg of Flash. Is this starting to sound like the .NET concept?

Now add to this UPnP, Universal Plug and Play, formed by Microsoft and filled with basically the same list of companies that are in OSGi and iHA.
UPnP is XML based and says that any device can hop onto a network, declare itself as a member, describe itself to everyone and then become an active part of the automation framework. This is a beautiful concept when combined with ODVA-style device profiles. It could eliminate tens of thousands of dollars in configuration time for a SCADA package.

So what happens if a server somewhere downloads a hostile Service Bundle to your OSGi Gateway? Or what happens if a hostile node hops onto your UPnP
network? These organizations haven't sorted out all of these details yet because they are not Controls companies. They are still struggling with the same dilemmas we all solved 20 years ago, but it gets worse.

In a factory, you have wires, and these wires are shielded, and these wires connect instruments, and these instruments are in cabinets, and these
cabinets are earthed with big copper rods, locked with padlocks and only opened by trained personnel. In the home, you communicate with your
appliances and electric meters over the same powerline (yes, PLC means PowerLine Carrier, not Programmable Logic Controller) your neighbor uses to turn on his lights, or your thermostat talks to your gateway via the same Bluetooth network your neighbor uses to print from his laptop, or you download MPEGs over the same 802.11b wireless ethernet your neighbor uses to browse the interent. They are all different logical nets but they all use the same PHY as does your neighbor.

Now don't get me wrong; the companies behind these standards are full of smart people who recognize that these sub-nets must be secure. They are just having a bit of trouble getting there.

So should we be afraid of the .NET scenario? I don't know, but there is a much bigger industry out there than "yours" that will end up choking it down right along with the java that you purchased automatically via www.Peapod.com.

Mitch
[email protected]

 
M

Michael Griffin

At 13:00 05/09/01 -0500, Curt Wuollet wrote:
<clip>
>That is as close I think, as we can come from published and leaked sources.
>Put the web under the hood, weld it shut, and bill frequently.
>I wonder what will happen to those who don't buy in. Will we have all but
>20% of the web off-limits to us? Or, will they find a way to bill us too?
<clip>

Dot Net may or may not turn out the way Microsoft (and others) currently envision it. Remember that Microsoft's attempt a few years ago to replace the internet with their own proprietary network was a complete flop. Nobody wanted it and Microsoft had to abandon the whole idea.

However, let us assume for the moment that Dot Net *is* accepted and *is* successful in the business and home market. How will this affect
automation? There are four possible channels this effect could operate through.

1) Windows may change in such a manner as to become unsuitable for use in soft logic systems. We will assume for the purposes of this
discussion that it suitable in at least some applications today.
2) Windows may change in such a manner as to become either better or worse for use in large scale MMI systems.
3) Some specialised versions of Windows such as Windows CE (which is used in some OEM products) may not fit the Dot Net model and be terminated, or simply cease to have any development effort applied to it as a "non-core"
product.
4) The programming, CAD, and other similar software used in creating and maintaining machines may be delivered or paid for in a different manner than today. This may be good or bad. This is really an indirect effect on the Automation Industry, but it deserves consideration.

The question then becomes what could cause each of the above to occur, and how likely each of these is.

**********************
Michael Griffin
London, Ont. Canada
**********************

 
J

Joe Jansen/ENGR/HQ/KEMET/US

I agree completely. It is all about value. Return On Investment. So if the manufacturer, who you appear to say doesn't know what they are doing, can get a 5% increase in efficiency for the cost of $500,000 are they going to do it? Probably not.....

If the same mis-understanding manufacturer can get the same 5% increase in efficiency for $150,000 would that increase or decrease his chance of investing?

Walt, I think you are promoting larger scale projects to increase the size of the return, and spreading the higher cost of the investment across the larger return in efficiency. Of course, this is a perfectly valid method of doing it.

Curt, on the other hand, appears to be working the other side ofthe equation, by bringing the cost down, he can justify investment in smaller
return projects by decreasing the cost of the investment.

I would be cautious, however, stating that manufacturers don't understand their business outside of making parts. Telling the customer that they don't know what they are doing rarely seems to work out in a beneficial manner.

Maybe _I_ also don't understand, but I took your point as saying that small projects are dead, and that the only market space available was for MES and ERP scale projects. I can't agree with that, tho. MES and ERP are dismal failures because they have been oversold, and are so disgustingly
overpriced for what you get. Monolithic software should be killed. A plant I worked at had the PHB's convinced by a salesman that they should
invest in ERP. Last I heard, they had topped the $2 million mark, and were still going at the rate of $250 / hour for the programmer to make
modifications to the base system in a proprietary language. I can not use words strong enough to tell you what absolute garbage that is! This was a plant that employed just over 100 people total. ERP has added no value to them whatsoever, and is a total money sinkhole. (Incidentally, the ERP systems guys told them that it would work better on a unix server, but they instead opted for a Windows NT cluster. NT's clustering is even more hilarious. Apparently, hot failover is defined as occuring within 60 seconds. Typical failover times ran about 45 seconds, but disconnected some of the services anyway.)

Lastly, I didn't read any of Curt's post as "trashing" you, Walt. I cannot say that the opposite is true, tho. Your replies did seem to take on a rather personal tone. I think you do operate in a different world than those that are on the shop floor making the incremental improvements that _every_ plant needs.

I think it is benificial to everyone to pick up a set of wrenches and go get dirty for a few weeks a year, minimum. The only way you keep in touch
with what is happening on the floor is if you are out there. I make a point of having detailed discussions with every operator on my machines _at
least_ weekly. Not their supervisor, not the plant manager. Even if it means a special trip to that facility to do so. And even tho I am the
"software guy" for those machines, I make sure that I get time out there replacing a gear box, pulling cables, or whatever occaisionally so that I don't lose touch. I get more information about what nuances the machines have, and what simple changes could be made to make the operators life
easier while I'm out there working than I will ever get out of a prduction meeting. Stuff like: If that button were on this screen instead of that one, I could save time setting up a batch. It's a 2 minute fix, but would never be brought up in a meeting.

I would challenge anyone on this list: When was the last time you had a substantive discussion with an operator? How about during a system design? My experience has been that the guy doing the job for 10 years know the machine and processes far better than the engineering manager that is going to try to tell you how it works.

<End Soap Box>

--Joe Jansen

 
V

Vladimir E. Zyubin

Hello Mark,

Yes. Profit culculation is the only one right way to make decision. But a problem exists. The vendors can convince beat-counters to make wrong
decision... for example, http://www.plantweb.com/ (TestPlantWeb link, the means of persuation)...

Another argument of persuation could be the appeal to the fear to be off mainstream.

At that there are researchs that show: the total computerisation doesn't save money in real life at all...


--
Best regards,
Vladimir mailto:[email protected]
 
A

Anthony Kerstens

Add to the law of good enough the corollary of the recognizable.

How many of us buy a particular product because we've used it for years without even questioning it's competativeness.

For example, my mother uses Sunlight laundry detergent and refuses to believe that there is any better. She doesn't even look at other products.

So, people will buy into .Net (initially) just because MS _has_ been good enough for _their_ purposes for so long.

And there are people who will shun it just because MS has _not_ been good enough for _their_ purposes for so long.

Anthony Kerstens P.Eng.
 
M

Michael Griffin

I have a little story to tell, which I will relate without mentioning the names of any companies or individuals.

For several years a certain person (Mr. 'X') has been pursuing a "plant integration" project for his company. We'll call this company 'A'. He did various design studies, selected software and hardware, budgeted manhours, wrote reports, etc. All the managers who would benefit from this project were all in favour of it.

Each year it was put in the budget, got approved, and then before the POs could be issued, the money just vanished - and nobody could find out why. It happened at such rarified levels of finance and management that nobody involved in the project could get an answer, but apparently, someone just didn't see the return on investment. This makes it a *bad* idea. Most
people would give up in frustration, but Mr. 'X' is rather stubborn.

A certain very large automation products company whom we all know has established a subsidiary in Toronto to engage in what they call "IT integration". We'll call this company 'B'. They provide consulting services
involving both their products and certain third party software.

It so happens that the head of this IT integration division happens to know the director of company 'A'. He says he would like to show him what they can do. The director of company 'A' tells his managers to arrange a meeting with company 'B' to investigate this terrific idea. This idea has been proposed by company 'B', so obviously this is a *good* idea.

The Mr. 'X' at company 'A' (mentioned at the beginning of this little story) who has been getting nowhere in his efforts received a
telephone call from the third party software company whose application software he has been proposing to use as the centre of his project.

It seems that company 'B' has asked this third party software company to put on a demo for the managers of company 'A', and the person doing the demo would like some information on who these managers are. Mr. 'X' says "Meeting? What meeting?". The third party company replies "Surely
you must know about the meeting - you've been working with us on this for several years now. Besides, who else in your company would understand what we'll be talking about?"

Mr. 'X' assures them that he has never heard if this "IT Integration" division of company 'B', and knows nothing about any upcoming
meeting. However the names they have mentioned are all highly placed directors and managers who can approve the project if they like what they see.

The moral of the story is, that if you are trying to sell "plant integration" to a company, you are wasting your time if you speak to someone who has any idea of what you are talking about. Instead, concentrate on selling to the people who don't have to justify their decisions.

I would like to finish this story by saying how in the end everyone lived happly ever after, but this big meeting won't happen for another couple of weeks yet.

**********************
Michael Griffin
London, Ont. Canada
**********************
 
The use of piping the UNIX tools to produce some output is interesting. It really goes along with what one of my friends use to say, "There are two
laws to UNIX: 1) Everything is a file 2) Get the last word." The second rule talks about being part of a community. The operating system is a
language that you learn. The guys that invented it really understood language and it is evident in the rich set of tools that you have for
processing text streams. You can even build compilers with the tools.

Curt and the other guys that are talking up the beauty of Linux and OSS have made the investment in learning UNIX and they are utilizing that
expertise to develop good solutions for their customers.

Nevertheless, I have a hard time seeing a change in the IA market. While some IA companies have put tools or applications on the Linux platform they have not committed to the platform. For each of these Linux offerings there are many, many more that are offered for the Windows environment. It is obvious that a very small fraction of the IA software is offered on Linux.
In some case the offering is a communications driver to aid in systems integration, while the real applications stay in the Windows environment.

While a lot of marketing is hype, you can often tell how much force a company has by the amount of information that they are able to extend into
the market. If you go to their web site you can get a feel for how much energy they can put into communicating to the public.

Taking a look at the Linux PLC web site that has a link off www.control.com, may be a good example of how much energy the Linux PLC project has. Maybe I missed a link or something, but there isn't very much information on that site. It is very indicative of what you find with OSS.
Unless, it is Linux and it has grasped enough attention that someone sees real dollars out there then you just don't have much there to work with.

It goes back to my friends second law of UNIX - you need to be part of the team to make use of it. More power to Curt and anyone else that works on this. If they are able to 100 people outside the team to use it, then they have accomplished a great deal.

 
B
Ralph Mackiewicz said:
> Thank you for the detailed description of how to accomplish this on
> Linux using scripting. Take my word as a non-programmer: This will
> not be perceived as easy or simple to anyone who is not a programmer.
> It is easier for my primitive brain to follow a 20 line VB program to
> do the same thing than to figure out how this simple script works. VB
> might not be efficient but it is much more intuitive.

I always suspected that people that used VB were not programmers and could not perceive detailed descriptions.

With a little sarcasm,
Mark Blunier
Any opinions expressed in this message are not necessarily those of the company.
 
B
> This is as true as gravity: a product is "good" if a large
> percentage of the
> target population buys it and uses it for its intended service.
>
> There is no other definition of "good" that works in product development.
>
> A pretty face plate on a product that is 80% as good as the
> one that is ugly
> but better: the pretty product will outsell the ugly one.

Hmm. product Ugly has U market share. Product Pretty has 0.80*U market share, yet your stated definition of good implies that a the product with more market share is the better product, suggesting that 0.8*U > U. Your own example
shows that 'good' is more that just a measure of market share.

Mark Blunier
Any opinions expressed in this message are not necessarily those of the company.
 
Good Luck Michael !!!

I experienced EXACTLY the same scenario.
Fortunately Mr. "X" won out in my case.
Research company "B's" products and services.
During the meeting ask pointed questions you know they can't answer or shows their product in a poor light. Watch them squirm !!
Worked for me.

Mark Hill


 
Top