From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.1 required=5.0 tests=BAYES_05,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 1025b4,959627a08fbc77c5 X-Google-Attributes: gid1025b4,public X-Google-Thread: 103376,30a9bb3017fa58dd X-Google-Attributes: gid103376,public From: bill@nospam Subject: Re: GNAT versions ( was :Ada compiler for PC?) Date: 1999/05/08 Message-ID: <7h30sb$2go1@drn.newsguy.com>#1/1 X-Deja-AN: 475737862 References: <7fndu7$im4$1@nnrp1.dejanews.com> <7g5ju3$qpb$1@nnrp1.dejanews.com> <7gbjhg$s98$1@rtl.cygnus.com> <7gpsrd$qc7$1@nnrp1.dejanews.com> <7h2ig6$apr$1@nnrp1.deja.com> Organization: Newsguy News Service [http://www.newsguy.com] Newsgroups: comp.lang.ada,gnu.misc.discuss Date: 1999-05-08T00:00:00+00:00 List-Id: In article <7h2ig6$apr$1@nnrp1.deja.com>, Robert says... > >Sure some iteration is required, but it can often be minimized, >and you can come very close to the ideal. > >For example, for one project I did for Honeywell, a full real time >executive, with thread support, synchronization primitives, integral >debugger etc, was done by FIRST writing the user reference manual >documenting the API in completely detail, THEN writing the executive >(some 50,000 lines of assembly code). very few changes were required >to the manual, I also like the document first, write code second. But many time, after development starts, the API needs to be changed, becuase others wants it changed. it is not in your control. If you design your API one way, and no one complains then, but one week later, manager asks you to add something to the API or change it becuase they need some new functionality from your system, what are you to do? I found that when this happens, it is almost always becuase people did not spend too much time on specifications and on design stage. This happens also in places where little communication between engineers is the common culture in the work place. And in places where software managers have no clue about software, yet they are in charge of large software development projects. I've had a software manager who had no idea what a source control system is, and this was in a major US company. His idea of source control is to copy your files to separate hard drive. I've worked in places, where design changes were nade based on quick talk over the coffe station at work, or some remark made between 2 programmers walking across each other in the hallway. I've worked in places, where programmers do not talk to each others working on the same project. I've even worked on projects where programmers do not talk period. It is not surprising that changes in API are always occuring in these places. These places are some of the major companies in the US, well known names. It seems the most common way of writing code nowadays is this: -- Below is a simplified version of how software is written -- nowadays in some of the major companies in the US. To make every one think they are doing things right, quickly write some design thing. email it. then goto write_code. (of course no one will read and comment on the design send, since everyone else is busy debugging, but it is done so one can say they have done 'design'). write_code: write more code. see if that does what you think it needs to do if not then goto write_code else done: email the program to customer. cutomer emails back a bug complaint. goto write code. end if Bill