Re: Mapping (CoBOL) Methodologies to Problem Domains


<docdwarf@xxxxxxxxx> wrote in message news:fncm8p$fsr$1@xxxxxxxxxxxxxxxxxxxx
Waw haw haw haw... this guy's *serious*? Give this a listen, from .pdf
page 5 (showing book page 332):

--begin quoted text

Step 2: DOCUMENT THE DESIGN

At this point it is appropriate to raise the issue of - 'how much
documentation?' My own view is 'quite a lot'; certainly more than most
programmers, analysts or program designers are willing to do if left to
their own devices. The first rule of managing software development is
ruthless enforcement of documentation requirements.

<snip>

--end quoted text

All righty, by a show of hands... has anyone ever seen anything like this
happen?

(My experience, of course, is with 'sick shops' so I haven't run across an
instance of a single manager - let along an entire project's management -
being replaced because documentation was not 'up to acceptable standards',
even where 'acceptable' was construed as 'scribble something in cuneiform
- Akkadian or Hittite, your choice - on a bit of bathroom-tissue'.)

DD


I often hear the argument - from programmers mostly - "how can you write the
specs before you write the program?" To me, that's most peculiar. I answer
"how can you draw the blueprints before you build the house?". Trouble is,
they don't get it.

Whether or not they commit anything to paper, every programmer - every good
one, anyway - has a pretty good idea of what the program has to do. A great
number of the details will have to be filled in but the basic flow and the
functions that the program has to accomplish are clear or at least obvious.
(OO programmers take note: I'm not using "function" in the OO sense). I
have found, and the people I've convinced have found, that if you take time
and scribble all these notions down, and go over them a few times with
different coloured pens (Yes! You can't write or debug a program without a
red pen!) you will have resolved most of the issues and greatly eased the
actual coding. Notes and corrections can be likewise scribbled in; once
the program is working the whole mass can be neatly reformatted into the
program specs.

(Please keep your scorn generators off. I'm speaking about something that
works, can be proved to work, and is easy to do. That I choose to do it
with pencil & paper is irrelevant.)

(The process that PD uses is similar in essence but far more controlled and
precise in practice).

Apart from what I was calling task guides in 1980 but which are now known as
use cases, this is the only form of documentation which is controversial. I
can truthfully state that it's saved my bacon on any number of occasions.

To answer DD's question: no, I haven't seen this done, but there have been
times when I wished it had! And I'd agree that conformance with
documentation standards is essential to keep the shop out of trouble.

PL


.

Relevant Pages

  • Re: Interview preparation
    ... assurance quality standards, yet are designed and proven to improve ... In the worst case writing documentation becomes goal deferment. ... The Planner thinks about what he.s doing so much, ... Strengths They do design. ...
    (comp.arch.embedded)
  • Re: Forth is broken by culture?
    ... At some point the design provides some clear idea of what ... Forth" which discusses design and documentation processes for Forth ... review process, what your specifications look like, etc. ... If you do your Forth code right the only tool you need for static analysis ...
    (comp.lang.forth)
  • Re: Opinions re: MCU vendors [long]
    ... I'm looking at a couple of different parts from Atmel ... you *know* a quality product when you see it. ... you verify that it meets the other design specifications. ... Documentation for a reference design using that same component ...
    (comp.arch.embedded)
  • Re: How many of your jobs are like this?
    ... Megawatt power designs one day, ... documentation easier, ... if the windows are *open* to much and don't present enough ... "back pressure" to keep wind from pushing HOT AIR back into the ...
    (comp.arch.embedded)
  • Re: hardware board design - beginner... pls help
    ... I am an electronics graduate and I wish to learn hardware board design. ... Here's a typical very simple design flow and note that each and every stage requires thorough documentation: ... There's a lot more - power requirements, battery operation?, chargers, size, weight - there's a thousand and one things that have to be thoroughly _defined_. ... Hand route any critical signals - autorouters, in general, suck for critical signals, and it's best to route the ...
    (sci.electronics.design)