Forums

Good hardware, poor software

Started by bitrex April 16, 2017
On Sunday, April 16, 2017 at 1:25:10 PM UTC-4, Don Y wrote:

> 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". >
My pet peeve is web sites that have help sections for all the things that the programmer can think of going wrong, and no option for contacting anyone about something that they did not think of. Dan
On 4/16/2017 7:46 AM, bitrex wrote:
> 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.
It is relatively easy to write a specification that defines the hardware's capabilities. Then, hand that off to someone who can implement it without further contact with the-powers-that-be. And, easy to *verify* compliance to that specification. Wanna *bet* there was no similarly detailed specification written for the software? Wanna bet the "coder" probably decided what the "program" should do, what the user interface should look like, etc.? Early on, I opted for fixed cost contracts (instead of T&M) as it gave me a lot more freedom in what I did, how I did it, etc. But, the best aspect was that it forced the client to produce a clean definition of what he wanted/expected -- because that was how we would jointly agree that the contract's terms had been met! When hammering out details of the "final" spec (always amusing how quickly the client considered the spec "finished" vs. how many holes remained in it!), I would invariably ask the client, "What do you want to happen when <whatever> occurs?" "I don't care" was a common reply. Of course, what he meant was "I don't know and I don't want to think about it!" Of course, *I* know that whatever *I* decide should happen in that situation could easily be considered "wrong" by him when it comes time for sign-off... so, I *do* care about what is written down as the "contractually agreed upon" way of handling that situation. I would very deliberately and seriously comment, /sotto voce/ "When <whatever> happens, the device should catch fire/crash/explode/etc..." Client would heat this (cuz I intended for him to hear it!) and exclaim, "THAT'S not what I want!!" "Ah, so you *do* care! ..." Would you sign a contract with a home builder agreeing to a price and delivery date -- but NOT to a detailed description of the structure he was setting out to build? Conversely, would you sign that contract with the home *buyer* without all those details present?
On 4/16/2017 10:36 AM, dcaster@krl.org wrote:
> On Sunday, April 16, 2017 at 1:25:10 PM UTC-4, Don Y wrote: > >> 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". > > My pet peeve is web sites that have help sections for all the things that > the programmer can think of going wrong, and no option for contacting anyone > about something that they did not think of.
Or, that contain *errors*! To be fair, its hard to imagine the numerous ways things can deviate from "intended". This is especially true for "processes" that the developer considers as sequential: do this, THEN this, and finally THAT! The *user* may not see the process as taking the same sequence that the developer envisioned: "I don't feel like filling in line 1 before line 2..." The developer followed an unspoken set of rules in how he designed the program/product. Then, neglected to *codify* those rules in the places where their order was inherently relied upon by *his* code! "Ah! You didn't fill in the gallons-of-fuel, yet! So, the code is dividing the miles-traveled figure that you specified on line 2 by the gallons-of-fuel (which it sees as '0' due to being blank) and, thus, crashing when it computes MPG!" I have a "gesture recognizer" in my current design (think of gestures as "buttons" so the application can dynamically map specific gestures to specific commands/actions/responses). Of course, there is a lot of variability between users (and uses!) for the set of gestures supported -- in much the same way that penmanship varies from one user to another ("Is that a '4' or a '9'?"). So, it would be silly to force users to conform to a template for each individual gesture; you'd end up frustrating them by a high number of rejected actions. Instead, I adapt my models for each gesture to reflect what I observe from the user ("OK, I considered THAT to be a '4', and not a '9', and he appears to have agreed with my assessment as he didn't hit the UNDO button immediately afterwards. So I'll tweak my model for '4' to make it resemble the actual gesture that he 'issued' so the next time he does that, there will be a tighter fit with my model"). But, in accommodating the user, in this way, I run the risk of being crippled by his failure to differentiate similar gestures! I.e., his '9' and '4', if *too* similar, will cause *my* models for '9' and '4' to tend to converge. This will lead to an increase in the MISrecognition rate. There can come a time when he simply can't generate a gesture that he has high confidence that I will recognize as '4' vs. '9'! And, once that has happened, how do we get the models to *diverge*?? Add a "reset models" command?? So, in addition to adapting models to better agree with the user's particular "gesturing style", I *also* have to analyze those models to ensure the user's style doesn't lead to a situation where my recognizer can't work as intended; there comes a time when you have to force the *user* to comply with CONSTRAINED models and not the other way around. [Failing to realize this possibility AT DESIGN TIME could have lead to a really lousy implementation! "Is that an 'l' or a '1'? 'O' or '0'? 'V' or '>' (or '<')?"]
On 04/16/2017 01:44 PM, Don Y wrote:

