Re: A Brief Look at History

Paul E. Bennett wrote:
> John Doty wrote:
> 
>> Elizabeth D Rather wrote:
>>
>>> Some programmers don't like to write comments in code regardless of
>>> language.  They shouldn't be tolerated: we've spoken of management in
>>> other contexts, and one of the responsibilities of good management is
to
>>> be sure the team is professional about writing clear, well-commented
>>> code.  And one of the responsibilities of professional programmers is
to
>>> write that way.
>> Then you cannot collaborate: it's a simple as that. In a collaboration
>> you do not get to choose who writes the code. And if you're doing
>> anything but a trivial application, you'd better worry about finding
>> people whose strengths match the domain and quit worrying about
>> inflexible notions of who should be writing code. Code that cleanly
>> solves the real application issues can always be prettied up, but a
>> "professional programmer" cannot create the code without the domain
>> knowledge, and that can take a lifetime of study to acquire.
> 
> I would hope any professional programmer will always write clear well
> commented and do***ented code. However, professional engineers, whatever
> their discipline, also write code these days and I expect no less a
level
> of professional code writing from them if they write code at all.
> 
> One of the things that makes it easier in a professional team
environment is
> the existence of coding and do***ent standards that lay out the rules
for
> the way the company needs their code to look and the management's skill
in
> ensuring that these standards are adhered to.

What if the coding is taking place under nine institutional roofs in 
three different countries with four separate funding sources, and 
therefore no single management authority?

> 
> I don't go with having code in the production stream that needs to be
> prettied up. It should start out that way by design and be maintained in
> its full elegant glory. Prototype code should never be used as a
starting
> point for production code. All you should take from the prototype code
is
> the essential idea from it and design the final code properly.

Nice when you can make that approach work. What do you do when your 
collaborator takes a different approach?

I also note that in space research, essentially everything (not just 
software) is a prototype by normal commercial standards. It's the nature 
of the endeavor. This is especially true with NASA, where to save money 
they cut the number of builds to an absolute minimum (but that actually 
costs extra money).

-- 
John Doty, Noqsi Aerospace, Ltd.
http://www.noqsi.com/
--
History teaches that logical consistency is neither sufficient nor 
necessary to establish practical, real world truth. Those who attempt to 
use logic for that purpose are abusing it.