TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy

TEAM-ADA@LISTSERV.ACM.ORG

Options: Use Classic View

Use Proportional Font
Show Text Part by Default
Show All Mail Headers

Topic: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
JF Harrison <[log in to unmask]>
Fri, 23 Feb 2001 18:59:50 -0800
text/plain (55 lines)
> Do not condemn successful software just because it has bugs.  It would not
> be successful if it did not provide some service that the purchaser wants.
>
> Sorry for the rant.
>
> Roger Racine
>
Here's my blather.  I'm a novice Ada programmer, by the way.


    "A good plan today is better than a perfect plan tomorrow." Gen. George
S. Patton

    business as war

    capture defensible ground

  Sucky software wins the battle today and the war tomorrow, but "good
enough" software wins the battle and the war.  Looks like Ada developers are
good at winning the first battle on big, hard to manage projects, but that
Ada isn't handy for rapid prototyping (versus quick and dirty C
programmers).  Could there be an ugly-headed step-child of Ada to be used
for rapid prototyping, or is that already C?  Perhaps a rapid-development
Visual Ada environment wouldn't help much on big projects, but would make a
difference for quick and dirties.   Perhaps that should be the goal for a
"new" Ada development environment - churning out quick and dirties - and the
resultant code would still be Ada.  If the project merited further work, it
could be restarted from scratch using existing methods, but the code
generated by the quick and dirty interface (QDI) might be a useable
foundation.  Ada programmers might derive income or notoriety by developing
templates and plugins/extensions to the QDI for specific project types or
activities.

Caveat:
  Using such a QDI might degrade the traditional software engineering
practices Ada developers pride themselves in, if novice Ada
developers/hobbyists learn Ada through using the QDI alone.  That, however,
would be the difference between a Junior and Senior Ada developer.  Jr. only
knows how to play with the QDI, whereas Sr. is a real software engineer.
I'm referring to some kind of certification practice.  Without
certification, the novices that emphasize Sr. level practices over Jr. level
ones will probably get fired in the real world, and the Jr.'s will get
promoted to senior level positions simply due to success.  Success is great,
but just because they succeeded with the QDI doesn't mean they'll be
qualified to manage major software projects that require sound engineering
principles.  In other words, an effective Sniper or Sergeant doesn't
necessarily make an effective Captain or General.



"Ada: Battle Ready."


JF Harrison

ATOM RSS1 RSS2