Forums

Good hardware, poor software

Started by bitrex April 16, 2017
The graveyard of audio production equipment is littered with the corpses 
of products that had rock-solid hardware designed by professionals, but 
firmware written by nincompoops.

It's really frustrating when you buy a blinky-light box that some 
engineers somewhere likely spent thousands of man-hours on designing the 
best sounding DAC structure they could for the budget, but then the OS 
crashes when you accidentally try to load a file that's the wrong format.
On 04/16/2017 09:13 AM, bitrex wrote:
> The graveyard of audio production equipment is littered with the corpses > of products that had rock-solid hardware designed by professionals, but > firmware written by nincompoops.
To be clear, what I mean by that is they let EEs write the software.
On Sun, 16 Apr 2017 09:17:36 -0400, bitrex wrote:

> On 04/16/2017 09:13 AM, bitrex wrote: >> The graveyard of audio production equipment is littered with the >> corpses of products that had rock-solid hardware designed by >> professionals, but firmware written by nincompoops. > > To be clear, what I mean by that is they let EEs write the software.
HEY! There's a lot of profoundly good embedded software engineers out there with EE degrees. -- Tim Wescott Control systems, embedded software and circuit design I'm looking for work! See my website if you're interested http://www.wescottdesign.com
On Sun, 16 Apr 2017 09:13:39 -0400, bitrex wrote:

