Re: GNAT versions ( was :Ada compiler for PC?)

[bill@nospam]

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