-------------- Original message --------------
From: Ernest Christley <echristley@nc.rr.com>

> Forwarded by popular demand (Ed'd popular and he demanded it 8*)
> {Several typos corrected}
>
> -------- Original Message --------
>
> Applaud! Applaud! Great insight, Ernest. Should post this on the Rotary
> list just for our general info.
>
> Ed
>
> Ed Anderson
> Rv-6A N494BW Rotary Powered
> Matthews, NC
> eanderson@carolina.rr.com
> ----- Original Message -----
> From: "Ernest Christley"
> To:
> Sent: Monday, June 26, 2006 10:44 AM
> Subject: AeroElectric-List: Re: AeroElectric-List Digest: 26 Msgs - 06/24/06
>
>
> > --> AeroElectric-List message posted by: Ernest Christle y
> >
> >
> > AeroElectric-List Digest Server wrote:
> >
> >>The AI NEVER stabilizes there is a slow tumble until I see either nothing
> >>but sky or ground. NEVER STABILIZING!
> >>
> >>Has anyone ever run across this problem and if so what was the cause and
> >>cure?
> >>
> >>It has been suggested that I perform two (2) operations:
> >>1 - Upgrade the Software from Ver 2.21 to Ver 2.64
> >>2 - Hook up the keyboard and do a Warm System reboot from the keyboard
> >>
> >>What are your thoughts? Does this sound like a cure? Of course the
> >>software upgrade is required and will be done.
> >>
> >>Barry
> >>"Chop'd Liver"
> >>
> >>
> > I work in the software industry as a Quality Assurance Engineer , ie. I
> > test software. I've written a lot of software. I've met a lot of
> > software engineers. I've worked for several software companies.
> > There is a wide range of attitudes when it comes to software.
> >
> > At one end of the spectrum is the companies/engineers that treat software
> > and the requisite hardware as an appliance. The software is tied
> > intimately to the hardware, and a breakage in one signifies a breakage in
> > the other. A breakage in either signifies a breakage in the organization.
> > Code is meticulously maintained, and every last detail of the
> > software/hardware combination is tested as much as humanly possible before
> > shipping to the customer. The engineers tend to be very experienced and
> > 'slow moving'. The code is not expected to break when delivered to QA.
> > The best example I have personal experience with is IBM's mainframe
> > networking division.
> > The other end of the spectrum is what I like to call "The Microsoft
> > Generation". Code is whipped out using long tool chains built on top of
> > libraries written by someone else. I meet lots of these engineers
> > building database frontends to generate reports to management. The
> > criteria for these engineers is that they generate a disposable app
> > quickly and move on to the next project. They are conditioned to value a
> > new glitzy widget over solid engineering. Code unit test is an
> > afterthought at best, and if it does happen it consist of being able to
> > generate a report on a couple sets of data at most. These guys deliver
> > stuff to QA with the idea that the test team will tell them what is wrong
> > with the code. I call it the Microsoft Generation, because that company
> > has bee n the forerunner in preaching that hiring competent, seasoned
> > engineers is uneccessary with their software. Software is complex and
> > should be expected to break, they preach, but their tool set will enable a
> > cheap college grad that works around the clock for Coke and pizza to
> > spit out polished applications to run the enterprise. Widgets, "new
> > features" and just more eye-candy can be added ad nauseum, quickly and
> > easily.
> >
> > The Microsoft Generation is OK for generating reports to management. I'll
> > even abide letting them build a video game or two. But I want real
> > engineers writing any software that I will be letting my butt ride on.
> >
> > I talked to Blue Mountain and Dynon at Sun-n-Fun. The question I had in
> > mind was, "If I were an QA engineer at this company, what would the
> > development team deliver to me for testing?" The Dynon unit booted
> > quickly and showed a simple display. I got the "feel" that the software
> > was written for the hardware, and the hardware was designed for the
> > software. The BMA unit seemed to take forever to boot up, complete with
> > splash screen to keep the user occupied reading copyright information
> > while it did a digital dance behind the scenes. (BTW, a "splash screen"
> > is a red flag that someone from the Microsoft Generation is behind the
> > scenes. How is it helpful, except to show more eye-candy? And copyright?
> > What am I going to do, run the stuff on my PC?) I got the distinct
> > feeling that BMA engineers would expect me to tell them what was wrong
> > with it, while the Dynon folks would only expect me to verify that it
> > works as they designed it.
> >
> > My thoughts? The fact that the BMA is d esigned for "quick upgrades" is a
> > glaring red flag. The thing is a limited function device. It should work
> > out of the box. The in-field "quick upgrade" tells me that BMA is using
> > you as a beta tester. The fact that it doesn't work out of the box tells
> > me that either the hardware or software is broken. Being that this is the
> > real world, I can accept hardware being broken. Things break in
> > shipping...not every IC is tested off the assembly line..etc. But the
> > fact that a 'software fix' is available gives me the thought that the
> > development organization needs a fix.
> >
> > --
> > ,|"|"|, Ernest Christley |
> > ----===<{{(oQo)}}>===---- Dyke Delta Builder |
> > o| d |o http://ernest.isa-geek.org |
>
>
>
>
>
>
> --
> ,|"|"|, Ernest Christley |
> ----===<{{(o Qo)}}>===---- Dyke Delta Builder |
> o| d |o http://ernest.isa-geek.org |
>
> --
> Homepage: http://www.flyrotary.com/
> Archive and UnSub: http://mail.lancaironline.net/lists/flyrotary/