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
Message
Development thoughts [was Ken Elhardt's Patchbook Series]
2006-07-15 by Greg James
Attachments
- No local attachments were found for this message.