ontolog-forum
[Top] [All Lists]

Re: [ontolog-forum] semantic analysis was do not trust quantifiers

To: "'[ontolog-forum] '" <ontolog-forum@xxxxxxxxxxxxxxxx>
From: "Rich Cooper" <rich@xxxxxxxxxxxxxxxxxxxxxx>
Date: Sat, 25 Sep 2010 13:12:19 -0700
Message-id: <20100925201221.26303138EF5@xxxxxxxxxxxxxxxxx>

Hi David,

 

It seems to me that we DO maintain our machines, mostly without the help of heavily constructed detailed documentation.  

 

Back in the seventies and eighties, the government insisted on full docs for software development and they defined the DoD standard 2167 family of specifications.  Productivity on full doc projects was running at around 60 LOC per person month at that time.  With the better word processors of today, perhaps that would be a better rate – maybe 75 LOC.  

 

But small R&D groups developing in teams of 2 to 5 people can regularly turn out 2,000 to 10,000 LOC with minimal documentation to demonstrate technical viability of a concept.  So the question was raised about how valuable it is to fully document, test, qualify and validate a software project compared to the cost of doing so.  

 

Best current practice is to only use deep docs when you have a mission-critical application that really requires that much detail.  

 

Then, there is the problem that the maintenance process often renders documents of questionable use because new materials are being added, new concepts, new situations that cause undesirable behavior.  Even behaviors that were perfectly specified and implemented change faster than the docs can be updated.  That is why so many major software projects “wear out” and have to be completely replaced with new developments.  Maintenance is a very expensive process only justified in certain circumstances, and even then, they require a large company development perspective, not the small company technology development perspective that the original concept did.  

 

Randy Jensen studied the actual development cost and schedule information and was able to formulate the kind of math model for estimating software development which made his estimates better than any of the more famous, better published authors of those studies.  His SEER concept was implemented in a program then, though I haven’t kept up with the details since about 1990.  

 

Jensen’s one line summary of good software development management techniques was to treat the process as similar to “crowd control”!  Divide the design into small components, separate the development teams for every detail not required to be interfaced to other components, and try to recreate the high productivity of small teams by narrowing the size of the component interface specs compared to the size of the implementation software for each component.  But management was only able to achieve some small degree of improvement, mainly because the concepts in the component interfaces were very difficult to make known, unambiguously, to both component developers and component users.  

 

He used to say that the main cost of software development was communication.  Getting every programmer concerned with each interface symbol to understand the meaning of that symbol as presented, designed, implemented and tested in the component, and later presented, designed, implemented and tested in the system assembly that incorporated each component.  It was that limit (communications), according to Jensen, that caused large groups of programmers to be so vastly less productive than small groups.  Ultimately, his conclusion was that there could be NO basic improvement because the large projects simply run into the human limits of conceptual organization and sharing about the precise meaning of the component interfaces.  Toolware helps a lot, but it is ultimately the programmer’s limited brain (seven plus or minus two chunks) which establishes the cost and schedule curve.  

 

HTH,

-Rich

 

Sincerely,

Rich Cooper

EnglishLogicKernel.com

Rich AT EnglishLogicKernel DOT com

9 4 9 \ 5 2 5 - 5 7 1 2


From: ontolog-forum-bounces@xxxxxxxxxxxxxxxx [mailto:ontolog-forum-bounces@xxxxxxxxxxxxxxxx] On Behalf Of David Eddy
Sent: Saturday, September 25, 2010 10:38 AM
To: [ontolog-forum]
Subject: Re: [ontolog-forum] semantic analysis was do not trust quantifiers

 

Rich -

 

On Sep 25, 2010, at 12:55 PM, Rich Cooper wrote:



The real issue, from my viewpoint, is just how UNNATURAL the language can be before turning the users back to hiring computer operators instead of doing their work firsthand on the available computers and software.  My experience with UNNATURAL languages is that they don’t function as normally advertised.   

 

What I'm beating on here is that the language used inside software applications—the systems that ensure milk gets delivered to my supermarket & that my checking account is properly balanced by the bank—the language used is U-G-L-Y.

 

Natural language is the stuff you read in the NYTimes... it's been explicitly written to be read by another human, PLUS edited by a professional editor for readability.  The software that runs invisibly in the background of our lives is written to make a computer do something.  It is mostly not written for readability.  Such resources easily succumb to statistical analysis.

 

When another human comes along & needs to read software, because there are effectively no rules for such language (other than the technical restrictions on length & separators between terms) it can be a slow & error-prone process to understand what cryptic abbreviations mean.

 

 

IF there were a mechanism available to help the analyst/programmer to quickly understand that at line 1503 in program LCCIIL02 "MIT" means male impotence test (rather than Massachusetts Institute of Technology) this would be socially useful.

 

 

To repeat: EM Forester's "The Machine Stops"... if we cannot maintain the "machines" (e.g. software applications) that support our society, this is not good. 

 

___________________

David Eddy

 

781-455-0949

 


_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/  
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/  
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/ 
To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx    (01)

<Prev in Thread] Current Thread [Next in Thread>