The Embedded Muse 329

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

In article <ofcj21$lls$1@dont-email.me>, rbehm@hushmail.com says...
> 
> 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

ditto

Been some good ones recently like

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

-- 
Paul Carpenter          | paul@pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/>    PC Services
<http://www.pcserviceselectronics.co.uk/LogicCell/> Logic Gate Education
<http://www.pcserviceselectronics.co.uk/fonts/>     Timing Diagram Font
<http://www.badweb.org.uk/>    For those web sites you hate

On Mon, 15 May 2017 23:59:02 +0800, Reinhardt Behm wrote:

> 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

:)

All too true.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

I'm looking for work -- see my website!

On 2017-05-15 1:31 PM, Tim Wescott wrote:
> On Mon, 15 May 2017 23:59:02 +0800, Reinhardt Behm wrote:
>
>> 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
>
> :)
>
> All too true.
>
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..

On 5/17/2017 10:26 AM, Walter Banks wrote:

> 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.

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.]

> 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.

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..."

> 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".

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

On 17/05/17 18:26, Walter Banks wrote:
> On 2017-05-15 1:31 PM, Tim Wescott wrote:
>> On Mon, 15 May 2017 23:59:02 +0800, Reinhardt Behm wrote:
>>
>>> 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
>>
>> :)
>>
>> All too true.
>>
> 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.

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".


> 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".

Amazing how effective that analogy is :(