Forums

Good hardware, poor software

Started by bitrex April 16, 2017
On 17/04/17 23:26, Clifford Heath wrote:
> 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.
Yes and no. TDD certainly enables such ossification, and - arguably - encourages it. The problem is that some people don't realise the dysfunctional aspects of TDD, and do take the necessary steps to avoid them. It is the same with any other technique, of course. "Against stupidity the gods themselves contend in vain." The problem is that fools are so damn ingenious!
On Mon, 17 Apr 2017 08:38:01 +0100, Tom Gardner wrote:

> On 17/04/17 00:53, Clifford Heath wrote: >> On 17/04/17 08:36, 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". >> >> That's not what TDD does. >> >> A well-written specification should be written like code, and it should >> be machine-processable (to be run as a test suite). That's what TDD >> does. >> >> As you write the specification, you *test* each part by implementing >> it. If you ever find yourself implementing anything that's not >> specified, you're no longer doing TDD. >> If you find yourself specifying something that cannot be tested, you're >> no longer doing TDD. >> >> It's all very easy to criticize cowboy coders, but how do you write >> design specifications? How do you know that the spec is (a) correct and >> (b) implementable? >> >> Very few people are willing to accept the discipline that TDD actually >> demands. They might say they're doing TDD, but they're often breaking >> the rules. > > As you get around to implying, TDD is like fracking: safe *when done > properly*. > > The relevant questions are: > - do the people using the tool understand the > theory behind it > - is the specific task somewhere where the tool > can be used safely > - are the people given sufficient resources to > use the tool safely > - are the individuals capable of doing it > properly > > Too many times I've seen people emphatically state "there's a green > light so it works"!
That applies to any formal design methodology, and not just in the software field.
> Too many times I've seen unit tests that aren't failable!
Then those unit tests are broken. When I do TDD for myself, I first write a test that tests for non-existent features, to verify that it fails (i.e., I test the test). THEN I add the features to the code base that I'm working on.
> Too many times I've seen unit tests that serve *only* to test irrelevant > implementation details, thus freezing the codebase!
Again, broken unit tests...
> TDD is better than some alternative testing regimes, but it is not the > panacea claimed by some zealots.
As with all other design methodologies, including "I just do it inherently right because I'm a manly man!" -- Tim Wescott Wescott Design Services http://www.wescottdesign.com I'm looking for work -- see my website!
On 4/17/2017 11:52 AM, Tim Wescott wrote:
> 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."
This is *nothing* like what you said before, "do the up-front work before jumping into coding and debug." Deadlines are imposed by various factors, methods are hard to dictate. -- Rick C
On Mon, 17 Apr 2017 21:00:19 +0100, Tom Gardner
<spamjunk@blueyonder.co.uk> 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 :)
Of course. We used to do it all the time in IBM. At the end of the quarter and particularly in December, trucks lined up all around the property to get the product out in that quarter. Tax laws are nuts.
> >Much like HP describing its desktop computers as "calculators", >so as not to invoke customers' IT department's immune system >response.
Yep. We used to buy complete boards to scavenge microprocessors because we were proscribed from buying them. PHBs can be nuts.
On 04/16/2017 07:51 AM, bitrex wrote:
> 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.
It's not so much "scared of", but the suspicion that the new emperor has no better clothes than the old emperor.. :-)
On 4/17/2017 6:21 PM, Bill Martin wrote:
> On 04/16/2017 07:51 AM, bitrex wrote: >> 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. > > It's not so much "scared of", but the suspicion that the new emperor has no > better clothes than the old emperor.. :-)
The analogy *almost* fits. I think it *doesn't* fit when applied to things like OOP vs. procedural approaches. There's a definite distinction in how you think about problems (i.e., *solutions*) in the two approaches. And, while duality lets you (theoretically) transform an approach from one solution space to the other, it is impractical. OTOH, I *do* think the analogy is appropriate when it comes to the "how to" methodologies that try to improve quality, reliability, efficiency, etc. with a single idea that inevitably gets distilled to a terse mantra. Just like "don't run with scissors", it ignores a whole set of details that can (and do!) make a big difference in outcomes.
On 04/17/2017 07:16 PM, Don Y wrote:
> On 4/17/2017 6:21 PM, Bill Martin wrote: >> On 04/16/2017 07:51 AM, bitrex wrote: >>> 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. >> >> It's not so much "scared of", but the suspicion that the new emperor >> has no >> better clothes than the old emperor.. :-) > > The analogy *almost* fits. > > I think it *doesn't* fit when applied to things like OOP vs. procedural > approaches. There's a definite distinction in how you think about > problems (i.e., *solutions*) in the two approaches. And, while duality > lets you (theoretically) transform an approach from one solution > space to the other, it is impractical. > > OTOH, I *do* think the analogy is appropriate when it comes to the "how to" > methodologies that try to improve quality, reliability, efficiency, etc. > with a single idea that inevitably gets distilled to a terse mantra. Just > like "don't run with scissors", it ignores a whole set of details that > can (and do!) make a big difference in outcomes.
Well, the new can be better than the old, but I still recall when Pascal was gonna save us from ourselves...that's really the sticking point, "save us from our selves". Doesn't work, our selves can be just as stupid in a constrained grammar as in assembly code... :-( And damned ingenious in finding new ways to "beat the system"!
On 18/04/17 08:35, Tom Gardner wrote:
> On 17/04/17 23:26, Clifford Heath wrote: >> 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. > > TDD certainly enables such ossification, and - arguably - encourages it.
The worst ossification I've ever seen was before TDD was a thing, and would have simply not been a problem had the system in question been designed using TDD. In this project, 10 minutes of engineering which would have delivered high value to almost every customer was deemed impossible because it would have required 3 months to rework the test results.
> ...people don't realise the dysfunctional aspects of TDD...
People don't realise the dysfunctional aspects of humans. I'm sorry that you've had a bad experience, but my experience is the opposite. The folk I know who use TDD are annoyingly religious about clean and minimal code, including in their tests. They're all about rapid mutability of their implementations, and I've never seen such an app get ossified in the way you say. I have seen that repeatedly with non-TDD apps, even to a ridiculous degree. I've also seen apps that are woefully undertested and buggy. Between these three approaches (spanning a 35 year career as architect of major enterprise software products), TDD yielded the best overall results; balancing rapid release schedules with overall quality. Clifford Heath.
On 4/17/2017 7:47 PM, Bill Martin wrote:
> On 04/17/2017 07:16 PM, Don Y wrote: >> On 4/17/2017 6:21 PM, Bill Martin wrote: >>> On 04/16/2017 07:51 AM, bitrex wrote: >>>> 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. >>> >>> It's not so much "scared of", but the suspicion that the new emperor >>> has no >>> better clothes than the old emperor.. :-) >> >> The analogy *almost* fits. >> >> I think it *doesn't* fit when applied to things like OOP vs. procedural >> approaches. There's a definite distinction in how you think about >> problems (i.e., *solutions*) in the two approaches. And, while duality >> lets you (theoretically) transform an approach from one solution >> space to the other, it is impractical. >> >> OTOH, I *do* think the analogy is appropriate when it comes to the "how to" >> methodologies that try to improve quality, reliability, efficiency, etc. >> with a single idea that inevitably gets distilled to a terse mantra. Just >> like "don't run with scissors", it ignores a whole set of details that >> can (and do!) make a big difference in outcomes. > > Well, the new can be better than the old, but I still recall when Pascal was > gonna save us from ourselves...that's really the sticking point, "save us from > our selves". Doesn't work, our selves can be just as stupid in a constrained > grammar as in assembly code... :-( And damned ingenious in finding new ways to > "beat the system"!
The problem is when people get the mindset: "ALL you need to do, is..." They distill an idea down to a philosophy and think their problems magically go away. As if the idea/philosophy could replace original thought. (if it was THAT mechanical, why not eliminate the human and let an algorithm design the product, write the code, etc.? :> ) Even something as mundane as digging a ditch requires the presence of a critical intellect!
On 18/04/17 04:04, Clifford Heath wrote:
> On 18/04/17 08:35, Tom Gardner wrote: >> On 17/04/17 23:26, Clifford Heath wrote: >>> 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. >> >> TDD certainly enables such ossification, and - arguably - encourages it. > > The worst ossification I've ever seen was before TDD was a thing, > and would have simply not been a problem had the system in question > been designed using TDD. > > In this project, 10 minutes of engineering which would have delivered > high value to almost every customer was deemed impossible because > it would have required 3 months to rework the test results. > >> ...people don't realise the dysfunctional aspects of TDD... > > People don't realise the dysfunctional aspects of humans. > > I'm sorry that you've had a bad experience, but my experience is > the opposite. The folk I know who use TDD are annoyingly religious > about clean and minimal code, including in their tests. They're > all about rapid mutability of their implementations, and I've > never seen such an app get ossified in the way you say. I have > seen that repeatedly with non-TDD apps, even to a ridiculous degree. > I've also seen apps that are woefully undertested and buggy. > > Between these three approaches (spanning a 35 year career as architect > of major enterprise software products), TDD yielded the best overall > results; balancing rapid release schedules with overall quality.
I think I have fostered a misapprehension. Used appropriately TDD is indeed a very powerful technique. I like TDD. I have been using TDD for decades, since the early 80s in fact. I've used it for both hard and soft realtime software, semi-custom ASICs, FPGAs and other hardware. I've caused TDD to be introduced to companies where it was an improvement on the previous techniques. Unfortunately I've also seen programmers use it inappropriately, in a way that made me think of "cargo-cult programming" and "religious dogma".