15 Dec
2001
15 Dec
'01
9:46 a.m.
----- Original Message -----
From: "Jim Davis" <jpdavis(a)gorge.net>
To: <classiccmp(a)classiccmp.org>
Sent: Saturday, December 15, 2001 4:40 AM
Subject: Re: "Geeks" and licensing
I'm not sure if geeks should be licensed, but there are certainly instances
when their output should be monitored closely. Geeks who program voting
machines, for example. (I think that voting machine software should be
open source and available from the voting machine. Every other civilized
country gets by with pencil and paper and big bunches of people doing the
counting. I need to trust that an embedded systems programmer doesn't have
strong enough political beliefs that they would try to rig an election.
It gets even worse when you need to believe that people (read Microsoft)
coding the OS of the damn things don't have any interest in the outcome of
elections.)
I'd also include Geeks who program any machine that could accidentally
kill someone (for example airplanes) and Geeks who code for billion
dollar space hardware.
Eric
IMHO: All software development should be performed as
such:
1) Requirements - what should it do, and not do. Spin this till
everybody signs off.
2) Prelim design - Ok, a rough outline of the design, data
structures and control/data flow defined here.
3) Detailed design - Define all the modules and their function,
break it down.
4) Test plan - integrate testing into detailed design, make it unit
testable. A unit is somthing that has input and output and side
effects, like a function.
5) Finally, coding - build modules in parallel with test code.
6) Unit testing - verify that modules comply with detailed design.
7) Integration testing - hook it all together, make sure it works, apply
test plan developed in step 4 for fully integrated aplication.
Do 1-3 until marketing decides what they want,4-7 until you find no
errors.
A couple of things have been left out.
(a) make certain that all deliverable code has NOTHING that's not
absolutely required: not a superfluous comment, not an extra semicolon.
(b) make certain that all comments in the source have been kept current with the
code as it changes. Too many times, v117.03 has comments left from rev 000.01.
(c) test the model before you write the code. Make certain that every
combination of inputs vs content produces predictable results, no matter how
"impossible" the combination may appear to be.
(d) fire anyone who passes on a document with any form of error in it, including
spelling, punctuation, etc. That's as good a marker as anything as to how well
they've done their job.
For safety critical, you should /have to perform
statement and decision
coverage in
step 6 and 7 and the detailed design should have a one-to-one
corespondence
with the detailed design document.
Jim Davis.
"Eric J. Korpela" wrote:
>
> > > I've also had to work alongside people who managed to scrape their way
into
a
"programming" job without having "what it takes" to really write code
*and* solve problems. Don't get me wrong -- I have no degree and don't
think one's required to be a competent analyst/programmer/whatever.
But . . .
Should programmers be licensed? Sure makes me wonder . . .
Ok, what does it take to really write code and solve programs?
(Unlicensed programer/coder here ). Writing code is easy... writing the
doc's that is another story. I tend to favor the hardware side, but they
don't make TTL machines like the PDP-8E or transistor ones like the
PDP8/S.