The Embedded Muse 329

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Just found this in J.Ganssles Embedded Muse:
<http://www.ganssle.com/tem/tem329.html

"Without requirements and design, programming is the art of adding bugs to  
an empty text file." - Louis Srygley

--  
Reinhardt


Re: The Embedded Muse 329
Quoted text here. Click to load it

ditto

Been some good ones recently like

"Don't comment bad code - rewrite it." - Brian W. Kernighan

--  
Paul Carpenter          | snipped-for-privacy@pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/ PC Services
We've slightly trimmed the long signature. Click to see the full one.
Re: The Embedded Muse 329
On Mon, 15 May 2017 23:59:02 +0800, Reinhardt Behm wrote:

Quoted text here. Click to load it

:)

All too true.

--  

Tim Wescott
Wescott Design Services
We've slightly trimmed the long signature. Click to see the full one.
Re: The Embedded Muse 329
On 2017-05-15 1:31 PM, Tim Wescott wrote:
Quoted text here. Click to load it
This is timely. I am trying to explain to a bunch of investors in terms
they understand why a disciplined development process is essential for
their client to stop from missing product release deadlines. The problem
with the line is, I would need to start by explaining what a "bug" is.

Over the years as we all have here been faced with speaking and entirely
different language to those who grease development and make it possible.

Explained that quadrupling the number of people on the project was
probably going to hurt more than it helps in this case with. "Nine
ladies cannot have a baby in one month".

w..

Re: The Embedded Muse 329
On 5/17/2017 10:26 AM, Walter Banks wrote:

Quoted text here. Click to load it

Then don't.  I don't need to know what all of the possible negative
outcomes of an upcoming surgery might be -- they are probably innumerable
*if* the surgeon wanted to be exhaustive in his disclosure ("The
anesthesiologist may suffer a stroke while monitoring your sedation level
and fail to control it properly...")

I like to either learn (or know, a priori) enough about the client/customer's
"business" that I can present hypotheticals to which he can relate; or,
present some "simple problem" that he *thinks* he understands (and ask him
to solve it -- while systematically poking holes in his incremental
solution(s)); or, have him present some simple problem to *me* (perhaps
from his application domain) and deliberately fumble my implementation of
his problem presentation (to highlight the details that he may have
failed to mention).

[A favorite problem is having him describe changing a tire on a car.
It *seems* so trivial -- yet, if I was a Martian (unfamiliar with tires
and cars and all the implied information therein), I could easily find
fault in damn near any description he could make of that process.]

Quoted text here. Click to load it

You have to be able to imagine their point of perspective.

I recall trying to explain subroutines, modules, programs and *PROMS*
(which is what the manufacturing director was REALLY concerned with)
in the early 70's to a guy who had previously thought in terms of
diodes and resistors.
     "The program is the *story*.  The modules are the chapters."
     "And what about the PROMs?"
     "signatures -- bundles of N pages"
     "How do they correspond to the chapters?"
     "They don't.  A PROM could contain one -- or more -- modules;
      or, *part* of one; or, part of one and part of another; or,
      one or more complete modules and parts of other modules; or..."
     "???"
     "Here, rip the pages out of this book and stuff them into
      AS FEW OF THESE ENVELOPES AS POSSIBLE (cuz the envelopes are
      expensive).  Then, when done, find me Chapter 3..."

Quoted text here. Click to load it

I dislike the "baby" example so often cited wrt Brooks' work.
It's too "basic", in principle:  "well, d'uh!"

Instead, I try to find analogies to which the client/VC can more
readily relate:
- 12 people can't carry a dozen eggs more quickly than *one* person
- ...and a 13th is just going to get in the way!
- more shovels (and bodies) don't expedite digging a hole for a *lamppost*
- two people can't read a book faster than one


Re: The Embedded Muse 329
On 17/05/17 18:26, Walter Banks wrote:
Quoted text here. Click to load it

I've always liked Michael Faraday's 1850 description
of the practical value of electricity. The question
was asked by the Chancellor of the Exchequer, so the
appropriate answer was "one day, sir, you may tax it".


Quoted text here. Click to load it

Amazing how effective that analogy is :(


Site Timeline