Forums

Good hardware, poor software

Started by bitrex April 16, 2017
On 17/04/17 11:56, bitrex wrote:
> On 04/16/2017 07:00 PM, Lasse Langwadt Christensen wrote: >> Den sø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 >> > > There are probably four or five languages that came out in the past decade that > have as their "mission statement" something like "To develop a language which > has the ease of use, expressiveness, and safety of an interpreted language, and > the execution speed of a compiled language." > > People still use C++ a lot...
There is a fad cycle. People don't like strongly typed languages because they are "too constraining" and "too verbose". So they invent yet another more-or-less untyped language. They then find that they've lost the ability to: - inspect and draw solid conclusions about other people's codebase - use code-completion to speed typing and avoid mistakes - detect errors at compile time; they have to hope they can detect them at run time before their customers detect them So then they realise the benefits of strongly typed languages, and swap to the latest variant thereof. Unfortunately by that age, the HR-droids think they are "past sell by date" and so they are shunted into middle-management positions or the dole queue.
On Sun, 16 Apr 2017 10:43:05 -0400, rickman wrote:

> 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?
First-hand experience. "Tell us you'll get it done by this date, with these resources, or you're fired." To be fair, I've seen quality efforts shot down at every level in the pipeline -- but it's management's job to understand what it takes to make the next level down care about quality, and what it takes to at least give them room to deliver it. -- 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/17/2017 8:52 AM, Tim Wescott wrote:
> First-hand experience. "Tell us you'll get it done by this date, with > these resources, or you're fired." > > To be fair, I've seen quality efforts shot down at every level in the > pipeline -- but it's management's job to understand what it takes to make > the next level down care about quality, and what it takes to at least > give them room to deliver it.
When "reward" is tied to the WRONG "results" metric, its too hard to get PHB's to make the "right" decisions. I watched a *system* (7 figures) shipped off to the customer AS A BOX FULL OF UNASSEMBLED PARTS (nor was the system completely *designed* at time of delivery) -- just so the boss could collect his bonus and promotion (leaving the next guy to take the hit -- reputation and "on the books" -- when the client shipped the box-full-of-parts back, outraged!)
On 17/04/17 20:17, Don Y wrote:
> On 4/17/2017 8:52 AM, Tim Wescott wrote: >> First-hand experience. "Tell us you'll get it done by this date, with >> these resources, or you're fired." >> >> To be fair, I've seen quality efforts shot down at every level in the >> pipeline -- but it's management's job to understand what it takes to make >> the next level down care about quality, and what it takes to at least >> give them room to deliver it. > > When "reward" is tied to the WRONG "results" metric, its too hard to > get PHB's to make the "right" decisions. > > I watched a *system* (7 figures) shipped off to the customer AS A BOX > FULL OF UNASSEMBLED PARTS (nor was the system completely *designed* at > time of delivery) -- just so the boss could collect his bonus and > promotion (leaving the next guy to take the hit -- reputation > and "on the books" -- when the client shipped the box-full-of-parts > back, outraged!)
Contrariwise, I've heard tales of customers /asking/ suppliers to ship them empty boxes. Why? Shipped at the end of the financial year so as to use up a pot of gold, supplier corrected the "omission" at their normal lead time :) Much like HP describing its desktop computers as "calculators", so as not to invoke customers' IT department's immune system response.
On 04/17/2017 08:47 AM, Tom Gardner wrote:
> On 17/04/17 11:56, bitrex wrote: >> On 04/16/2017 07:00 PM, Lasse Langwadt Christensen wrote: >>> Den sø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 >>> >> >> There are probably four or five languages that came out in the past >> decade that >> have as their "mission statement" something like "To develop a >> language which >> has the ease of use, expressiveness, and safety of an interpreted >> language, and >> the execution speed of a compiled language." >> >> People still use C++ a lot... > > There is a fad cycle. > > People don't like strongly typed languages because > they are "too constraining" and "too verbose". So > they invent yet another more-or-less untyped language. > > They then find that they've lost the ability to: > - inspect and draw solid conclusions about other > people's codebase > - use code-completion to speed typing and avoid > mistakes > - detect errors at compile time; they have to hope > they can detect them at run time before their > customers detect them > So then they realise the benefits of strongly typed > languages, and swap to the latest variant thereof.
the "auto" automatic type deduction keyword available in C++11 onwards helps cut down on the verbosity a lot; I use it wherever possible, in C++14 it's even available for use to automatically deduce function return types. In general: <https://arne-mertz.de/2016/11/stronger-types/> Use stronger types. It should be inherently impossible to have -27000 pieces of gold, or be 34.73 years old, because C++ makes it easy enough to create a near-zero-overhead abstractions of quantities that reject the possibility, ideally with a compile-time error. I think on a modern desktop environment at least there's little reason to use any underlying fundamental data types other than int32_t, int64_t, double, and std::string. "What if the character gets really rich though, and int32_t would overflow?" Simple, don't put that much money in the game, it means the game's economy is broken. Or at least put a limit on how much can be stored in one place. Avoiding errors like that should be partly a design decision from the start, not just an implementation problem.
On 4/17/2017 1:00 PM, Tom Gardner wrote:
> On 17/04/17 20:17, Don Y wrote: >> On 4/17/2017 8:52 AM, Tim Wescott wrote: >>> First-hand experience. "Tell us you'll get it done by this date, with >>> these resources, or you're fired." >>> >>> To be fair, I've seen quality efforts shot down at every level in the >>> pipeline -- but it's management's job to understand what it takes to make >>> the next level down care about quality, and what it takes to at least >>> give them room to deliver it. >> >> When "reward" is tied to the WRONG "results" metric, its too hard to >> get PHB's to make the "right" decisions. >> >> I watched a *system* (7 figures) shipped off to the customer AS A BOX >> FULL OF UNASSEMBLED PARTS (nor was the system completely *designed* at >> time of delivery) -- just so the boss could collect his bonus and >> promotion (leaving the next guy to take the hit -- reputation >> and "on the books" -- when the client shipped the box-full-of-parts >> back, outraged!) > > Contrariwise, I've heard tales of customers /asking/ suppliers > to ship them empty boxes. > > Why? Shipped at the end of the financial year so as to use up > a pot of gold, supplier corrected the "omission" at their normal > lead time :)
But, there, "everybody" wins; The Next Guy doesn't get left holding the bag so the previous guy could profit!
> Much like HP describing its desktop computers as "calculators", > so as not to invoke customers' IT department's immune system > response.
Or, calling the suspicious looking (XRay) device in your toolkit an "electric wire-wrapping tool" to avoid the attention of the security folks at the airport...
On 4/17/2017 5:47 AM, Tom Gardner wrote:
> People don't like strongly typed languages because > they are "too constraining" and "too verbose". So > they invent yet another more-or-less untyped language. > > They then find that they've lost the ability to: > - inspect and draw solid conclusions about other > people's codebase > - use code-completion to speed typing and avoid > mistakes > - detect errors at compile time; they have to hope > they can detect them at run time before their > customers detect them
(gasp!) You're talking about obsoleting that whole "after sale test" department!! Imagine what you'll do to the unemployment rate!
> So then they realise the benefits of strongly typed > languages, and swap to the latest variant thereof.
If you find type enforcement getting in the way of what you're trying to do, you should be rethinking exactly what it *is* that you're trying to do! Even when working with bare metal, there is usually *some* "alternate model" that you can apply to the "devices" to make them fit into the language's notion of the types that it supports. The syntax may get clumsy, but... And, you should be abstracting away these issues with utmost haste -- so, few people OTHER than you should ever be aware of them!
> Unfortunately by that age, the HR-droids think they > are "past sell by date" and so they are shunted into > middle-management positions or the dole queue.
On 4/17/2017 2:03 PM, Don Y wrote:
> If you find type enforcement getting in the way of what > you're trying to do, you should be rethinking exactly what > it *is* that you're trying to do! Even when working with > bare metal, there is usually *some* "alternate model" that > you can apply to the "devices" to make them fit into the > language's notion of the types that it supports. The > syntax may get clumsy, but...
E.g., in my current environment, I'd *really* benefit from a syntax like: thing=>method or thing=>member (note: NOT '->') but languages don't support that additional level of indirection :<
On 04/17/2017 04:56 PM, Don Y wrote:

> Or, calling the suspicious looking (XRay) device in your toolkit > an "electric wire-wrapping tool" to avoid the attention of the security > folks at the airport...
I shipped a client of mine a quick one-off prototype last year, built on through-hole protoboard. The USPS took it. Shipped the guy an empty box. They really did! They sent it along with a "damaged in shipping" form letter. The box was pristine and had been neatly opened from the flap with the contents removed. I guess someone does watch the X-ray machines they use.
On 17/04/17 20:00, Tom Gardner wrote:
> And at that point TDD has turned the codebase into concrete.
No. Poor coding practices has done that. Whether by people who espouse TDD or not, that'll always kill you.