> The graveyard of audio production equipment is littered with the corpses > of products that had rock-solid hardware designed by professionals, but > firmware written by nincompoops. > > It's really frustrating when you buy a blinky-light box that some > engineers somewhere likely spent thousands of man-hours on designing the > best sounding DAC structure they could for the budget, but then the OS > crashes when you accidentally try to load a file that's the wrong > format.
Imagine how frustrating it is for the folks who know how to do it right but are blocked by management, on pain of firing, to do the up-front work before jumping into coding and debug. Particularly when you know that every up-front hour spent shortens the debug time by at least two hours. -- Tim Wescott Control systems, embedded software and circuit design I'm looking for work! See my website if you're interested http://www.wescottdesign.com
On 4/16/2017 10:25 AM, Tim Wescott wrote:
> On Sun, 16 Apr 2017 09:17:36 -0400, bitrex wrote: > >> On 04/16/2017 09:13 AM, bitrex wrote: >>> The graveyard of audio production equipment is littered with the >>> corpses of products that had rock-solid hardware designed by >>> professionals, but firmware written by nincompoops. >> >> To be clear, what I mean by that is they let EEs write the software. > > HEY! There's a lot of profoundly good embedded software engineers out > there with EE degrees.
Some are even Chinese! -- Rick C
On 4/16/2017 10:27 AM, Tim Wescott wrote:
> On Sun, 16 Apr 2017 09:13:39 -0400, bitrex wrote: > >> The graveyard of audio production equipment is littered with the corpses >> of products that had rock-solid hardware designed by professionals, but >> firmware written by nincompoops. >> >> It's really frustrating when you buy a blinky-light box that some >> engineers somewhere likely spent thousands of man-hours on designing the >> best sounding DAC structure they could for the budget, but then the OS >> crashes when you accidentally try to load a file that's the wrong >> format. > > Imagine how frustrating it is for the folks who know how to do it right > but are blocked by management, on pain of firing, to do the up-front work > before jumping into coding and debug. Particularly when you know that > every up-front hour spent shortens the debug time by at least two hours.
First hand experience or do you just like making up straw boogeymen? -- Rick C
On 04/16/2017 10:27 AM, Tim Wescott wrote:
> On Sun, 16 Apr 2017 09:13:39 -0400, bitrex wrote: > >> The graveyard of audio production equipment is littered with the corpses >> of products that had rock-solid hardware designed by professionals, but >> firmware written by nincompoops. >> >> It's really frustrating when you buy a blinky-light box that some >> engineers somewhere likely spent thousands of man-hours on designing the >> best sounding DAC structure they could for the budget, but then the OS >> crashes when you accidentally try to load a file that's the wrong >> format. > > Imagine how frustrating it is for the folks who know how to do it right > but are blocked by management, on pain of firing, to do the up-front work > before jumping into coding and debug. Particularly when you know that > every up-front hour spent shortens the debug time by at least two hours. >
I hear that. I also think designing say a "computer-DAC" box is not an "easier" task than writing the firmware, exactly, but maybe a more "bounded domain." In some sense one computer-DAC-audio-box is a lot like any other, the specifics may vary but the solution will likely take a form that is reminiscent of similar things. But for the software, does the codebase for say Cubase really resemble the codebase for Cakewalk? Likely not very much, even though they both are pieces of software that at the end of the day are used for the exact same thing.
On 04/16/2017 10:25 AM, Tim Wescott wrote:
> On Sun, 16 Apr 2017 09:17:36 -0400, bitrex wrote: > >> On 04/16/2017 09:13 AM, bitrex wrote: >>> The graveyard of audio production equipment is littered with the >>> corpses of products that had rock-solid hardware designed by >>> professionals, but firmware written by nincompoops. >> >> To be clear, what I mean by that is they let EEs write the software. > > HEY! There's a lot of profoundly good embedded software engineers out > there with EE degrees. >
They sometimes seem scared of newfangled stuff like OOP, "design patterns", "test-driven development", and "agile development." It's okay. It's really not that scary! You don't even have to be afraid of all that "inheritance" and endless class hierarchy stuff, it's not 1993 and nobody gets paid by number of classes derived from anymore.
On 4/16/2017 6:13 AM, bitrex wrote:
> The graveyard of audio production equipment is littered with the corpses of > products that had rock-solid hardware designed by professionals, but firmware > written by nincompoops.
That's true of many application domains.
> It's really frustrating when you buy a blinky-light box that some engineers > somewhere likely spent thousands of man-hours on designing the best sounding > DAC structure they could for the budget, but then the OS crashes when you > accidentally try to load a file that's the wrong format.
Because most (naive) developers seem to "test" by throwing things that *should* work at the code and verifying that they *do*, in fact, work -- instead of throwing things that *don't* work (i.e., bad file formats, out-of-bounds parameters, etc.) and verifying proper handling of those conditions. A colleague had *just* proclaimed that he had "finished" the software for his product (process control gear for pharma -- a "picky" market!). I reached over his shoulder and pressed a few keys... and watched the system crash! "What did you *do*??!!" "I typed <whatever>" "But, you're not supposed to *do* that!" "Then why did YOU *let* me?!" Most folks struggle to make something work. So, the "inputs" they throw at it are designed to be correct -- to see why their code *isn't* getting executed as they expect. It's a different mindset to simultaneously be throwing "bad" inputs at the code to verify *they* are handled "appropriately". Like back-driving a power supply to verify that it remains stable when its output is "forced" to the wrong levels. Or, that it "behaves" when operated at 110C ambient (you can't just slap a label on software declaring "maximum operating conditions"; it has to *behave* even when those are exceeded! A power supply can fail miserably when operated outside its nameplate ratings and no one worries: "Of *course* it won't work at -120C!")
On 4/16/2017 6:17 AM, bitrex wrote:
> On 04/16/2017 09:13 AM, bitrex wrote: >> The graveyard of audio production equipment is littered with the corpses >> of products that had rock-solid hardware designed by professionals, but >> firmware written by nincompoops. > > To be clear, what I mean by that is they let EEs write the software.
When I was in school, CS was taught *in* the school of EE. As an EE, you learned how to design power supplies AND design programming languages. But, folks opting for the "classic" EE curriculum would spend far more effort in the former while folks opting for the CS focus spent more in the latter. [In my case, I was interested in computer *hardware* so had to flip a coin as to which focus to pursue]