Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #26603

Re: The Embedded Muse 329

Show all headers | View raw

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

Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

The Embedded Muse 329 Reinhardt Behm <rbehm@hushmail.com> - 2017-05-15 23:59 +0800
  Re: The Embedded Muse 329 Paul <paul@pcserviceselectronics.co.uk> - 2017-05-15 17:56 +0100
  Re: The Embedded Muse 329 Tim Wescott <seemywebsite@myfooter.really> - 2017-05-15 12:31 -0500
    Re: The Embedded Muse 329 Walter Banks <walter@bytecraft.com> - 2017-05-17 13:26 -0400
      Re: The Embedded Muse 329 Don Y <blockedofcourse@foo.invalid> - 2017-05-17 11:12 -0700
      Re: The Embedded Muse 329 Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-05-17 20:13 +0100

csiph-web