> Andrew,
> >This advice to more seriously consider the user and task is, I think,
> >very good and I think doing so is important to rendering our results
> >more scientific. Unfortunately, it seems less and less of the
> >resulting work is directly relevant to the relatively low-level
> >practices of coding by experts.
>
> Not necessarily. Given a model of how people understand code
> I'm sure it would
> be possible to derive some useful guidelines.
Yes, not necessarily. It is certainly reasonable to expect to get some
sort of useful guidelines out of models.
But I was really arguing a rather more philosophical point about how
much further away cognitive models are from justifiable design
requirements or programming guidelines. The early work tried to
directly tell you if one program format worked better than another.
Use n-space tabs! Avoid this construct! By building a cognitive model
instead, you're a good number of steps removed from figuring out such
things. The design implications seem to tend towards very simple and
low level, or the basic and very general: don't tax memory; make
things consistent; make stuff learnable. I was arguing we seem to see
few specific programming-related recommendations coming out of the
cognitive modeling work (yet we still see some coming out of the simple
performance comparison type of work).
This is just my own opinion as someone from computing science who has
genuinely tried to apply theory to designing tools. But I think I
share some good company too in my assessment of the limitations of
cognitive theory (see Landauer's chapter 5 in "Designing Interaction",
ISBN 0-521-40056-2).
What kind of guidelines are you thinking of? You mention the guideline
to use meaningful names for identifiers. I admit I'm rather hard
pressed to think of any reason to employ a cognitive model to justify
this guideline, but I suppose it could be invariably wrong. I also
don't know of any cognitive model that would tell how to write a
guideline stating which meaningful names to use (or meaningful names to
avoid), but that would obviously be useful.
(Maybe it is a worthwhile project to get together a list of coding
guidelines for which there exist psychological justifications and/or
experimental results. This would obviously be something you're
interested in.)
> >How many rules do you think govern programming?
> Sheil quotes Brooks as estimating 10K, which sounds about right.
> I have broken the C standard down into 2,500 sentences and am writing
> to each of those. I could write 10 comments per sentence, so 25K. And that's
> just at a low level. [..] I am also excluding the higher
> level design stuff. So I would be happy with 10K.[..]
> Does 2000 pages (current estimate) sound reasonable? But hey, who said
> anybody would ever read it :-|
I'm not sure if I understand you correctly: you mean you've described
the C standard in 2.5K sentences and have about 10 rules of programming
(or guidelines, if you prefer) that apply to each of those sentences?
Wow.
> >Guidelines can be thought of as the rules of thumb
>
> Err, would you be happy with the software controlling the car/airplane/...
> you are in being written to rules of thumb?
You mean like programmers applying the guideline "use meaningful
identifiers" when nobody knows what that really means? I wouldn't
dream of flying on an aircraft built using such fuzzy rules. ;-/
This brings up a point that others may be interested in talking about
here in connection with your original question. ACM has pulled out of
SWEcc (Software Engineering Coordination Committee) and so licensing of
professional software engineers in most of North America has become
less certain. One of the major concerns of theirs was how to figure
out what a core body of knowledge for software engineering would be.
They said:
we are uncertain whether, at present, there exists any process to
articulate a core body of knowledge in software engineering that will
directly contribute to the solution of the software quality problem.
(see http://www.acm.org/serving/se_policy/bok_assessment.pdf).
In the bok_assessment document, it claims that the core body of
knowledge for credentialed engineers would need to "reflect actual
achievable good practice". I should think that some of your guidelines
would be related to such a body of knowledge.
> Companies are scared of testing developers in case they frighten off the good
> ones. In what other area could people with little experience manage to get
> jobs with such responsibility?
You mean...other than politics? : )
Andrew
