Archive of the former Yahoo!Groups mailing list: MOTM

previous by date index next by date
previous in topic topic list  

Subject: Development thoughts [was Ken Elhardt's Patchbook Series]

From: "Greg James" <gjames@...>
Date: 2006-07-15

I guess I have to put my 2(00) cents in, here:

If it were ∗A∗ professional programmer, you wouldn't have these problems. In
my experience (25+ years), commercial software suffers from poor management
as Jason suggests. To answer Ken's question (which he indirectly answered
himself), these kinds of problems hit the street because managers:

- Still haven't learned about scope creep
- Can't manage large(r) project teams and projects
- Refuse to acknowledge the reality of testing and QA
- Are generally ignorant about what it takes to produce code

Ken, your code was clean because you did it all: wrote the entire program,
tested it, and perhaps even spec'd and designed it. You also had something
else that a lot of programmers unfortunately do not: a good grasp of the
problem being solved. When software deliverables are split up amongst a
bunch of analysts, programmers, and if your lucky, a QA/testing person, the
project is glued together by a manager or committee who are administrators,
not software developers or users of their product, they are put under
artificial pressure before they've even started, it's a recipe for bugs.

There's always good and bad (_______) fill in the blank (programmers,
project managers, ...). It doesn't surprise me that Ken's code is virtually
bug free. Knowing his synth programming skills and attention to detail, I
believe his claim without a doubt.

To offer an example and bring this thread back on topic: Let's look at
Paul's
foray into software with MOTM:

- How long have we been waiting for the 650?

Paul clearly understands the product. There are, what, 2 maybe 3 people
involved with it's development (I'm guessing from what I've read in Paul's
posts). Paul has made a concerted effort to alpha and beta test. And guess
what, many of us are still waiting. Why? Because Paul is also the manager
and he's got a clear idea of the acceptable quality the product must have
and he's decided what other priorities will impact the schedule (Fraq
format,
running MOTM operations, dealing with business disruptions, ...).

I get the sense that most of us are here because of the quality. If that's
the case, then our loyalty agrees with Paul to the extent that he makes
decisions that do not compromise quality. That's part of the price we pay
to do business with him.

Unfortunately, way too much commercial software isn't developed with quality
as the uncompromised attribute. Cost and ship date have always won out in my
experience.

Now I'd like to weigh-in on the new Audio Engine direction, since MOTM is
taking a path straight into major software territory. Here's some questions
for Paul which he may or may not choose to answer, but they are what's on my
mind:

- What happens to all of this if the Xilinx guru gets hit by a bus? And as
we painfully know in MOTM-land, it's already happened to some extent.

- These modules are going to be software black boxes. With the circuit-based
modules, I have a reasonable chance of fixing something if it wonks-out. The
Audio Engines sound like they're going to be throw-aways if something goes
wrong, especially in or around the chip. This is true for many of us
regarding
SMT, too. Maintainability in the field has been an unsung attribute of MOTM
gear thus far.

- What's going to happen when someone like Ken finds a niggle in the code,
but 80-90% of the rest of us don't really need that or care? Is the firmware
going to be updated anyway? Or will time and effort (cost) mean that Ken or
whomever just has to live with the shortcoming? Remember - the end user will
not be able to mod or patch these things themselves like many have done with
the hardware-based modules.

- No design can do it all. All modules have their "sweet spot." At the end
of the day, I'm curious about how the Audio Engine modules will sound. MOTM
today means quality in construction and sound. Paul (and Jeurgen, and other
collaborators) has been nothing short of brilliant in bringing MOTM to us.
But this is new territory. I'm not thinking too much about this one because
of Paul's track record, but you never know.

OK, sorry for the essay on Saturday morning, and I appreciate anyone who had
the patience to get here.

Paul: I'm still a happy customer (but not happy about losing the kits)

Jeurgen: I listen to your CDs a lot, and one of these days I'll write you
about them. To all others - If you like very interesting, atmospheric music,
check JH's CDs out. I bought the whole set and am not disappointed.

Ken: May you not encounter what I described above with the new modules. And
thanks again for turning me on to the great deal for Arturia's Moog Modular
software.

-Greg