> Would you sign a contract with a home builder agreeing to a price > and delivery date -- but NOT to a detailed description of the structure > he was setting out to build? Conversely, would you sign that contract > with the home *buyer* without all those details present?
The problem is that since software implementations are ideally straightforward to modify, it's an expectation that it's possible to request modifications during the development process. It's part of the reason that we use software to accomplish tasks in the first place. <https://en.wikipedia.org/wiki/Agile_software_development> The requirements are expected to evolve during the development process; indeed a client may not even know exactly what their requirements are until they see a partially working product of some type. At least the pure version of "waterfall" design like you might do with hardware isn't really possible anymore with complex pieces of software.
On 04/16/2017 01:25 PM, Don Y wrote:
> 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.
<https://en.wikipedia.org/wiki/Test-driven_development#/media/File:TDD_Global_Lifecycle.png>
On 4/16/2017 11:34 AM, bitrex wrote:
> On 04/16/2017 01:44 PM, Don Y wrote: > >> Would you sign a contract with a home builder agreeing to a price >> and delivery date -- but NOT to a detailed description of the structure >> he was setting out to build? Conversely, would you sign that contract >> with the home *buyer* without all those details present? > > The problem is that since software implementations are ideally straightforward > to modify, it's an expectation that it's possible to request modifications > during the development process. It's part of the reason that we use software to > accomplish tasks in the first place. > > <https://en.wikipedia.org/wiki/Agile_software_development> > > The requirements are expected to evolve during the development process; indeed > a client may not even know exactly what their requirements are until they see a > partially working product of some type. > > At least the pure version of "waterfall" design like you might do with hardware > isn't really possible anymore with complex pieces of software.
Space shuttle? Medical Instruments? Military? Gaming?
On Sun, 16 Apr 2017 10:32:02 -0700, Don Y
<blockedofcourse@foo.invalid> wrote:

>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.
WHen I was in school, Computer Engineering was in the EE department of the College of Engineering. CS was in the LAS (liberal arts and sciences) college[*]. It may even have been in the math department but I don't remember when that changed. But CompE and CS were entirely different things. [*] A few years before, when my brother was in EE school, CS was in the graduate college. There was no such thing as a BS CS.
>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]
I took an EE degree but took all of the classes needed for CompE, so I could claim either.
On 16/04/17 19:36, bitrex wrote:
> On 04/16/2017 01:25 PM, Don Y wrote: >> 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. > > <https://en.wikipedia.org/wiki/Test-driven_development#/media/File:TDD_Global_Lifecycle.png>
One of the major changes since I started engineering is that it is no longer deemed necessary to design software. Nowadays it is possible to "test quality into products". Or not.
On 4/16/2017 3:36 PM, Tom Gardner wrote:
> On 16/04/17 19:36, bitrex wrote: >> On 04/16/2017 01:25 PM, Don Y wrote: >>> 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. >> >> <https://en.wikipedia.org/wiki/Test-driven_development#/media/File:TDD_Global_Lifecycle.png> > > One of the major changes since I started engineering > is that it is no longer deemed necessary to design > software. Nowadays it is possible to "test quality > into products". > > Or not.
The latter. If you don't know what the hell you're *building* (cuz you skipped the DESIGN stage), how can you test to be sure you've GOT what you WANTED?? "I don't know where I'm going -- but, I'll *know* when I /get there/!"
Den s&oslash;ndag den 16. april 2017 kl. 16.51.46 UTC+2 skrev bitrex:
> 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."
there is also the opposite, where using the latest greatest half done pre-alpha languages, libraries, tools and buzz word development models they only understand half of gets priority over making stuff that actually works